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 GRO'ed in the first
>>> place because of the loss of information and
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.
>
> First of all GRO is supposed to be lossless,
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 e
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 pa
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 reason to turn it off on a
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 outperf
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 reas
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 forwarding/routing workloads. Instead we should be
>>>
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 traverse the stack togethe
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 really losing with incre
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 whenever e.g. the desti
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 as I think you're sayi
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 th
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 consider that a 40Gb/s link ca
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 1
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
>> so if you have two flows that g
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 see it is essentially ju
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 lossles
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 currently
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 field
>> as a way of identifyin
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
>
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 valid
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 inval
23 matches
Mail list logo
