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: <CAKgT0UeJLhn5yyK9Ezt=jHsysi4y+fVkRoOyZN2Zbe7Wk0LuHw@mail.gmail.com>
Date:	Fri, 22 Apr 2016 10:14:22 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Steffen Klassert <steffen.klassert@...unet.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 Fri, Apr 22, 2016 at 1:51 AM, Steffen Klassert
<steffen.klassert@...unet.com> wrote:
> 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.

Well really GSO is only meant to preform better than if we didn't do
any GRO/GSO at all.  If that isn't the case I wouldn't consider it a
regression since as Eric points out there are other scenerios where
you end up with a chain of buffers stuck on the fraglist.  Mostly what
GRO/GSO gets you is fewer runs through the stack.

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

Most of them don't.  There are only one or two NICs out there that
support transmitting a frame that has a 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.

Right.  It is something to think about.  I was considering what might
be involved to make a fraglist based skb a GSO type.  Then we might be
able to handle it kind of like what we do for the whole
SKB_GSO_DODGY/NETIF_F_GSO_ROBUST path.  Basically if we just need to
break the frame at the fraglist level it probably wouldn't be that
hard to do assuming each skb is MSS aligned in terms of size.

- Alex