On Thu, 14 Aug 2025 16:44:49 +0300 Roger Quadros wrote:

quoted

quoted

Because driver doesn't have logic to decide the location and relies on ethtool to
decide it if user doesn't supply it.  

The location supplied by the user may have semantic significance.
IOW locations may be interpreted as priorities.  

OK. Is there any convention on location vs priority for user or it is driver dependent?
i.e. Does higher location mean higher priority?

/**
 * struct ethtool_rx_flow_spec - classification rule for RX flows
[...]
 * @location: Location of rule in the table.  Locations must be
 *	numbered such that a flow matching multiple rules will be
 *	classified according to the first (lowest numbered) rule.
 */

quoted

It's better to support LOC_ANY and add the 10 lines of code to
allocate the id in the driver..  

OK.

I did more tests and it seems that higher locations in the classifier override the lower locations.

With this new information, what is the best approach?

I can add support for LOC_ANY with logic to find first available free location.
If driver supports LOC_ANY, does driver also need to support explicit
location supplied by user? In this case I think user convention and
driver convention of location vs priority must match.

If your device supports ordering then it's up to you.
LOC_ANY has slight performance advantage, because CLI doesn't have 
to dump all the rules to find an unused ID. But I'm mostly concerned
about the semantics, the performance thing may not matter, depending
on how many rules you can support in the first place.. up to you.