netdev - Re: [ethtool PATCH 2/2] Add RX packet classification interface

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1299513430.2522.9.camel@bwh-desktop>
Date:	Mon, 07 Mar 2011 15:57:10 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Alexander Duyck <alexander.h.duyck@...el.com>
Cc:	Santwona Behera <santwona.behera@....com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [ethtool PATCH 2/2] Add RX packet classification interface

On Fri, 2011-03-04 at 11:09 -0800, Alexander Duyck wrote:
> On 2/28/2011 4:35 PM, Ben Hutchings wrote:
> > On Tue, 2011-02-22 at 12:52 -0800, Alexander Duyck wrote:
> 
> [...]
> 
> >>>>                                 } else
> >>>>                                         show_usage(1);
> >>>>                                 break;
> >>>
> >>> I don't think the same options (-n, -N) should be used both for flow
> >>> hashing and n-tuple flow steering/filtering.  This command-line
> >>> interface and the structure used in the ethtool API just seem to reflect
> >>> the implementation in the niu driver.
> >>>
> >>> (In fact I would much prefer it if the -u and -U options could be used
> >>> for both the rxnfc and rxntuple interfaces.  But I haven't thought about
> >>> how the differences in functionality would be exposed to or hidden from
> >>> the user.)
> >>
> >> I was kind of thinking about merging the two interfaces too, but I was
> >> looking at it more from the perspective of moving away from ntuple more
> >> towards this newer interface.  My main motivation being that the filter
> >> display option is so badly broken for ntuple that it would be easier to
> >> make ntuple a subset of the flow classifier instead of the other way around.
> >>
> >> What would you think of using the "flow-type" keyword to indicate legacy
> >> ntuple support, and then adding something like "class-rule-add", and
> >> "class-rule-del" to add support for the network flow classifier calls?
> >
> > I really don't want to introduce different syntax for functionality that
> > is common between the two command sets.  The user should not have to
> > know that driver A implements interface I and driver B implements
> > interface J, except that since version 2.6.y driver A implements
> > interface J too.
> >
> > Surely it is possible to try one interface, then the other, when the
> > requested filter can be implemented either way?
> 
> The problem is that the interfaces are different in the way they 
> implement their masks.  N-tuple defines the mask as 0s mean inclusion, 
> 1s, mean exclusion.

You have got to be kidding me!

If this is the case, then the current kernel-doc for
ethtool_rx_flow_spec::m_u is incorrect.

> The network flow classifier filters are the exact 
> opposite.  As such we really need to know which type of filter we are 
> dealing with before we start setting up values.

This is nonsense; it's not hard to flip the bits later.

> In addition there are 
> options such as location which exist in network flow classifier rules, 
> but not in ntuple rules.

Sure, and when those are specified then there can be no fallback.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
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