[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D75225B.3010008@chelsio.com>
Date: Mon, 07 Mar 2011 10:22:19 -0800
From: Dimitris Michailidis <dm@...lsio.com>
To: Ben Hutchings <bhutchings@...arflare.com>
CC: Alexander Duyck <alexander.h.duyck@...el.com>,
Santwona Behera <santwona.behera@....com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [ethtool PATCH 2/2] Add RX packet classification interface
Ben Hutchings wrote:
> On Mon, 2011-03-07 at 09:04 -0800, Alexander Duyck wrote:
>> The only time where location really matters is if you are attempting to
>> overwrite an existing rule and I am not sure how that would be handled
>> in ntuple anyway since right now adding additional rules via ntuple for
>> ixgbe just results in duplicate rules being defined.
>
> As I understand it, the location also determines the *priority* for the
> rule.
This is true, at least for TCAMs. But it's relevant only when multiple
filters would match a packet. People often use non-overlapping filters, for
these adding the filter at any available slot is OK.
> Which is why I wrote that "@fs.@...ation specifies the index to
> use and must not be ignored."
>
> To support hardware where the filter table is hash-based rather than a
> TCAM, we would need some kind of flag or special value of location that
> means 'wherever'.
I'd find the 'wherever' option useful for TCAMs too. Maybe even have a few
of those, like 'first available', 'any', and 'last available'. The last one
is quite useful for catch-all rules without requiring one to know the TCAM size.
--
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
Powered by blists - more mailing lists