On Fri, Mar 11, 2016 at 2:55 PM, Tom Herbert wrote:
> On Fri, Mar 11, 2016 at 2:31 PM, Alexander Duyck
> wrote:
>> On Fri, Mar 11, 2016 at 1:29 PM, Edward Cree wrote:
>>> On 11/03/16 21:09, Alexander Duyck wrote:
The only real issue with the "generic" TSO is that it isn't going to
be s
On Fri, Mar 11, 2016 at 2:31 PM, Alexander Duyck
wrote:
> On Fri, Mar 11, 2016 at 1:29 PM, Edward Cree wrote:
>> On 11/03/16 21:09, Alexander Duyck wrote:
>>> The only real issue with the "generic" TSO is that it isn't going to
>>> be so generic. We have different devices that will support diffe
On Fri, Mar 11, 2016 at 1:29 PM, Edward Cree wrote:
> On 11/03/16 21:09, Alexander Duyck wrote:
>> The only real issue with the "generic" TSO is that it isn't going to
>> be so generic. We have different devices that will support different
>> levels of stuff. For example the ixgbe drivers will n
On 11/03/16 21:09, Alexander Duyck wrote:
> The only real issue with the "generic" TSO is that it isn't going to
> be so generic. We have different devices that will support different
> levels of stuff. For example the ixgbe drivers will need to treat the
> outer tunnel header as one giant L2 hea
On Fri, Mar 11, 2016 at 12:24 PM, Edward Cree wrote:
> On 11/03/16 20:16, Tom Herbert wrote:
>> On Fri, Mar 11, 2016 at 11:59 AM, Edward Cree wrote:
>>> On 11/03/16 19:57, Tom Herbert wrote:
On Fri, Mar 11, 2016 at 11:20 AM, Edward Cree wrote:
> Tom,
>
> Are you planning to / wo
On 11/03/16 20:16, Tom Herbert wrote:
> On Fri, Mar 11, 2016 at 11:59 AM, Edward Cree wrote:
>> On 11/03/16 19:57, Tom Herbert wrote:
>>> On Fri, Mar 11, 2016 at 11:20 AM, Edward Cree wrote:
Tom,
Are you planning to / working on implementing this? If not, I might have a
crack
On Fri, Mar 11, 2016 at 11:59 AM, Edward Cree wrote:
> On 11/03/16 19:57, Tom Herbert wrote:
>> On Fri, Mar 11, 2016 at 11:20 AM, Edward Cree wrote:
>>> Tom,
>>>
>>> Are you planning to / working on implementing this? If not, I might have a
>>> crack at it; I've talked to our firmware guys and (
On 11/03/16 19:57, Tom Herbert wrote:
> On Fri, Mar 11, 2016 at 11:20 AM, Edward Cree wrote:
>> Tom,
>>
>> Are you planning to / working on implementing this? If not, I might have a
>> crack at it; I've talked to our firmware guys and (provisionally) we think
>> we can support it in current sfc h
On Fri, Mar 11, 2016 at 11:20 AM, Edward Cree wrote:
> On 20/02/16 19:51, Tom Herbert wrote:
>> Right. To use LCO with TSO we would need to ensure that all packets
>> are the same size so that the UDP length field and thus checksum are
>> constant for all created segments. But this property this w
On 20/02/16 19:51, Tom Herbert wrote:
> Right. To use LCO with TSO we would need to ensure that all packets
> are the same size so that the UDP length field and thus checksum are
> constant for all created segments. But this property this would also
> make any payload lengths in headers constant fo
From: Tom Herbert
Date: Tue, 23 Feb 2016 08:47:30 -0800
> Right, GRO should probably not coalesce packets with non-zero IP
> identifiers due to the loss of information.
If they are monotonically increasing, which is the only case worth
caring about, it absolutely should.
Because that can be don
On 24/02/16 00:53, Tom Herbert wrote:
> That's an interesting idea. This should work in IPv6 now and nearly
> all encapsulation protocols (GRE w/ csum doesn't work this way for
> instance)
You mean GRE with sequence numbers? csum should be fine, it'sjust the
usual LCO setup (i.e. only depends on h
From: David Laight
Date: Wed, 24 Feb 2016 09:58:03 +
> From: David Miller
>> Sent: 23 February 2016 18:25
>>
>> From: Jesse Gross
>> Date: Tue, 23 Feb 2016 09:31:09 -0800
>>
>> > Most OSs (including Linux with connected TCP sockets) use non-zero IP
>> > IDs so requiring this would effectiv
From: David Miller
> Sent: 23 February 2016 18:25
>
> From: Jesse Gross
> Date: Tue, 23 Feb 2016 09:31:09 -0800
>
> > Most OSs (including Linux with connected TCP sockets) use non-zero IP
> > IDs so requiring this would effectively disable GRO.
>
> +1
>
> Any OS that wants to work with SLHC, a
> [ I really hope we can figure out a way not to change IP IDs, because I think
> an inverted version of Tom's generic TSO could also work as a generic h/w GRO
> accelerator. In its simplest form, the hardware just remembers the previous
> packet, then gives us the length of the common prefix. If
From: Edward Cree
Date: Tue, 23 Feb 2016 20:20:50 +
> So VJ implementations that can't handle it really are buggy, not
> just exhibiting a difference of opinion.
Buggy or not, they exist, and we have to cope with them.
On 23/02/16 18:08, David Miller wrote:
> From: Edward Cree
> Date: Tue, 23 Feb 2016 17:38:28 +
>
>> "The IPv4 ID field MUST NOT be used for purposes other than fragmentation
>> and reassembly."(§4.1)
>> "Originating sources MAY set the IPv4 ID field of atomic datagrams to any
>> value."(§4.1
On Tue, Feb 23, 2016 at 10:26 AM, David Miller wrote:
> From: Tom Herbert
> Date: Tue, 23 Feb 2016 09:42:00 -0800
>
>> Why not just fix the stack to conform to RFC6864? As Edward pointed
>> out we lose the actual IP ID's in GRO anyway, so attempts to set them
>> in GSO may be wildly incorrect fro
From: Tom Herbert
Date: Tue, 23 Feb 2016 09:42:00 -0800
> Why not just fix the stack to conform to RFC6864? As Edward pointed
> out we lose the actual IP ID's in GRO anyway, so attempts to set them
> in GSO may be wildly incorrect from the source point of view-- even in
> that case were probably
From: Jesse Gross
Date: Tue, 23 Feb 2016 09:31:09 -0800
> Most OSs (including Linux with connected TCP sockets) use non-zero IP
> IDs so requiring this would effectively disable GRO.
+1
Any OS that wants to work with SLHC, as I mentioned, has to emit
monotonically increasing IP ID values in all
On Tue, Feb 23, 2016 at 9:42 AM, Tom Herbert wrote:
> On Tue, Feb 23, 2016 at 9:31 AM, Jesse Gross wrote:
>> On Tue, Feb 23, 2016 at 8:47 AM, Tom Herbert wrote:
>>> On Tue, Feb 23, 2016 at 7:18 AM, Edward Cree wrote:
On 23/02/16 03:31, Jesse Gross wrote:
> The only issue that I see is
On Tue, Feb 23, 2016 at 9:38 AM, Edward Cree wrote:
> On 23/02/16 17:20, Rick Jones wrote:
>> On 02/23/2016 08:47 AM, Tom Herbert wrote:
>>> Right, GRO should probably not coalesce packets with non-zero IP
>>> identifiers due to the loss of information. Besides that, RFC6848 says
>>> the IP identi
From: Edward Cree
Date: Tue, 23 Feb 2016 17:38:28 +
> On 23/02/16 17:20, Rick Jones wrote:
>> On 02/23/2016 08:47 AM, Tom Herbert wrote:
>>> Right, GRO should probably not coalesce packets with non-zero IP
>>> identifiers due to the loss of information. Besides that, RFC6848 says
>>> the IP i
On 23/02/16 17:20, Rick Jones wrote:
> On 02/23/2016 08:47 AM, Tom Herbert wrote:
>> Right, GRO should probably not coalesce packets with non-zero IP
>> identifiers due to the loss of information. Besides that, RFC6848 says
>> the IP identifier should only be set for fragmentation anyway so there
>
On Tue, Feb 23, 2016 at 9:31 AM, Jesse Gross wrote:
> On Tue, Feb 23, 2016 at 8:47 AM, Tom Herbert wrote:
>> On Tue, Feb 23, 2016 at 7:18 AM, Edward Cree wrote:
>>> On 23/02/16 03:31, Jesse Gross wrote:
The only issue that I see is that making TSO completely unaware of
outer headers wi
On Tue, Feb 23, 2016 at 8:47 AM, Tom Herbert wrote:
> On Tue, Feb 23, 2016 at 7:18 AM, Edward Cree wrote:
>> On 23/02/16 03:31, Jesse Gross wrote:
>>> The only issue that I see is that making TSO completely unaware of
>>> outer headers will likely cause performance regressions in some cases.
>>>
On 02/23/2016 08:47 AM, Tom Herbert wrote:
Right, GRO should probably not coalesce packets with non-zero IP
identifiers due to the loss of information. Besides that, RFC6848 says
the IP identifier should only be set for fragmentation anyway so there
shouldn't be any issue and really no need for H
On Tue, Feb 23, 2016 at 7:18 AM, Edward Cree wrote:
> On 23/02/16 03:31, Jesse Gross wrote:
>> The only issue that I see is that making TSO completely unaware of
>> outer headers will likely cause performance regressions in some cases.
>> Imagine if we have an incoming TCP stream with incrementing
On 23/02/16 03:31, Jesse Gross wrote:
> The only issue that I see is that making TSO completely unaware of
> outer headers will likely cause performance regressions in some cases.
> Imagine if we have an incoming TCP stream with incrementing IP IDs
> that we aggregate through GRO and forward. Today
On Sat, Feb 20, 2016 at 11:51 AM, Tom Herbert wrote:
> On Fri, Feb 19, 2016 at 6:18 PM, Jesse Gross wrote:
>> On Fri, Feb 19, 2016 at 4:14 PM, Tom Herbert wrote:
>>> On Fri, Feb 19, 2016 at 4:08 PM, Jesse Gross wrote:
On Fri, Feb 19, 2016 at 3:10 PM, Alex Duyck wrote:
> On Fri, Feb 19
From: Alexander Duyck
Date: Fri, 19 Feb 2016 11:26:17 -0800
> This patch series makes it so that we enable the outer Tx checksum
> for IPv4 tunnels by default.
Series applied, thanks Alex.
On Fri, Feb 19, 2016 at 6:18 PM, Jesse Gross wrote:
> On Fri, Feb 19, 2016 at 4:14 PM, Tom Herbert wrote:
>> On Fri, Feb 19, 2016 at 4:08 PM, Jesse Gross wrote:
>>> On Fri, Feb 19, 2016 at 3:10 PM, Alex Duyck wrote:
On Fri, Feb 19, 2016 at 1:53 PM, Jesse Gross wrote:
> On Fri, Feb 19,
On Fri, Feb 19, 2016 at 4:14 PM, Tom Herbert wrote:
> On Fri, Feb 19, 2016 at 4:08 PM, Jesse Gross wrote:
>> On Fri, Feb 19, 2016 at 3:10 PM, Alex Duyck wrote:
>>> On Fri, Feb 19, 2016 at 1:53 PM, Jesse Gross wrote:
On Fri, Feb 19, 2016 at 11:26 AM, Alexander Duyck
wrote:
> This
On Fri, Feb 19, 2016 at 4:08 PM, Jesse Gross wrote:
> On Fri, Feb 19, 2016 at 3:10 PM, Alex Duyck wrote:
>> On Fri, Feb 19, 2016 at 1:53 PM, Jesse Gross wrote:
>>> On Fri, Feb 19, 2016 at 11:26 AM, Alexander Duyck
>>> wrote:
This patch series makes it so that we enable the outer Tx checks
On Fri, Feb 19, 2016 at 3:10 PM, Alex Duyck wrote:
> On Fri, Feb 19, 2016 at 1:53 PM, Jesse Gross wrote:
>> On Fri, Feb 19, 2016 at 11:26 AM, Alexander Duyck
>> wrote:
>>> This patch series makes it so that we enable the outer Tx checksum for IPv4
>>> tunnels by default. This makes the behavio
On Fri, Feb 19, 2016 at 1:53 PM, Jesse Gross wrote:
> On Fri, Feb 19, 2016 at 11:26 AM, Alexander Duyck wrote:
>> This patch series makes it so that we enable the outer Tx checksum for IPv4
>> tunnels by default. This makes the behavior consistent with how we were
>> handling this for IPv6. In
On Fri, Feb 19, 2016 at 11:26 AM, Alexander Duyck wrote:
> This patch series makes it so that we enable the outer Tx checksum for IPv4
> tunnels by default. This makes the behavior consistent with how we were
> handling this for IPv6. In addition I have updated the internal flags for
> these tun
37 matches
Mail list logo
