netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: Alexander Duyck <alexander.h.duyck@intel.com>
Cc: Dimitris Michailidis <dm@chelsio.com>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [ethtool PATCH 4/4] v5 Add RX packet classification interface
Date: Wed, 04 May 2011 19:45:38 +0100	[thread overview]
Message-ID: <1304534738.2926.74.camel@bwh-desktop> (raw)
In-Reply-To: <4DC19912.3000803@intel.com>

On Wed, 2011-05-04 at 11:21 -0700, Alexander Duyck wrote:
[...]
> Honestly what I would prefer to see is a seperate call added such as an 
> ETHTOOL_GRSCLSRLLOC that we could pass the flow specifier to and perhaps 
> include first/last location call in that and then let the driver return 
> where it wants to drop the rule.

This must not be done as a separate operation because it's racy (in fact
that's an inherent problem with the rule manager).  In the sfc driver
(and probably others in future) filters could be inserted for RFS at any
time.

> That way we can avoid having to create 
> an overly complicated rule manager that can handle all the bizarre rule 
> ordering options that I am sure all the different network devices support.

Right, the rule manager can't implement that.

> The only reason I am not implementing this now is because there aren't 
> any drivers in place that would currently use it.  I figure once cxgb 
> has a means in place of supporting flow classifier rules then Dimitris 
> can add the necessary code to ethtool and the kernel to allow the driver 
> to specify rule locations.  I would prefer to avoid adding features 
> based on speculation of what will be needed and would like to be able to 
> actually see how the features will be used.

If you are going to implement the same interface in ixgbe as in niu
(modulo bugs), then I have no objection to going ahead with this and
then adding the option for driver-assigned locations later.

Please can you confirm that the location specified for
ETHTOOL_SRXCLSRLINS will indeed be used as a priority in case of
overlapping filters?

Ben.

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


  reply	other threads:[~2011-05-04 18:45 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-03 16:12 [ethtool PATCH 0/4] Add support for network flow classifier Alexander Duyck
2011-05-03 16:12 ` [ethtool PATCH 1/4] ethtool: remove strings based approach for displaying n-tuple Alexander Duyck
2011-05-03 16:12 ` [ethtool PATCH 2/4] Cleanup defines and header includes to address several issues Alexander Duyck
2011-05-03 16:12 ` [ethtool PATCH 3/4] Add support for __be64 and bitops, centralize several needed macros Alexander Duyck
2011-05-03 16:12 ` [ethtool PATCH 4/4] v5 Add RX packet classification interface Alexander Duyck
2011-05-03 23:23   ` Dimitris Michailidis
2011-05-03 23:34     ` Ben Hutchings
2011-05-04  0:29       ` Alexander Duyck
2011-05-04  1:35         ` Dimitris Michailidis
2011-05-04  3:10           ` Alexander Duyck
2011-05-04 17:09       ` Dimitris Michailidis
2011-05-04 17:24         ` Ben Hutchings
2011-05-04 17:33           ` Dimitris Michailidis
2011-05-04 17:41             ` Alexander Duyck
2011-05-04 18:05               ` Ben Hutchings
2011-05-04 18:21                 ` Alexander Duyck
2011-05-04 18:45                   ` Ben Hutchings [this message]
2011-05-04 21:07                     ` Alexander Duyck
2011-05-04 21:54                       ` Ben Hutchings
2011-05-04 19:06                 ` Dimitris Michailidis
2011-05-04 18:18               ` Dimitris Michailidis
2011-05-04 18:35                 ` Alexander Duyck
2011-05-04 18:50                   ` 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=1304534738.2926.74.camel@bwh-desktop \
    --to=bhutchings@solarflare.com \
    --cc=alexander.h.duyck@intel.com \
    --cc=davem@davemloft.net \
    --cc=dm@chelsio.com \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=netdev@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).