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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240910075606.565fae97@kernel.org>
Date: Tue, 10 Sep 2024 07:56:06 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Joe Damato <jdamato@...tly.com>
Cc: Stanislav Fomichev <stfomichev@...il.com>, netdev@...r.kernel.org,
 mkarsten@...terloo.ca, skhawaja@...gle.com, sdf@...ichev.me,
 bjorn@...osinc.com, amritha.nambiar@...el.com, sridhar.samudrala@...el.com,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Jonathan Corbet
 <corbet@....net>, Jiri Pirko <jiri@...nulli.us>, Sebastian Andrzej Siewior
 <bigeasy@...utronix.de>, Lorenzo Bianconi <lorenzo@...nel.org>, "open
 list:DOCUMENTATION" <linux-doc@...r.kernel.org>, open list
 <linux-kernel@...r.kernel.org>
Subject: Re: [RFC net-next v2 1/9] net: napi: Add napi_storage

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.