On 4/21/22 8:09 PM, 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@xxxxxxxxxxx/) >>>> >>>> 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? > I'll sent version 3 also to the nvme list. > And does it make sense to squash somes patches of this series; at > high-level there is 32b-CQE support, and no-op support. >
