[PATCH 0/1] nvmet: add basic in-memory backend support

[Chaitanya Kulkarni]

Christoph,


On 11/6/25 03:50, hch at lst.de wrote:
> On Thu, Nov 06, 2025 at 01:20:41AM +0000, Chaitanya Kulkarni wrote:
>> Hi Hannes and Christoph,
>>
>>
>> On 11/5/25 05:14, hch at lst.de wrote:
>>> But what is the use that requires removing all that overhead / indirection?
>>>
>>> I think you need to describe that very clearly to make a case.  And
>>> maybe drop a lot of the marketing sounding overly dramatatic language
>>> that really does not help the case.
>> the quantitative data that proves removing all overhead/indirection
>> gives better performance for nvmet-mem-backend against null_blk
>> membacked and brd. Here is the link for the comparative data :-
> But what is the use case?  Why do you care about performance of a
> non-persistent DRAM-bound backend?
>
1. From cover letter:
    Workloads requiring dynamic allocation of high-performance temporary
    storage:
    - AI/ML training scratch space for checkpointing and intermediate data
    - Data analytics shuffle storage
    - In-memory database overflow
    - Target resources are exported and assigned to Host VMs as backend
      storage. Fast ephemeral storage allows VMs to access remote DRAM
      via NVMeOF building remote backend storage and associated scratch
      space under one Subsystem with a controller in it.

    These need sub-millisecond namespace creation via NVMe-oF without
    traditional storage provisioning or infra.

2. Migration from LIO target:
    Deployments migrating from LIO to NVMe-oF need equivalent functionality.
    LIO has supported memory backend (target_core_rd) since inception for
    efficient host access to target DRAM resources. Applications using LIO
    require this when moving to NVMe-oF target.

    LIO target_core_rd has never been removed -> active production use.

3. Performance improvement impact on TCO calculations:
    Hannes's comment that brd and null_blk will continue to work is only
    partially correct, but at measurably lower performance.

    It also creates a misleading impression of the maximum performance
    achievable (wrong TCO calculations) when using NVMe-oF targets with
    DRAM:

    brd:         randread  6-11% degradation vs nvmet-mem (avg 3)
                 randwrite 4-8%  degradation vs nvmet-mem (avg 3)

    null_blk:    randread  10-14% degradation vs nvmet-mem (avg 3)
                 randwrite 9%     degradation vs nvmet-mem (avg 3)

    I don't have access to all brd/null_blk with NVMe-oF deployments,
    but significant improvement with reduced overhead will get
    improved and right TCO numbers.

4. Why we should care ?
    Kernel implementations should be highly optimized - something
    evident from all micro-optimization patches I've reviewed. As compare
    to that this is 10x perf improvement. Hence we should move all existing
    NVMeOF brd/null_blk users to native nvme-mem backend.

Please let me know what else I can provide to help this.

-ck