netdev - Re: [RFC PATCH] gro: Partly revert "net: gro: allow to build full sized skb"

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: <20160422085107.GJ3347@gauss.secunet.com>
Date:	Fri, 22 Apr 2016 10:51:07 +0200
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Alexander Duyck <alexander.duyck@...il.com>
CC:	Eric Dumazet <eric.dumazet@...il.com>,
	Sowmini Varadhan <sowmini.varadhan@...cle.com>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH] gro: Partly revert "net: gro: allow to build full
 sized skb"

On Thu, Apr 21, 2016 at 09:02:48AM -0700, Alexander Duyck wrote:
> On Thu, Apr 21, 2016 at 12:40 AM, Steffen Klassert
> <steffen.klassert@...unet.com> wrote:
> > This partly reverts the below mentioned patch because on
> > forwarding, such skbs can't be offloaded to a NIC.
> >
> > We need this to get IPsec GRO for forwarding to work properly,
> > otherwise the GRO aggregated packets get segmented again by
> > the GSO layer. Although discovered when implementing IPsec GRO,
> > this is a general problem in the forwarding path.
> 
> I'm confused as to why you would need this to get IPsec GRO forwarding
> to work. 

It works without this, but the performance numbers are not that good
if we have to do GSO in software.

> Are you having to go through a device that doesn't have
> NETIF_F_FRAGLIST defined?

I don't know of any NIC that can do TSO on a skbuff with fraglist,
that's why I try to avoid to have a buffer with fraglist.

> Also what is the issue with having to go
> through the GSO layer on segmentation?  It seems like we might be able
> to do something like what we did with GSO partial to split frames so
> that they are in chunks that wouldn't require NETIF_F_FRAGLIST.  Then
> you could get the best of both worlds in that the stack would only
> process one super-frame, and the transmitter could TSO a series of
> frames that are some fixed MSS in size.

This could be interesting. Then we could have a buffer with
fraglist, GSO layer splits in skbuffs without fraglist that
can be TSO offloaded. Something like this might solve my
performance problems.