Re: [RFC net-next v2 1/9] net: napi: Add napi_storage

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 10 Sep 2024 08:16:05 +0200 Joe Damato wrote:
> > >   2. The two step "takeover" which seemed to imply that we might
> > >      pull napi_id into napi_storage? Or maybe I just read that part
> > >      wrong?  
> > 
> > Yes, the suggestion here is to drop patch #2 from your series and
> > keep napi_id as a user facing 'id' for the persistent storage. But,
> > obviously, this requires persistent napi_id(s) that survive device
> > resets.
> > 
> > The function that allocates new napi_id is napi_hash_add
> > from netif_napi_add_weight. So we can do either of the following:
> > 1. Keep everything as is, but add the napi_rehash somewhere
> >    around napi_enable to 'takeover' previously allocated napi_id.
> > 2. (preferred) Separate napi_hash_add out of netif_napi_add_weight.
> >    And have some new napi_hash_with_id(previous_napi_id) to expose it to the
> >    userspace. Then convert mlx5 to this new interface.  
> 
> Jakub is this what you were thinking too?
> 
> If this is the case, then the netlink code needs to be tweaked to
> operate on NAPI IDs again (since they are persistent) instead of
> ifindex + napi_storage index?

No strong preference on the driver facing API, TBH, your
netif_napi_add_storage() with some additional 'ifs' in the existing
functions should work.

Also no strong preference on the uAPI, avoiding adding new fields is
a little bit tempting. But if you think NAPI ID won't work or is less
clean - we can stick the index in.