search for: target_core_nvme

...uot;LIO NVMe target" can support frontend driver talk to backend driver directly with NVMe commands without translation. Am I wrong? > > As with the nvme-over-fabric case, it would be possible to do a mapping > between backend driver queue resources for real NVMe hardware (eg: > target_core_nvme), but since it would still be doing close to the same > amount of software emulation for both backend driver cases, I wouldn't > expect there to be much performance advantage over just using normal > submit_bio(). > > --nab >

...uot;LIO NVMe target" can support frontend driver talk to backend driver directly with NVMe commands without translation. Am I wrong? > > As with the nvme-over-fabric case, it would be possible to do a mapping > between backend driver queue resources for real NVMe hardware (eg: > target_core_nvme), but since it would still be doing close to the same > amount of software emulation for both backend driver cases, I wouldn't > expect there to be much performance advantage over just using normal > submit_bio(). > > --nab >

On Wed, 2015-09-16 at 23:10 -0700, Nicholas A. Bellinger wrote: > Hi Ming & Co, > > On Thu, 2015-09-10 at 10:28 -0700, Ming Lin wrote: > > On Thu, 2015-09-10 at 15:38 +0100, Stefan Hajnoczi wrote: > > > On Thu, Sep 10, 2015 at 6:48 AM, Ming Lin <mlin at kernel.org> wrote: > > > > These 2 patches added virtio-nvme to kernel and qemu, > > >

On Wed, 2015-09-16 at 23:10 -0700, Nicholas A. Bellinger wrote: > Hi Ming & Co, > > On Thu, 2015-09-10 at 10:28 -0700, Ming Lin wrote: > > On Thu, 2015-09-10 at 15:38 +0100, Stefan Hajnoczi wrote: > > > On Thu, Sep 10, 2015 at 6:48 AM, Ming Lin <mlin at kernel.org> wrote: > > > > These 2 patches added virtio-nvme to kernel and qemu, > > >

...e host interface emulation in kernel code, and would be able to decode nvme Read/Write/Flush operations and translate -> submit to existing backend drivers. As with the nvme-over-fabric case, it would be possible to do a mapping between backend driver queue resources for real NVMe hardware (eg: target_core_nvme), but since it would still be doing close to the same amount of software emulation for both backend driver cases, I wouldn't expect there to be much performance advantage over just using normal submit_bio(). --nab

...d drivers. This doesn't apply to PSCSI backend driver of course, because it expects to process actual SCSI CDBs. > But I thought the future "LIO NVMe target" can support frontend driver > talk to backend driver directly with NVMe commands without translation. > The native target_core_nvme backend driver is not processing nvme commands per-say, but simply exposing nvme hardware queue resources to a frontend fabric driver. For the nvme-over-fabrics case, backend nvme submission/complete queues are mapped to RDMA hardware queues. So essentially the nvme physical region page (PRP) is...