On 04/01/2016 07:21 PM, Eric Dumazet wrote:
On Fri, 2016-04-01 at 22:16 -0400, David Miller wrote:
From: Alexander Duyck
Date: Fri, 1 Apr 2016 12:58:41 -0700
RFC 6864 is pretty explicit about this, IPv4 ID used only for
fragmentation. https://tools.ietf.org/html/rfc6864#section-4.1
The goal
On Fri, Apr 1, 2016 at 7:16 PM, David Miller wrote:
> From: Alexander Duyck
> Date: Fri, 1 Apr 2016 12:58:41 -0700
>
>> RFC 6864 is pretty explicit about this, IPv4 ID used only for
>> fragmentation. https://tools.ietf.org/html/rfc6864#section-4.1
>>
>> The goal with this change is to try and ke
On Sat, 2016-04-02 at 10:19 +0800, Herbert Xu wrote:
> On Fri, Apr 01, 2016 at 07:15:33PM -0700, Eric Dumazet wrote:
> > On Sat, 2016-04-02 at 09:57 +0800, Herbert Xu wrote:
> > >
> > > We could easily fix that by adding a feature bit to control this,
> > > something like SKB_GSO_TCP_FIXEDID.
> >
On Fri, 2016-04-01 at 22:16 -0400, David Miller wrote:
> From: Alexander Duyck
> Date: Fri, 1 Apr 2016 12:58:41 -0700
>
> > RFC 6864 is pretty explicit about this, IPv4 ID used only for
> > fragmentation. https://tools.ietf.org/html/rfc6864#section-4.1
> >
> > The goal with this change is to tr
On Fri, Apr 01, 2016 at 07:15:33PM -0700, Eric Dumazet wrote:
> On Sat, 2016-04-02 at 09:57 +0800, Herbert Xu wrote:
> >
> > We could easily fix that by adding a feature bit to control this,
> > something like SKB_GSO_TCP_FIXEDID.
>
> I understood the patch allowed to aggregate 4 segments having
From: Alexander Duyck
Date: Fri, 1 Apr 2016 12:58:41 -0700
> RFC 6864 is pretty explicit about this, IPv4 ID used only for
> fragmentation. https://tools.ietf.org/html/rfc6864#section-4.1
>
> The goal with this change is to try and keep most of the existing
> behavior in tact without violating
On Sat, 2016-04-02 at 09:57 +0800, Herbert Xu wrote:
> Eric Dumazet wrote:
> >
> > I do not particularly care, but it is worth mentioning that GRO+TSO
> > would not be idempotent anymore.
>
> We could easily fix that by adding a feature bit to control this,
> something like SKB_GSO_TCP_FIXEDID.
Eric Dumazet wrote:
>
> I do not particularly care, but it is worth mentioning that GRO+TSO
> would not be idempotent anymore.
We could easily fix that by adding a feature bit to control this,
something like SKB_GSO_TCP_FIXEDID.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.a
| For transmit we can leave the IP ID code as is. For receive we should not be
| snooping into the IP ID for any frames that have the DF bit set as devices
| that have adopted RFC 6864 on their transmit path will end up causing issues.
Currently, GRO does not coalesce TCP packets originating f
On Fri, Apr 1, 2016 at 12:24 PM, David Miller wrote:
> From: Eric Dumazet
> Date: Fri, 01 Apr 2016 11:49:03 -0700
>
>> For example, TCP stack tracks per socket ID generation, even if it
>> sends DF=1 frames. Damn useful for tcpdump analysis and drop
>> inference.
>
> Thanks for mentioning this, I
From: Eric Dumazet
Date: Fri, 01 Apr 2016 11:49:03 -0700
> For example, TCP stack tracks per socket ID generation, even if it
> sends DF=1 frames. Damn useful for tcpdump analysis and drop
> inference.
Thanks for mentioning this, I never considered this use case.
> With your change, the resulti
On Fri, 2016-04-01 at 11:05 -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
> GRO. W
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
13 matches
Mail list logo