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: <4D7138EF.7050606@intel.com>
Date:	Fri, 04 Mar 2011 11:09:35 -0800
From:	Alexander Duyck <alexander.h.duyck@...el.com>
To:	Ben Hutchings <bhutchings@...arflare.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 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.  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.  In addition there are 
options such as location which exist in network flow classifier rules, 
but not in ntuple rules.

Thanks,

Alex

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