On 27/02/2025 15:29, Jakub Kicinski wrote:
On Thu, 27 Feb 2025 15:18:47 +0000 Edward Cree wrote:
quoted
On 27/02/2025 04:45, Jakub Kicinski wrote:
quoted
The ordering guarantees of ntuple filters are a bit unclear.
My understanding was that first match terminates the search,
actually, so your example wouldn't work :S
My understanding is that in most ntuple implementations more-
specific filters override less-specific ones, in which case
Gal's setup would work.
The behavior of partially overlapping rules being undefined?
In the general case yes; for our implementation I think there's
a total order of match masks defined by firmware that extends
the partial order from the subset relation. (Unlike our MAE
implementation for *TC* rules on ef100, where it really is
undefined.)
I never uttered the thought that lead me to opposing.
ctx 0 is a poor man's pass / accept. If someone needs a pass we should
add an explicit "action pass".
To me 'pass' is just a shorthand for whatever specific behaviour
happens to match the default. I.e. if you can already express
that behaviour directly, then 'pass' is a strictly nonorthogonal
addition and therefore bad interface design.
But then, I'm the guy who thinks ed(1) is a good UI, so...
Or am I missing something magical that
ctx 0 would do that's not 100% the same as pass (modulo the queue
offset)?
Nothing comes to mind.
Using ctx 0 as implicit pass is a very easy thing to miss
for driver developers.
I don't see why drivers need anything special to handle "0 is
pass". They need to handle "0 isn't in the xarray" (so map it
to the default HW context), which I suppose we ought to call out
explicitly in the struct ethtool_rxnfc kdoc if we're going to
continue allowing it, but it's not the fact that it's "an
implicit pass" that makes this necessary. If there's something
I'm missing here please educate me :)