netdev - Re: net: RFC ethtool 5-tuple filter set/get feature

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 17 Dec 2008 02:55:59 -0800 (Pacific Standard Time)
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	David Miller <davem@...emloft.net>
cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Santwona.Behera@....COM" <Santwona.Behera@....COM>,
	"Matheos.Worku@....COM" <Matheos.Worku@....COM>
Subject: Re: net: RFC ethtool 5-tuple filter set/get feature

On Mon, 15 Dec 2008, David Miller wrote:

> From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
> Date: Mon, 15 Dec 2008 18:52:07 -0800 (Pacific Standard Time)
> 
> > I am looking at current methods to support adding 5-tuple filters to a 
> > network device.  3 methods I can see are 1) Creating a sysfs interface, 2) 
> > writing a custom application using netlink or some other interface, or 3) 
> > Adding support to ethtool.
> 
> I'm pretty sure ethtool is the best mechanism currently.

I'm glad.  I was targeting that, but wanted community confirmation.  :-)

> 
> > The latest ethtool bits support the rxhash callbacks, allowing different 
> > Rx hashing methods to be enabled or disabled in Sun's Neptune device.  I 
> > would like to add similar options to ethtool to support features in 
> > current versions of igb hardware, and in future ixgbe hardware.
> 
> You could extend the existing RXHASH ethtool thing, adding your
> key specifiers and some capability flags.
> 
> Actually, the Neptune folks (Santwona and Matheos CC:'d) are working
> on ethtool interfaces to load TCAM entries, which would specify the
> same things (except be a lot more flexible, multiple entries can be
> loaded into Neptune, up to 128 or 256, with all kinds of masking etc.)

Future ixgbe-supported hardware can support 128 entries to start, and then 
has another mode to support 8192 entries, plus masking on each field.  igb 
supports 8 entries today (not many Rx queues at 1G...), so it's a subset.  
So I think my needs would definately be satisfied with the work being 
proposed.

> We could represent igb/ixgbe as a TCAM with one entry and no
> masking support.  Or something like that.

If that's for a first cut, sure thing.  But ixgbe will require full 
masking support in the future.  We can take care of this when the need 
arises if it doesn't exist out of the gate.

> You can find their proposal by looking for "Interface proposal for rx
> classification using ethtool" subject in the netdev archives for
> September 2008.  I believe it was posted on the 29th.

I found the thread, and am echo'ing the same question that was posted last 
to that thread.  What's the state of the patches?  I know there was a 
target of mid-November to submit a new patchset, but I'm also sensitive 
that priorities shift day to day, let alone month to month.  I'm ready to 
work on this, and have some early code chunks if needed.  I will hold off 
on posting anything until the Sun folks have a chance to respond, since I 
don't want to cloud their efforts by posting my patches.

Cheers,
-PJ Waskiewicz
<peter.p.waskiewicz.jr@...el.com>
--
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