[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1446740279.4184.40.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Thu, 05 Nov 2015 08:17:59 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: Arnd Bergmann <arnd@...db.de>, David Miller <davem@...emloft.net>,
netdev@...r.kernel.org, tklauser@...tanz.ch
Subject: Re: AF_PACKET mmap() v4...
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....
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists