Thread (15 messages) 15 messages, 6 authors, 2010-06-22

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

From: Jeff Garzik <hidden>
Date: 2010-02-26 02:26:42

On 02/25/2010 08:49 PM, Waskiewicz Jr, Peter P wrote:
On Wed, 24 Feb 2010, Jeff Garzik wrote:
quoted
On 02/04/2010 02:51 AM, Jeff Kirsher wrote:
quoted
From: Peter Waskiewicz<redacted>

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

   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

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help