[PATCH 0/2] Unprivileged sgl-only passthrough

[Jens Axboe]

On 10/18/23 1:44 PM, Kanchan Joshi wrote:
> On Thu, Oct 19, 2023 at 1:05?AM Keith Busch <kbusch at kernel.org> wrote:
>>
>> On Wed, Oct 18, 2023 at 12:40:35PM -0600, Jens Axboe wrote:
>>> On 10/18/23 12:30 PM, Kanchan Joshi wrote:
>>>> Patch 1: Prep. Adds the meta-transfer ability in nvme-pci
>>>> Patch 2: Enables fine-granular passthrough with the change that i/o
>>>> commands can transfer the data only via SGL.
>>>>
>>>> Requirement:
>>>> - Prepared against block 6.6 tree.
>>>> - The patch in uring-passthrough failure handling is required to see the
>>>>   submission failure (if any)
>>>>   https://lore.kernel.org/linux-nvme/20231018135718.28820-1-joshi.k@samsung.com/
>>>
>>> I didn't have time to follow the previous discussion, but what's the
>>> reasoning behind allowing it for SGL only? IIRC, we do have an inline
>>> vec for a small number of vecs, so presumably this would not hit
>>> alloc+free for each IO? But even so, I would imagine that SGL is slower
>>> than PRP? Do we know how much?
>>
>> SGL for metadata is definitely slower, but it's the only nvme protocol
>> way to directly specify how much memory is actually available for the
>> command's transfer. PRP/MPTR vs SGL is like strcpy() vs strncpy().
>>
>> Similiar to Kanchan's earlier experience though, I haven't found real
>> nvme devices that support the SGL mode for metadata. The scenarios this
>> enables might be pretty limited. :(
> 
> What I found later was that - all the enterprise drives (of samsung)
> support SGL for data/meta.
> I have tested this code on one such SSD and on QEMU.

Maybe a moot point given the status of the product, but it does look
like the gen2 optanes at least do support SGL for metadata.

-- 
Jens Axboe