On Thu, 7 May 2020 18:46:43 +0200 Pablo Neira Ayuso wrote: > On Thu, May 07, 2020 at 04:49:15PM +0100, Edward Cree wrote: > > On 07/05/2020 16:32, Pablo Neira Ayuso wrote: > > > On Thu, May 07, 2020 at 03:59:09PM +0100, Edward Cree wrote: > > >> Make FLOW_ACTION_HW_STATS_DONT_CARE be all bits, rather than none, so that > > >> drivers and __flow_action_hw_stats_check can use simple bitwise checks. > > > > > > You have have to explain why this makes sense in terms of semantics. > > > > > > _DISABLED and _ANY are contradicting each other. > > No, they aren't. The DISABLED bit means "I will accept disabled", it doesn't > > mean "I insist on disabled". What _does_ mean "I insist on disabled" is if > > the DISABLED bit is set and no other bits are. > > So DISABLED | ANY means "I accept disabled; I also accept immediate or > > delayed". A.k.a. "I don't care, do what you like". > > Jiri said Disabled means: bail out if you cannot disable it. That's in TC uAPI Jiri chose... doesn't mean we have to do the same internally. > If the driver cannot disable, then it will have to check if the > frontend is asking for Disabled (hence, report error to the frontend) > or if it is actually asking for Don't care. > > What you propose is a context-based interpretation of the bits. So > semantics depend on how you accumulate/combine bits. > > I really think bits semantics should be interpreted on the bit alone > itself. These 3 paragraphs sound to me like you were arguing for Ed's approach.. > There is one exception though, that is _ANY case, where you let the > driver pick between delayed or immediate. But if the driver does not > support for counters, it bails out in any case, so the outcome in both > request is basically the same. > > You are asking for different outcome depending on how bits are > combined, which can be done, but it sounds innecessarily complicated > to me. No, quite the opposite, the code as committed to net has magic values which drivers have to check. The counter-proposal is that each bit represents a configuration, and if more than one bit is set the driver gets to choose which it prefers. What could be simpler? netfilter just has to explicitly set the field to DONT_CARE rather than depending on 0 form zalloc() coinciding with the correct value.
