All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: Santwona Behera <santwona.behera@sun.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [ethtool PATCH 2/2] Add RX packet classification interface
Date: Fri, 04 Mar 2011 11:09:35 -0800	[thread overview]
Message-ID: <4D7138EF.7050606@intel.com> (raw)
In-Reply-To: <1298939712.2569.43.camel@bwh-desktop>

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


  reply	other threads:[~2011-03-04 19:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-11  1:18 [ethtool PATCH 0/2] Add support for RX network flow classifier rules Alexander Duyck
2011-02-11  1:18 ` [ethtool PATCH 1/2] Add macro for displaying [value N] formatting to manpage Alexander Duyck
2011-02-21 14:45   ` Ben Hutchings
2011-02-11  1:18 ` [ethtool PATCH 2/2] Add RX packet classification interface Alexander Duyck
2011-02-21 15:40   ` Ben Hutchings
2011-02-22 20:52     ` Alexander Duyck
2011-03-01  0:35       ` Ben Hutchings
2011-03-04 19:09         ` Alexander Duyck [this message]
2011-03-07 15:57           ` Ben Hutchings
2011-03-07 17:04             ` Alexander Duyck
2011-03-07 17:57               ` Ben Hutchings
2011-03-07 18:22                 ` Dimitris Michailidis
2011-03-07 18:28                   ` Ben Hutchings
2011-03-07 18:43                     ` Alexander Duyck
2011-03-07 18:57                       ` Dimitris Michailidis
2011-03-07 19:00                       ` Ben Hutchings
2011-03-07 19:11                         ` Dimitris Michailidis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D7138EF.7050606@intel.com \
    --to=alexander.h.duyck@intel.com \
    --cc=bhutchings@solarflare.com \
    --cc=netdev@vger.kernel.org \
    --cc=santwona.behera@sun.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.