On Wed, Feb 7, 2024 at 9:26 AM Joe Damato <jdamato@xxxxxxxxxx> 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@xxxxxxxxxxxx/ 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
