On 11/05/2015 11:56 PM, Daniel Borkmann wrote:
On 11/05/2015 05:17 PM, Eric Dumazet wrote:
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....
Sorry for the late answer.
For the skb->protocol issue, perhaps something like this. Also noticed that
we should rather do the vlan check when we have the actual linear data from
the ring slot, the current way seems buggy if I see this correctly. Both
patches squashed below.
Hmm, I believe there's another bug in TX_RING with SOCK_DGRAM, will do some
more experiments and post some patches later on.
Best,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
