From: Jacob Keller <[email protected]> Date: Tue, 28 May 2024 17:47:32 -0700
> > > On 5/28/2024 6:48 AM, Alexander Lobakin wrote: >> Currently, all HW supporting idpf supports the singleq model, but none >> of it advertises it by default, as splitq is supported and preferred >> for multiple reasons. Still, this almost dead code often times adds >> hotpath branches and redundant cacheline accesses. >> While it can't currently be removed, add CONFIG_IDPF_SINGLEQ and build >> the singleq code only when it's enabled manually. This corresponds to >> -10 Kb of object code size and a good bunch of hotpath checks. >> idpf_is_queue_model_split() works as a gate and compiles out to `true` >> when the config option is disabled. >> > > Could you clarify why we can't remove it? Presumably there exist some > users out there who depend on this (and can thus set the CONFIG option)? > Or is it because we intend to support some hardware which only supports > singleq sometime soon? > > This is a huge improvement over leaving it as-is, but I do wonder why > not just completely remove it. Its also a surprisingly small patch, but > I guess thats because the singleq_txrx is a separate file. I'd be happy to remove it completely, as it has bugs, makes some optimizations more difficult to do etc. But I was told there *might* be real users for it, although with no particular examples, so it can't be removed. Maybe Emil or someone else from the idpf team will finally give some ¯\_(ツ)_/¯ In general, I have no idea why one might want to use singleq when splitq is available: it's way faster (one queue is strictly RO, the other one is strictly WO -> better CL usage, less descriptor reads and writes etc.) and more flexible. XDP will be available in the splitq mode only -- it would be hell otherwise with no practical benefit. Thanks, Olek
