Re: [net-next v5 6/9] netdev-genl: Support setting per-NAPI config values

[Eric Dumazet]

On Thu, Oct 10, 2024 at 5:19 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>
> On Thu, 10 Oct 2024 06:24:54 +0200 Eric Dumazet wrote:
> > > +static const struct netlink_range_validation netdev_a_napi_defer_hard_irqs_range = {
> > > +       .max    = 2147483647ULL,
> >
> > Would (u64)INT_MAX  work ?
>
> I sent a codegen change for this. The codegen is a bit of a mess.
>
> > > +int netdev_nl_napi_set_doit(struct sk_buff *skb, struct genl_info *info)
> > > +{
> > > +       struct napi_struct *napi;
> > > +       unsigned int napi_id;
> > > +       int err;
> > > +
> > > +       if (GENL_REQ_ATTR_CHECK(info, NETDEV_A_NAPI_ID))
> > > +               return -EINVAL;
> > > +
> > > +       napi_id = nla_get_u32(info->attrs[NETDEV_A_NAPI_ID]);
> > > +
> > > +       rtnl_lock();
> >
> > Hmm.... please see my patch there :
> >
> >  https://patchwork.kernel.org/project/netdevbpf/patch/20241009232728.107604-2-edumazet@xxxxxxxxxx/
> >
> > Lets not add another rtnl_lock() :/
>
> It's not as easy since NAPIs can come and go at driver's whim.
> I'm quietly hoping we can convert all netdev-nl NAPI accesses
> to use the netdev->lock protection I strong-armed Paolo into
> adding in his shaper series. But perhaps we can do that after
> this series? NAPI GET already takes RTNL lock.


napi_by_id() is protected by rcu and its own spinlock ( napi_hash_lock )
I do not see why rtnl is needed.
This will also be a big issue with per netns-RTNL anyway.