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

From: Tom Herbert Date: Wed, 6 Apr 2016 14:42:26 -0300 > On Wed, Apr 6, 2016 at 12:43 PM, David Miller wrote: >> From: Tom Herbert >> Date: Wed, 6 Apr 2016 10:53:52 -0300 >> >>> Packets that are forwarded really should not be

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

On Wed, Apr 6, 2016 at 12:43 PM, David Miller wrote: > From: Tom Herbert > Date: Wed, 6 Apr 2016 10:53:52 -0300 > >> Packets that are forwarded really should not be GRO'ed in the first >> place because of the loss of information and added latency. > >

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

On Wed, 2016-04-06 at 16:55 +0100, Edward Cree wrote: > On 06/04/16 16:39, Eric Dumazet wrote: > > Look at the mess of some helpers in net/core/skbuff.c, and imagine the > > super mess it would be if using a concept of 'super packet with various > > headers on each segment'. > Maybe I'm still not

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

On 06/04/16 16:39, Eric Dumazet wrote: > Look at the mess of some helpers in net/core/skbuff.c, and imagine the > super mess it would be if using a concept of 'super packet with various > headers on each segment'. Maybe I'm still not explaining this very well, but there is _no_ concept of 'super

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

From: Tom Herbert Date: Wed, 6 Apr 2016 10:53:52 -0300 > Packets that are forwarded really should not be GRO'ed in the first > place because of the loss of information and added latency. First of all GRO is supposed to be lossless, so please stop saying this would be a

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

On Wed, 2016-04-06 at 15:26 +0100, Edward Cree wrote: > 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

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

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

On Wed, Apr 6, 2016 at 8:21 AM, Edward Cree wrote: > On 06/04/16 00:45, David Miller wrote: >> From: Edward Cree >> Date: Tue, 5 Apr 2016 16:07:49 +0100 >> >>> On the gripping hand, I feel like GRO+TSO is the wrong model for >>> speeding up

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

On 06/04/16 00:45, David Miller wrote: > From: Edward Cree > Date: Tue, 5 Apr 2016 16:07:49 +0100 > >> On the gripping hand, I feel like GRO+TSO is the wrong model for >> speeding up forwarding/routing workloads. Instead we should be >> looking into having lists of SKBs

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

On Tue, Apr 05, 2016 at 12:36:40PM -0300, Tom Herbert wrote: > On Tue, Apr 5, 2016 at 12:07 PM, Edward Cree wrote: > > On 05/04/16 05:32, Herbert Xu wrote: > >> On Mon, Apr 04, 2016 at 09:26:55PM -0700, Alexander Duyck wrote: > >>> The question I would have is what are you

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

From: Edward Cree Date: Tue, 5 Apr 2016 16:07:49 +0100 > On the gripping hand, I feel like GRO+TSO is the wrong model for > speeding up forwarding/routing workloads. Instead we should be > looking into having lists of SKBs traverse the stack together, > splitting the list

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

On Tue, Apr 5, 2016 at 2:06 PM, Edward Cree wrote: > On 05/04/16 16:36, Tom Herbert wrote: >> I thought about that some. It seems like we would want to do both GRO >> and retain all the individual packets in the skb so that we could use >> those for forwarding instead of GSO

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

On 05/04/16 16:36, Tom Herbert wrote: > I thought about that some. It seems like we would want to do both GRO > and retain all the individual packets in the skb so that we could use > those for forwarding instead of GSO as I think you're saying. I didn't quite mean that, I meant just pass around

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

On Tue, Apr 5, 2016 at 9:30 AM, Eric Dumazet wrote: > On Tue, 2016-04-05 at 08:52 -0700, Alexander Duyck wrote: > >> >> I disagree I think it will have to be part of the default >> configuration. The problem is the IP ID is quickly becoming >> meaningless. When you

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

On Tue, 2016-04-05 at 08:52 -0700, Alexander Duyck wrote: > > I disagree I think it will have to be part of the default > configuration. The problem is the IP ID is quickly becoming > meaningless. When you consider that a 40Gb/s link can wrap the IP ID > value nearly 50 times a second using a

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

On Mon, Apr 4, 2016 at 9:32 PM, Herbert Xu wrote: > On Mon, Apr 04, 2016 at 09:26:55PM -0700, Alexander Duyck wrote: >> >> The problem is right now we are mangling the IP ID for outer headers >> on tunnels. We end up totally ignoring the delta between the values >>

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

On Tue, Apr 5, 2016 at 12:07 PM, Edward Cree wrote: > On 05/04/16 05:32, Herbert Xu wrote: >> On Mon, Apr 04, 2016 at 09:26:55PM -0700, Alexander Duyck wrote: >>> The question I would have is what are you really losing with increment >>> from 0 versus fixed 0? From what I

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

On 05/04/16 05:32, Herbert Xu wrote: > On Mon, Apr 04, 2016 at 09:26:55PM -0700, Alexander Duyck wrote: >> The question I would have is what are you really losing with increment >> from 0 versus fixed 0? From what I see it is essentially just garbage >> in/garbage out. > GRO is meant to be

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

On Mon, Apr 04, 2016 at 09:26:55PM -0700, Alexander Duyck wrote: > > The problem is right now we are mangling the IP ID for outer headers > on tunnels. We end up totally ignoring the delta between the values > so if you have two flows that get interleaved over the same tunnel GRO > will

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

On Mon, Apr 4, 2016 at 8:44 PM, Herbert Xu wrote: > On Mon, Apr 04, 2016 at 09:31:21AM -0700, Alexander Duyck wrote: >> RFC 6864 states that the IPv4 ID field MUST NOT be used for purposes other >> than fragmentation and reassembly. Currently we are looking at this

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

On Mon, Apr 04, 2016 at 09:31:21AM -0700, Alexander Duyck wrote: > RFC 6864 states that the IPv4 ID field MUST NOT be used for purposes other > than fragmentation and reassembly. Currently we are looking at this field > as a way of identifying what frames can be aggregated and which cannot for >

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

On 2016-04-04 10:31, Alexander Duyck wrote: RFC 6864 states that the IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly. Currently we are looking at this field as a way of identifying what frames can be aggregated and which cannot for GRO. While this is

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

RFC 6864 states that the IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly. Currently we are looking at this field as a way of identifying what frames can be aggregated and which cannot for GRO. While this is valid for frames that do not have DF set, it is