On Sun, Mar 27, 2016 at 10:36 PM, Jesse Gross wrote:
> On Fri, Mar 18, 2016 at 4:25 PM, Alexander Duyck wrote:
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index edb7179bc051..666cf427898b 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -2711,6 +2711,19 @@ struct sk_buff *__skb
On Wed, Mar 23, 2016 at 7:53 PM, Alexander Duyck
wrote:
> On Wed, Mar 23, 2016 at 6:37 PM, Jesse Gross wrote:
>> That being said, I actually think that it is good to have the DF bit
>> on by default for encapsulation headers being added. Unintentional
>> (and perhaps multiple layers of) fragmenta
On Fri, Mar 18, 2016 at 4:25 PM, Alexander Duyck wrote:
> diff --git a/net/core/dev.c b/net/core/dev.c
> index edb7179bc051..666cf427898b 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2711,6 +2711,19 @@ struct sk_buff *__skb_gso_segment(struct sk_buff *skb,
[...]
> + /* Only rep
On Thu, 24 Mar 2016, Alexander Duyck wrote:
> On Thu, Mar 24, 2016 at 4:00 PM, Edward Cree wrote:
>> So: in the initial transmit path we build a coherent superframe; when we get
>> to the device, we say either "oh, device doesn't support offloads at all,
>> call GSO", or "oh, device supports this
On Thu, Mar 24, 2016 at 4:00 PM, Edward Cree wrote:
> On 24/03/16 21:50, Alexander Duyck wrote:
>> On Thu, Mar 24, 2016 at 1:17 PM, Edward Cree wrote:
>>> (Besides, I thought it was impossible for the partial checksum to be zero
>>> anyway because at least one of the inputs must be nonzero, and t
On 24/03/16 21:50, Alexander Duyck wrote:
> On Thu, Mar 24, 2016 at 1:17 PM, Edward Cree wrote:
>> (Besides, I thought it was impossible for the partial checksum to be zero
>> anyway because at least one of the inputs must be nonzero, and the end-
>> around carry can never produce a zero. But may
On Thu, Mar 24, 2016 at 1:17 PM, Edward Cree wrote:
> On 24/03/16 18:43, Alexander Duyck wrote:
>> On Thu, Mar 24, 2016 at 10:12 AM, Edward Cree wrote:
>>> For UDP header, we look to see if the current checksum field is zero. If
>>> so, we leave it as zero, fold our edits into csum_edit and retu
On 24/03/16 18:43, Alexander Duyck wrote:
> On Thu, Mar 24, 2016 at 10:12 AM, Edward Cree wrote:
>> For UDP header, we look to see if the current checksum field is zero. If
>> so, we leave it as zero, fold our edits into csum_edit and return the
>> result. Otherwise, we fold our edits and csum_e
On Thu, Mar 24, 2016 at 10:12 AM, Edward Cree wrote:
> On 23/03/16 23:15, Alexander Duyck wrote:
>> Right, but the problem becomes how do you identify what tunnel wants
>> what. So for example we could theoretically have a UDP tunnel in a
>> UDP with checksum. How would we tell which one want to
On 23/03/16 23:15, Alexander Duyck wrote:
> Right, but the problem becomes how do you identify what tunnel wants
> what. So for example we could theoretically have a UDP tunnel in a
> UDP with checksum. How would we tell which one want to have the
> checksum set and which one doesn't? The fact i
On Wed, Mar 23, 2016 at 6:37 PM, Jesse Gross wrote:
> On Wed, Mar 23, 2016 at 11:19 AM, Alexander Duyck
> wrote:
>> On Wed, Mar 23, 2016 at 10:09 AM, Tom Herbert wrote:
>>> Can you add some description about strategy for dealing with ip_id?
>>
>> Yeah. I still need to add more documentation. I
On Wed, Mar 23, 2016 at 11:19 AM, Alexander Duyck
wrote:
> On Wed, Mar 23, 2016 at 10:09 AM, Tom Herbert wrote:
>> Can you add some description about strategy for dealing with ip_id?
>
> Yeah. I still need to add more documentation. I just didn't want to
> get into details on it until we have f
On Wed, Mar 23, 2016 at 4:00 PM, Edward Cree wrote:
> On 23/03/16 22:36, Alexander Duyck wrote:
>> On Wed, Mar 23, 2016 at 2:05 PM, Edward Cree wrote:
>>> I disagree. Surely we should be able to "soft segment" the packet just
>>> before we give it to the physical device, and then tell it to do d
On 23/03/16 22:36, Alexander Duyck wrote:
> On Wed, Mar 23, 2016 at 2:05 PM, Edward Cree wrote:
>> I disagree. Surely we should be able to "soft segment" the packet just
>> before we give it to the physical device, and then tell it to do dumb copying
>> of both the VXLAN and IPIP headers? At thi
On Wed, Mar 23, 2016 at 2:05 PM, Edward Cree wrote:
> On 23/03/16 18:06, Alexander Duyck wrote:
>> On Wed, Mar 23, 2016 at 9:27 AM, Edward Cree wrote:
>>> My belief is that my way is (in the long run) simpler: ultimately it gets
>>> rid of per-protocol GSO callbacks entirely. Every header gets w
On 23/03/16 18:06, Alexander Duyck wrote:
> On Wed, Mar 23, 2016 at 9:27 AM, Edward Cree wrote:
>> My belief is that my way is (in the long run) simpler: ultimately it gets
>> rid of per-protocol GSO callbacks entirely. Every header gets written
>> correctly* when the packet initially traverses t
On Wed, Mar 23, 2016 at 10:09 AM, Tom Herbert wrote:
> On Fri, Mar 18, 2016 at 4:25 PM, Alexander Duyck wrote:
>> This patch adds support for something I am referring to as GSO partial.
>> The basic idea is that we can support a broader range of devices for
>> segmentation if we use fixed outer h
On Wed, Mar 23, 2016 at 9:27 AM, Edward Cree wrote:
> On 22/03/16 21:38, Alexander Duyck wrote:
>> On Tue, Mar 22, 2016 at 12:40 PM, Edward Cree wrote:
>>> But won't the tunnel dev have the feature flag for GSO_PARTIAL depending
>>> on what the underlying dev advertises? (Or, at least, could we
On Fri, Mar 18, 2016 at 4:25 PM, Alexander Duyck wrote:
> This patch adds support for something I am referring to as GSO partial.
> The basic idea is that we can support a broader range of devices for
> segmentation if we use fixed outer headers and have the hardware only
> really deal with segmen
On 22/03/16 21:38, Alexander Duyck wrote:
> On Tue, Mar 22, 2016 at 12:40 PM, Edward Cree wrote:
>> But won't the tunnel dev have the feature flag for GSO_PARTIAL depending
>> on what the underlying dev advertises? (Or, at least, could we make it
>> bethatway?)
> This stuff doesn't work. That is
On Tue, Mar 22, 2016 at 12:40 PM, Edward Cree wrote:
> On 22/03/16 17:47, Alexander Duyck wrote:
>> On Tue, Mar 22, 2016 at 10:00 AM, Edward Cree wrote:
>>> On 18/03/16 23:25, Alexander Duyck wrote:
This patch adds support for something I am referring to as GSO partial.
The basic idea i
From: Jesse Gross
Date: Tue, 22 Mar 2016 13:11:21 -0700
> Features that have been designed this way in the past are usually
> pretty fragile. Not only would you have to track changes in the
> routing table but you could have bridges, tc, vlan devices, etc. all
> of which might change the path of
On Tue, Mar 22, 2016 at 12:40 PM, Edward Cree wrote:
> On 22/03/16 17:47, Alexander Duyck wrote:
>> On Tue, Mar 22, 2016 at 10:00 AM, Edward Cree wrote:
>>> On 18/03/16 23:25, Alexander Duyck wrote:
This patch adds support for something I am referring to as GSO partial.
The basic idea i
On 22/03/16 17:47, Alexander Duyck wrote:
> On Tue, Mar 22, 2016 at 10:00 AM, Edward Cree wrote:
>> On 18/03/16 23:25, Alexander Duyck wrote:
>>> This patch adds support for something I am referring to as GSO partial.
>>> The basic idea is that we can support a broader range of devices for
>>> seg
On Tue, Mar 22, 2016 at 10:00 AM, Edward Cree wrote:
> On 18/03/16 23:25, Alexander Duyck wrote:
>> This patch adds support for something I am referring to as GSO partial.
>> The basic idea is that we can support a broader range of devices for
>> segmentation if we use fixed outer headers and have
On 18/03/16 23:25, Alexander Duyck wrote:
> This patch adds support for something I am referring to as GSO partial.
> The basic idea is that we can support a broader range of devices for
> segmentation if we use fixed outer headers and have the hardware only
> really deal with segmenting the inner
This patch adds support for something I am referring to as GSO partial.
The basic idea is that we can support a broader range of devices for
segmentation if we use fixed outer headers and have the hardware only
really deal with segmenting the inner header. The idea behind the naming
is due to the
27 matches
Mail list logo
