Subject: Re: [ethtool PATCH] ethtool: Support n-tuple filter programming

From: Jeff Garzik <[email-masked]>
Date: Thu, 25 Feb 2010 21:26:38 -0500

On 02/25/2010 08:49 PM, Waskiewicz Jr, Peter P wrote:
> On Wed, 24 Feb 2010, Jeff Garzik wrote:
>
>> On 02/04/2010 02:51 AM, Jeff Kirsher wrote:
>>> From: Peter Waskiewicz<[email-masked]>
>>>
>>> Program underlying ethernet devices with n-tuple flow classification
>>> filters.
>>>
>>> This also adds a new flag to ethtool_flags, allowing n-tuple
>>> programming to be toggled using the set_flags call.
>>>
>>> Signed-off-by: Peter P Waskiewicz Jr<[email-masked]>
>>> Signed-off-by: Jeff Kirsher<[email-masked]>
>>> ---
>>>
>>>    ethtool-copy.h |   35 +++++++++++++
>>>    ethtool.c      |  156 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>>>    2 files changed, 186 insertions(+), 5 deletions(-)
>>
>> applied, but two problems remain:
>>
>> 1) you failed to document this in the man page.  I will expect a patch
>> to ethtool.8.
>>
>> 2) you introduced a deviation from the upstream kernel ethtool.h:
>
> The way I've come up with to fix this is less intrusive than I want, but I
> think it's right way to do it.  The intent wasn't to have ethtool
> (userspace) enforce how many filters could be returned.  What it should do
> is get the number of strings through drvinfo to make the proper memory
> allocation.
>
> What I need to change is the drvinfo struct in the kernel to include the
> ethtool strings field, returned from get_sset_count().  Then I can pull
> that into userspace and make the correct memory allocation, then call
> get_rx_ntuple().

I would say we need a ETHTOOL_GSTRINGS_COUNT rather than expanding 
drvinfo anymore...  but yeah, expanding drvinfo would work too.

> This will require a small kernel change.  Will something like this be
> pulled in at this point, given that 2.6.33 just released?

The n-tuple stuff is not in 2.6.33's ethtool interface, so it hasn't 
actually made it into a released kernel at this point.

It seems reasonable for 2.6.34 to either add ETHTOOL_GSTRINGS_COUNT or 
update drvinfo.  Even if net-next has already been pulled into 
post-2.6.33 merge window, that would IMO qualify as a reasonable 
interface bugfix to get upstream.  The ethtool n-tuple ABI is not locked 
into stone until 2.6.34 is released by Linus.

	Jeff