netdev - RE: [RFC] net: distribute vxlan tunneled traffic across multiple TXQs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CF9D1877D81D214CB0CA0669EFAE020C26B242FD@CMEXMB1.ad.emulex.com>
Date:	Thu, 19 Dec 2013 07:43:21 +0000
From:	Sathya Perla <Sathya.Perla@...lex.Com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [RFC] net: distribute vxlan tunneled traffic across multiple
 TXQs


> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@...il.com]
> Sent: Tuesday, December 17, 2013 10:15 PM
> To: Sathya Perla
> Cc: netdev@...r.kernel.org
> Subject: Re: [RFC] net: distribute vxlan tunneled traffic across multiple TXQs
> 
> On Tue, 2013-12-17 at 14:10 +0530, Sathya Perla wrote:
> > TX traffic is distributed across multiple TXQs using skb->sk->sk_hash.
> > For vxlan skbs, the reference to the original socket (skb->sk) is replaced
> > with vxlan-sk. Because of this all tunneled traffic ends up only on one TXQ.
> >
> > This patch uses the skb->rxhash field to carry the original sk->sk_hash
> > value so that it can be used by netdev layer to pick a TXQ. If this approach
> > is agreeable then we can change the name of skb->rxhash to skb->hash so that
> > it can be used in both RX and TX paths.
> >
> > But, after a TXQ is picked based on the skb->rxhash for tunneled traffic,
> > it's index cannot be recorded in the original socket as it's reference
> > is no longer available in skb. So, the TXQ-index would need to be
> > computed (from skb->rxhash) for each skb. Any ideas on how this can be
> > avoided?
> 
> Real question is : Why vxlan needs to set a skb destructor ?

The need for a vxlan skb destructor is not apparent to me.
The code just bumps up vxlan-sk->refcnt and does nothing else.
> 
> skb_orphan(skb) breaks TCP Small queues and FQ/pacing packet scheduler,
> plus other things...
It also seems to violate the TCP wmem accounting of the original socket.

I'll test a patch removing the vxlan destructor and post it for comments.

thanks,
-Sathya