Re: [PATCH net-next v2 05/12] net: ethtool: optionally skip rtnl_lock on Netlink path for SET ops

[Jacob Keller <jacob.e.keller@intel.com>]

On 6/8/2026 4:58 PM, Jakub Kicinski wrote:
> On Mon, 8 Jun 2026 15:15:48 -0700 Jacob Keller wrote:
>>> @@ -935,7 +935,13 @@ struct kernel_ethtool_ts_info {
>>>   * these bits separate, per GET and SET. GET is much easier to "unlock".
>>>   */
>>>  #define ETHTOOL_OP_NEEDS_RTNL_LINKSETTINGS	BIT(0)
>>> -#define ETHTOOL_OP_NEEDS_RTNL_GPAUSEPARAM	BIT(1)
>>> +#define ETHTOOL_OP_NEEDS_RTNL_SPFLAGS		BIT(1)
>>> +#define ETHTOOL_OP_NEEDS_RTNL_SRINGPARAM	BIT(2)
>>> +#define ETHTOOL_OP_NEEDS_RTNL_SCHANNELS		BIT(3)
>>> +#define ETHTOOL_OP_NEEDS_RTNL_SCOALESCE		BIT(4)
>>> +#define ETHTOOL_OP_NEEDS_RTNL_GPAUSEPARAM	BIT(5)
>>> +#define ETHTOOL_OP_NEEDS_RTNL_SPAUSEPARAM	BIT(6)
>>> +#define ETHTOOL_OP_NEEDS_RTNL_RSS		BIT(7)  
>>
>> Whats the reasoning for changing order here? Is this sorted somehow?
> 
> I went back and forth on this a little but at the end I wanted the GET
> and SET bits to be next to each other (PAUSE ones specifically, that's
> the only case where phylink forces us to add a GET bit).
> 
>> Would it make more sense to use an enum to define the bits instead so
>> that patches don't have to do a -/+ of the same NAME?
> 
> We'd need to add enum for bit ids and then defines for BIT(id)?
> Dunno, personally I don't really like that. And we never switch
> on the values here so enum buys us little. Maybe BTF, that's about it?

Its fine as is. I just didn't like seeing the bit indexes requiring
change mid-series.

You could just leave the indexes as the final values, but that also
looks odd, so I think its just a choice of which oddity do you prefer.
Regardless, it is noise since the only difference is inter-patch diffs
for stuff that will all be merged at once.