Message-ID: <CANr6G5zVA=hZLuo5Z2MaXy9A7zzt1-3RQCAS6aZY2iFudOGfYQ@mail.gmail.com>
Date:	Thu, 4 Dec 2014 10:41:34 -0800
From:	Joe Stringer <joestringer@...ira.com>
To:	Jesse Gross <jesse@...ira.com>
Cc:	Tom Herbert <therbert@...gle.com>, netdev <netdev@...r.kernel.org>,
	Shannon Nelson <shannon.nelson@...el.com>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	"linux.nics" <linux.nics@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv2 net] i40e: Implement ndo_gso_check()

On 2 December 2014 at 10:26, Jesse Gross <jesse@...ira.com> wrote:
> On Mon, Dec 1, 2014 at 4:09 PM, Tom Herbert <therbert@...gle.com> wrote:
>> On Mon, Dec 1, 2014 at 3:53 PM, Jesse Gross <jesse@...ira.com> wrote:
>>> On Mon, Dec 1, 2014 at 3:47 PM, Tom Herbert <therbert@...gle.com> wrote:
>>>> On Mon, Dec 1, 2014 at 3:35 PM, Joe Stringer <joestringer@...ira.com> wrote:
>>>>> On 21 November 2014 at 09:59, Joe Stringer <joestringer@...ira.com> wrote:
>>>>>> On 20 November 2014 16:19, Jesse Gross <jesse@...ira.com> wrote:
>>>>>>> I don't know if we need to have the check at all for IPIP though -
>>>>>>> after all the driver doesn't expose support for it all (actually it
>>>>>>> doesn't expose GRE either). This raises kind of an interesting
>>>>>>> question about the checks though - it's pretty easy to add support to
>>>>>>> the driver for a new GSO type (and I imagine that people will be
>>>>>>> adding GRE soon) and forget to update the check.
>>>>>>
>>>>>> If the check is more conservative, then testing would show that it's
>>>>>> not working and lead people to figure out why (and update the check).
>>>>>
>>>>> More concretely, one suggestion would be something like following at
>>>>> the start of each gso_check():
>>>>>
>>>>> +       const int supported = SKB_GSO_TCPV4 | SKB_GSO_TCPV6 | SKB_GSO_FCOE |
>>>>> +                             SKB_GSO_UDP | SKB_GSO_UDP_TUNNEL;
>>>>> +
>>>>> +       if (skb_shinfo(skb)->gso_type & ~supported)
>>>>> +               return false;
>>>>
>>>> This should already be handled by net_gso_ok.
>>>
>>> My original point wasn't so much that this isn't handled at the moment
>>> but that it's easy to add a supported GSO type but then forget to
>>> update this check - i.e. if a driver already supports UDP_TUNNEL and
>>> adds support for GRE with the same constraints. It seems not entirely
>>> ideal that this function is acting as a blacklist rather than a
>>> whitelist.
>>
>> Agreed, it would be nice to have all the checking logic in one place.
>> If all the drivers end up implementing ndo_gso_check then we could
>> potentially get rid of the GSO types as features. This probably
>> wouldn't be a bad thing since we already know that the features
>> mechanism doesn't scale (for instance there's no way to indicate that
>> certain combinations of GSO types are supported by a device).
>
> This crossed my mind and I agree that it's pretty clear that the
> features mechanism isn't scaling very well. Presumably, the logical
> extension of this is that each driver would have a function that looks
> at a packet and returns a set of offload operations that it can
> support rather than exposing a set of protocols. However, it seems
> like it would probably result in a bunch of duplicate code in each
> driver.

Given the discussion is still pretty open-ended, I've made the basic
feedback changes for v3 and haven't tried to address the concern about
forgetting to update this check when a driver adds support.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists