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
12 matches
Mail list logo