Re: [PATCH net-next 02/11] net: hold netdev instance lock during ndo_setup_tc

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 11 Feb 2025 19:48:50 -0800 Stanislav Fomichev wrote:
> > The netfilter / flow table offloads don't seem to test tc_can_offload(),
> > should we make that part of the check optional in dev_setup_tc() ?
> > Add a bool argument to ignore  tc_can_offload() ?  
> 
> Let me dig into it... I was assuming that tc_can_offload() is basically
> a runtime way to signal to the core that even though the device has
> ndo_setup_tc defined, the feature can't be used.
> 
> I don't understand why some places care only about ndo_setup_tc
> while other test for both ndo_setup_tc/tc_can_offload. Do you by
> chance have any context on this? Does tc_can_offload cover only
> a subset of (TC_SETUP_BLOCK) the offload types?
> 
> The easiest way is probably just to keep calls to tc_can_offload outside,
> as is, but I was thinking that doing both ndo_setup_tc and tc_can_offload
> is a bit more safe.

Off the top of my head the feature flag was added when John pioneered
the opportunistic offload of TC classifiers. It seems to have also
propagated to switch-like Qdisc offloads. The answer is probably some
mix of historic precedent (non-switch qdisc offload like mqprio exited
way before), features which are unambiguously HW-facing, and plain
omissions.

Let's do whatever is easiest here, the series touches half of the
stack, we can't possibly clean up all encountered.. mysteries.