On Fri, Apr 22, 2022 at 08:39:18AM +0530, Kanchan Joshi wrote:
>On Thu, Apr 21, 2022 at 12:59:42PM -0600, Jens Axboe wrote:
>>On 4/21/22 12:57 PM, Pavel Begunkov wrote:
>>>On 4/21/22 19:49, Stefan Roesch wrote:
>>>>On 4/21/22 11:42 AM, Pavel Begunkov wrote:
>>>>>On 4/20/22 23:51, Jens Axboe wrote:
>>>>>>On Wed, 20 Apr 2022 12:14:39 -0700, Stefan Roesch wrote:
>>>>>>>This adds the large CQE support for io-uring. Large CQE's are 16 bytes longer.
>>>>>>>To support the longer CQE's the allocation part is changed and when the CQE is
>>>>>>>accessed.
>>>>>>>
>>>>>>>The allocation of the large CQE's is twice as big, so the allocation size is
>>>>>>>doubled. The ring size calculation needs to take this into account.
>>>>>
>>>>>I'm missing something here, do we have a user for it apart
>>>>>from no-op requests?
>>>>>
>>>>
>>>>Pavel, what started this work is the patch series "io_uring passthru over nvme" from samsung.
>>>>(https://lore.kernel.org/io-uring/20220308152105.309618-1-joshi.k@samsung.com/)
>>>>
>>>>They will use the large SQE and CQE support.
>>>
>>>I see, thanks for clarifying. I saw it used in passthrough
>>>patches, but it only got me more confused why it's applied
>>>aforehand separately from the io_uring-cmd and passthrough
>>
>>It's just applied to a branch so the passthrough folks have something to
>>base on, io_uring-big-sqe. It's not queued for 5.19 or anything like
>>that yet.
>>
>Thanks for putting this up.
>I am bit confused whether these (big-cqe) and big-sqe patches should
>continue be sent (to nvme list too) as part of next
>uring-cmd/passthrough series?
>
>And does it make sense to squash somes patches of this series; at
>high-level there is 32b-CQE support, and no-op support.

Maybe as part of v3, as there seems some scope for that (I made comments
at respective places).