Re: [PATCH net-next v4 8/9] net: ethernet: ti: am65-cpsw: add network flow classification support
From: Roger Quadros <rogerq@kernel.org>
Date: 2025-08-14 13:44:54
Also in:
linux-omap, lkml
On 13/08/2025 17:48, Jakub Kicinski wrote:
On Wed, 13 Aug 2025 16:49:27 +0300 Roger Quadros wrote:quoted
On 17/05/2025 04:29, Jakub Kicinski wrote:quoted
On Wed, 14 May 2025 15:04:28 +0300 Roger Quadros wrote:quoted
The TRM doesn't mention anything about order of evaluation of the classifier rules however it does mention in [1] "if multiple classifier matches occur, the highest match with thread enable bit set will be used."So we're not sure how to maintain the user requested ordering?Currently we are using the user/ethtool provided location as is.quoted
Am I reading this correctly? If so then ..quoted
+ if (fs->location == RX_CLS_LOC_ANY ||.. why are we rejecting LOC_ANY?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?
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. -- cheers, -roger