On 27/05/2025 19:10, Jakub Kicinski wrote: > On Thu, 22 May 2025 16:19:28 -0700 Saeed Mahameed wrote: >>> Why are you modifying wanted_features? wanted_features is what >>> *user space* wanted! You should probably operate on hw_features ? >>> Tho, may be cleaner to return an error and an extack if the user >>> tries to set HDS and GRO to conflicting values. >>> >> >> hw_features is hw capabilities, it doesn't mean on/off.. so no we can't >> rely on that. >> >> To enable TCP_DATA_SPLIT we tie it to GRO_HW, so we enable GRO_HW when >> TCP_DATA_SPLIT is set to on and vise-versa. I agree not the cleanest.. >> But it is good for user-visibility as you would see both ON if you query >> from user, which is the actual state. This is the only way to set HW_GRO >> to on by driver and not lose previous state when we turn the other bit >> on/off. > > features = on > hw_features = off > > is how we indicate the feature is "on [fixed]" > Tho, I'm not sure how much precedent there is for making things fixed > at runtime. Isn't this something that should be handled through fix_features?
