Re: AF_PACKET mmap() v4...

[Eric Dumazet <eric.dumazet@gmail.com>]

On Thu, 2015-11-05 at 13:56 +0100, Daniel Borkmann wrote:
> On 11/05/2015 12:38 PM, Eric Dumazet wrote:

> > If I am not mistaken, af_packet also lacks the ability to properly set
> > skb->protocol
> >
> > I noticed this using trafgen on a bonding device, when I did my SYNFLOOD
> > tests for TCP listener rewrite.
> >
> > The bonding hash function might uses flow dissector, but as this flow
> > dissection depends on skb->protocol, all the traffic is directed on a
> > single slave.
> 
> Right, if I see this correctly, when you trigger the flushing of TX_RING
> via sendmsg(), one can hand over a sockaddr_ll, where we infer sll_protocol
> and tag every skb's skb->protocol with that in tpacket_fill_skb() for the
> current flushing run. Otherwise, we use the po->num specified at socket
> creation / bind time for everything (trafgen case).
> 
> If needed on a per skb basis, perhaps we could map some tpacket_hdr{,2}
> member that is not used from TX_RING side (perhaps union on tp_snaplen)?


If po->num is 0 (as in trafgen case), we could also get the proto from
Ethernet header provided by the user.

The skb_probe_transport_header() call from tpacket_fill_skb() is useless
in the current kernel.

Let say an application wants to mix IPv6 and IPv4 packets, using a
single TX ring....