Messages in this thread | | | From | Dave Taht <> | Date | Wed, 7 Feb 2024 09:31:33 -0500 | Subject | Re: [PATCH net-next] eth: mlx5: link NAPI instances to queues and IRQs |
| |
On Wed, Feb 7, 2024 at 9:26 AM Joe Damato <jdamato@fastly.com> wrote: > > On Wed, Feb 07, 2024 at 08:59:18AM +0200, Gal Pressman wrote: > > On 06/02/2024 21:23, Joe Damato wrote: > > >> The per queue coalesce series is going through internal code review, and is > > >> expected to also be ready in a matter of a few weeks. > > > > > > OK, great. Thanks for letting me know; we are definitely interested in > > > using this feature. > > > > Hi Joe, > > Can you please share some details about your usecase for this feature? > > It was outlined in the cover letter for the RFC [1]. > > But, briefly: we set a number of queues (say 16) via ethtool. We then > create a series of n-tuple filters directing certain flows to queues 0-7 > via a custom RSS context. The remaining queues, 8-15 are for all other > flows via the default RSS context. > > Queues 0-7 are used with busy polling from userland so we want those queues > to have a larger rx/tx-usecs rx/tx-frames than queues 8-15.
I am looking forward to trying this to chop some usec off of eBPF. I am curious as to how low can you go...
> We implemented basic support for this in the RFC we sent to the mailing > list.
thank you for re-citing this:
> [1]: https://lore.kernel.org/lkml/20230823223121.58676-1-dev@nalramli.com/
The big feature that I hope appears in some ethernet card someday the ability to map (say 16k) LPMs to a hw queue, as opposed to a mere tuple. It's the biggest overhead operation we have (presently in vectoring data via ebpf) to libreqos for 10k+ ISP subscribers.
>
-- 40 years of net history, a couple songs: https://www.youtube.com/watch?v=D9RGX6QFm5E Dave Täht CSO, LibreQos
| |