Re: [PATCH net-next 0/3] Add support to do threaded napi busy poll

[Joe Damato <jdamato@fastly.com>]

On Thu, Jan 02, 2025 at 04:47:14PM -0800, Jakub Kicinski wrote:
> On Thu,  2 Jan 2025 19:12:24 +0000 Samiullah Khawaja wrote:
> > Extend the already existing support of threaded napi poll to do continuous
> > busypolling.
> > 
> > This is used for doing continuous polling of napi to fetch descriptors from
> > backing RX/TX queues for low latency applications. Allow enabling of threaded
> > busypoll using netlink so this can be enabled on a set of dedicated napis for
> > low latency applications.
> 
> This is lacking clear justification and experimental results
> vs doing the same thing from user space.

Apologies for chiming in late here as I was out of the office, but I
agree with Jakub and Stanislav:

- This lacks clear justification and data to compare packet delivery
  mechanisms. IMHO, at a minimum a real world application should be
  benchmarked and various packet delivery mechanisms (including this
  one) should be compared side-by-side. You don't need to do exactly
  what Martin and I did [1], but I'd offer that as a possible
  suggestion for how you might proceed if you need some suggestions.

- This should include a test of some sort; perhaps expanding the test
  I added (as Stanislav suggested) would be a good start?

- IMHO, this change should also include updated kernel documentation
  to clearly explain how, when, and why a user might use this and
  what tradeoffs a user can expect. The commit message is, IMHO, far
  too vague.

  Including example code snippets or ynl invocations etc in the
  kernel documentation would be very helpful.

> I'd also appreciate if Google could share the experience and results
> of using basic threaded NAPI _in production_.

+1; this data would be very insightful.

[1]: https://lore.kernel.org/netdev/20241109050245.191288-1-jdamato@fastly.com/