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 gluon.
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?
https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-radv-filte...
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() infrastructure.
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).
Regards, Linus