On Fri, Apr 22, 2016 at 1:51 AM, Steffen Klassert <steffen.klass...@secunet.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.klass...@secunet.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
