[PATCH v2] batman-adv: Introduce no noflood mark
linus.luessing at c0d3.blue
Tue May 7 17:17:23 CEST 2019
On Tue, May 07, 2019 at 10:21:40AM +0200, Sven Eckelmann wrote:
> On Tuesday, 7 May 2019 10:00:18 CEST Marek Lindner wrote:
> > > I still don't see why this has to be implemented in batman-adv and not as an
> > > external filter (tc-ebpf or something like that).
> > As I understand the use-case (Linus correct me if I am wrong): The mark is
> > supposed to drop packets that couldn't be $optimized by one of the various
> > batman-adv payload traffic optimizations. From outside of batman-adv it would be
> > difficult to tell if a broadcast / multicast packet was optimized (think: served
> > via DAT cache, sent as unicast, etc) or not.
> It should be easy to see in tc whether a packet is transmitted as unicast or
> broadcast. It is just a bit check in the destination mac. So it would end up
> as a filter somewheere in the hardif tx path which first checks following
> before rejecting a packet:
> * is it a multicast/broadcast destination address?
> - maybe this part isn't even necessary - at least the mcast2unicast stuff
> uses batadv_send_skb_unicast
> * is it a batman-adv packet?
> * is is a batman-adv compat 15 broadcast packet?
> * does it have the noflood mark?
> This would even allow some fancy stuff like rate limiting or per hardif
> behavior. With the problem that there is no package yet which does this in
Ah, that's an interesting idea. So basically filtering on the
hardif instead of in batman-adv via some custom compiled BPF
filters. So basically similar to writing a small program like the
gluon-radv-filterd with a BPF_* parser?
> Or am I missing something essential here which is also done in the
> batadv_interface_tx path?
Hm, I guess functionally this would be mostly equivalent. Maybe
except a bit of performance due to our custom queueing
infrastructure. Not sure how much performance it would cost on our
small MIPS devices if a client were sending a few MBit/s of UDP
multicast through our batadv_add_bcast_packet_to_list()
The noflood-mark would drop the packet early on in batadv_interface_tx(),
before any queueing or copying happens.
Maybe more importantly even before the bcast_packet->seqno is
increased. It could become an issue if a node were increasing it's
seqno quickly without other nodes noticing the new seqnos.
Broadcast packets we actually let through might then be received
with a seqno outside of the seqno window on the receiving nodes.
> And why would we see see stuff which as served via DAT? This is usually not
> transmitted on the hardif ports.
I guess Marek ment it the other way round (see his "or not" at the
end of his sentence).
More information about the B.A.T.M.A.N