netdev - Re: [net PATCH v2 2/2] ipv4/GRO: Make GRO conform to RFC 6864

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <57051C79.7010303@solarflare.com>
Date:	Wed, 6 Apr 2016 15:26:01 +0100
From:	Edward Cree <ecree@...arflare.com>
To:	Tom Herbert <tom@...bertland.com>
CC:	David Miller <davem@...emloft.net>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Alexander Duyck <alexander.duyck@...il.com>,
	Alex Duyck <aduyck@...antis.com>,
	Jesse Gross <jesse@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [net PATCH v2 2/2] ipv4/GRO: Make GRO conform to RFC 6864

On 06/04/16 14:53, Tom Herbert wrote:
> But again, this scheme is optimizing for forwarding case and doesn't
> help (and probably hurts) the use case of locally terminated
> connections
Not really.  I think this has a chance to outperform GRO for locally
terminated connections, for a number of reasons:
* Doesn't look at higher-layer or inner headers until later in packet
  processing, for instance we (maybe) process every L3 header in a NAPI poll
  before looking at a single L4.  This could delay touching the second
  cacheline of some packets.
* Doesn't have to re-write headers to produce a coherent superframe.
  Instead, each segment carries its original headers around with it.  Also
  means we can skip _checking_ some headers to see if we're 'allowed' to
  coalesce (e.g. TCP TS differences, and the current fun with IP IDs).
* Can be used for protocols like UDP where the original packet boundaries
  are important (so you can't coalesce into a superframe).
Really the last of those was the original reason for this idea, helping with
forwarding is just another nice bonus that we (might) get from it.
And it's all speculative and I don't know for sure what the performance
would be like, but I won't know until I try it!
> which I would claim is more important.
No argument there :-)
> Packets that are
> forwarded really should not be GRO'ed in the first place because of
> the loss of information and added latency. The difficultly is that we
> don't currently make the forwarding decision before GRO,  if we can
> change this to decide whether packets are to be forwarded earlier then
> we can avoid doing GRO for those.
That certainly would be nice, XDP is exciting and I look forward to it.

-Ed