On 6/12/2024 6:15 AM, Alexander Lobakin wrote:
> 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
Makes sense, thanks for the explanation.
