lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 25 Feb 2010 21:26:38 -0500
From:	Jeff Garzik <>
To:	"Waskiewicz Jr, Peter P" <>
	"Kirsher, Jeffrey T" <>,
	"" <>,
	"" <>
Subject: Re: [ethtool PATCH] ethtool: Support n-tuple filter programming

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<>
>>> 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<>
>>> Signed-off-by: Jeff Kirsher<>
>>> ---
>>>    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.


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists