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

From: Jakub Kicinski <[email-masked]>
Date: Mon, 8 Jun 2026 16:58:26 -0700

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?