Hi Jakub,
On 6/13/24 1:04 AM, Jakub Kicinski wrote:
On Sun, 9 Jun 2024 17:33:50 +0000 Asbjørn Sloth Tønnesen wrote:
Now that all drivers properly rejects unsupported flower control flags
used with FLOW_DISSECTOR_KEY_CONTROL, then time has come to add similar
checks to the drivers supporting FLOW_DISSECTOR_KEY_ENC_CONTROL.
Thanks for doing this work!
Thank you, for maintaining the tree!
Do you have any more of such series left?
Not at the moment, I only stumbled upon this, because I read the code
with an eye on adding a new IS_JUMBO_FRAME flag (patches for which are
almost ready).
Once this[1] currently RFC patch goes in, I might try to move all
control flags in under FLOW_DIS_F_*, to get rid of the then
FLOW_DIS_(IS_FRAGMENT|FIRST_FRAG|ENCAPSULATION|F_*).
[1] [RFC PATCH net-next 1/9] net/sched: flower: define new tunnel flags
https://lore.kernel.org/netdev/20240611235355.177667-2-...@fiberby.net/
Could we perhaps consider
recording the driver support somewhere in struct net_device and do
the rejecting in the core?
Sure, it could work for the control flags, and used_keys validation,
but I am not sure if it is worth it, as most of the validation is
very specific to the limitations of the different hardware. An easy
first step in that direction would be to move the used_keys checks
behind a helper, and possibly storing used_keys in struct net_device.
That's much easier to extend when adding
new flags than updating all the drivers.
That's how it is now, with the new helpers, as all flags are
unsupported, unless the driver specifically supports it.
Any new flag only needs to be added to the core, and drivers only needs
to be updated when they implement offloading support for a flag.
This series I think may not be a great first candidate as IIUC all
drivers would reject so the flag would be half-dead...
Correct. I don't know if there is any hardware support planned for the
tunnel-related encapsulation control flags.
--
Best regards
Asbjørn Sloth Tønnesen
Network Engineer
Fiberby - AS42541
