[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZyD5Ntx_DwnQj47e@LQ3V64L9R2>
Date: Tue, 29 Oct 2024 08:03:18 -0700
From: Joe Damato <jdamato@...tly.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, namangulati@...gle.com, edumazet@...gle.com,
amritha.nambiar@...el.com, sridhar.samudrala@...el.com,
sdf@...ichev.me, peter@...eblog.net, m2shafiei@...terloo.ca,
bjorn@...osinc.com, hch@...radead.org, willy@...radead.org,
willemdebruijn.kernel@...il.com, skhawaja@...gle.com,
kuba@...nel.org, Alexander Lobakin <aleksander.lobakin@...el.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
"open list:BPF [MISC] :Keyword:(?:b|_)bpf(?:b|_)" <bpf@...r.kernel.org>,
Christian Brauner <brauner@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Donald Hunter <donald.hunter@...il.com>, Jan Kara <jack@...e.cz>,
Jesper Dangaard Brouer <hawk@...nel.org>,
Jiri Pirko <jiri@...nulli.us>,
Johannes Berg <johannes.berg@...el.com>,
Jonathan Corbet <corbet@....net>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
"open list:FILESYSTEMS (VFS and infrastructure)" <linux-fsdevel@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>,
Lorenzo Bianconi <lorenzo@...nel.org>,
Martin Karsten <mkarsten@...terloo.ca>,
Mina Almasry <almasrymina@...gle.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Xuan Zhuo <xuanzhuo@...ux.alibaba.com>
Subject: Re: [PATCH net-next v2 0/6] Suspend IRQs during application busy
periods
On Tue, Oct 29, 2024 at 11:25:18AM +0100, Paolo Abeni wrote:
> On 10/21/24 03:52, Joe Damato wrote:
> > Greetings:
> >
> > Welcome to v2, see changelog below.
[...]
>
> The changes makes sense to me, and I could not find any obvious issue in
> the patches.
Thanks for taking a look.
> I think this deserve some - even basic - self-tests coverage. Note that
> you can enable GRO on veth devices to make NAPI instances avail there.
>
> Possibly you could opt for a drivers/net defaulting to veth usage and
> allowing the user to select real H/W via env variables.
Could we send a selftest in a follow up?
I am asking because we've jumped through a number of hoops to get to
this point:
1. Added support for per-NAPI config settings [1] to address Eric's
concern in the v1, which took several revisions and was stalled
due to a merge window.
2. Added support for netdev-genl to numerous drivers so that this
would be usable in many different environments (gve, ena, tg3,
e1000, e1000e, igc...) [2] [3] [4] [5] [6]
3. We didn't get any feedback about adding a selftest in the RFC
or v1 [7].
I think all busy poll methods currently in the kernel need selftests
(including the existing busy poll method) and its not clear to me
currently how much work it'll be to get veth or netdevsim working to
a point where we could re-submit this with a selftest that would be
considered reasonable enough.
FWIW, neither my previous series on the epoll ioctl nor the per NAPI
settings were rejected due to lack of selftests, but I did add a
simple selftest for the epoll ioctl later [8].
What do you think?
Could we get this merged without having to get selftests working and
come back with a selftest as separate change (like I did for the
epoll ioctl) ?
[1]: https://lore.kernel.org/lkml/20241011184527.16393-1-jdamato@fastly.com/
[2]: https://lore.kernel.org/lkml/20240930210731.1629-1-jdamato@fastly.com/
[3]: https://lore.kernel.org/lkml/20241002001331.65444-1-jdamato@fastly.com/
[4]: https://lore.kernel.org/netdev/20241009175509.31753-1-jdamato@fastly.com/
[5]: https://lore.kernel.org/netdev/20240930171232.1668-1-jdamato@fastly.com/
[6]: https://lore.kernel.org/lkml/20241028195243.52488-1-jdamato@fastly.com/
[7]: https://lore.kernel.org/all/20240823173103.94978-1-jdamato@fastly.com/
[8]: https://lore.kernel.org/netdev/171528362770.20134.14528995105510778643.git-patchwork-notify@kernel.org/T/
Powered by blists - more mailing lists