netdev - Re: [PATCH] Fixed zero copy GSO without orphaning the fragments

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 03 Jun 2014 06:49:45 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Igor Royzis <igorr@...rtex.com>
Cc:	"Michael S. Tsirkin" <mst@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Tom Herbert <therbert@...gle.com>,
	Daniel Borkmann <dborkman@...hat.com>,
	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	Simon Horman <horms@...ge.net.au>,
	Joe Perches <joe@...ches.com>, Jiri Pirko <jiri@...nulli.us>,
	Florian Westphal <fw@...len.de>,
	Paul Durrant <Paul.Durrant@...rix.com>,
	Thomas Graf <tgraf@...g.ch>, Jan Beulich <JBeulich@...e.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Miklos Szeredi <mszeredi@...e.cz>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>,
	Anton Nayshtut <anton@...rtex.com>
Subject: Re: [PATCH] Fixed zero copy GSO without orphaning the fragments

On Tue, 2014-06-03 at 14:54 +0300, Igor Royzis wrote:
> Eric, could you please provide a feedback on the suggestion to move
> the pointer from skb_shared_info to skbuff? If we must fit
> skb_shared_info till the 'frags' field into 1 cache line (I honestly
> don't quite understand why (the whole structure as well as the skb's
> data will always require > 1 cache line anyway)  and I would
> appreciate if you elaborate on this more), then moving the pointer to
> the parent fragment off skb_shared_info should help. Am I right?


Have you tried this idea and cook a patch ?
It seems quite complex, but maybe you have a pretty clear idea.

> 
> The pointer is essential if we want to solve the incorrect way the
> kernel handles a combination of packet segmentation (of any reason, in
> our case it was a VM guest not supporting GRO) and zero-copy feature.
> Disabling zero-copy for segmented packets is a workaround but an
> efficient solution would require either:
> a) a pointer in skb_shared_info, or
> b) a pointer in skbuff,  or
> c) reusing a [currently unused] existing pointer/field in a skb
> structure, which is a bad idea and I list it for completeness only.
> 
> Please comment,

It's nice you guys want nice numbers for bulk flows sending at line
rate, but many networking workloads handle thousands of flows, if not
more, and small to medium packet sizes. Its critical for them to keep
skb overhead as small as possible.

My understanding of this zero copy stuff and GSO is that you need a
refcounter, not in the skb or skb_shared_info, but in the structure that
describes the zero copy stuff. This way, the overhead of this extra
refcounting (still a win for you compared to 'orphaning fragments'), is
only paid for this special case.



--
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