Re: NVMe over Fabrics target implementation

On Wed, Jun 08, 2016 at 09:36:15PM -0700, Nicholas A. Bellinger wrote: > The configfs ABI should not dictate a single backend use-case. And it doesn't. I actually had a file backend implemented to benchmark it against the loopback driver. It needed absolutely zero new configfs interface. And

Re: NVMe over Fabrics target implementation

On Wed, Jun 08, 2016 at 09:36:15PM -0700, Nicholas A. Bellinger wrote: > The configfs ABI should not dictate a single backend use-case. And it doesn't. I actually had a file backend implemented to benchmark it against the loopback driver. It needed absolutely zero new configfs interface. And

Re: NVMe over Fabrics target implementation

On Wed, 2016-06-08 at 16:12 +0300, Sagi Grimberg wrote: > >> *) Extensible to multiple types of backend drivers. > >> > >> nvme-target needs a way to absorb new backend drivers, that > >> does not effect existing configfs group layout or attributes. > >> > >> Looking at the nvmet/configfs layout

Re: NVMe over Fabrics target implementation

On Wed, 2016-06-08 at 16:12 +0300, Sagi Grimberg wrote: > >> *) Extensible to multiple types of backend drivers. > >> > >> nvme-target needs a way to absorb new backend drivers, that > >> does not effect existing configfs group layout or attributes. > >> > >> Looking at the nvmet/configfs layout

Re: NVMe over Fabrics target implementation

On Wed, 2016-06-08 at 14:19 +0200, Christoph Hellwig wrote: > On Tue, Jun 07, 2016 at 10:21:41PM -0700, Nicholas A. Bellinger wrote: > > *) Extensible to multiple types of backend drivers. > > > > nvme-target needs a way to absorb new backend drivers, that > > does not effect existing configfs

Re: NVMe over Fabrics target implementation

On Wed, 2016-06-08 at 14:19 +0200, Christoph Hellwig wrote: > On Tue, Jun 07, 2016 at 10:21:41PM -0700, Nicholas A. Bellinger wrote: > > *) Extensible to multiple types of backend drivers. > > > > nvme-target needs a way to absorb new backend drivers, that > > does not effect existing configfs

Re: NVMe over Fabrics target implementation

On Wed, Jun 08, 2016 at 04:12:27PM +0300, Sagi Grimberg wrote: >> Because it keeps the code simple. If you had actually participated >> on our development list you might have seen that until not too long >> ago we have very fine grainded locks here. In the end Armen convinced >> me that it's

Re: NVMe over Fabrics target implementation

On Wed, Jun 08, 2016 at 04:12:27PM +0300, Sagi Grimberg wrote: >> Because it keeps the code simple. If you had actually participated >> on our development list you might have seen that until not too long >> ago we have very fine grainded locks here. In the end Armen convinced >> me that it's

Re: NVMe over Fabrics target implementation

*) Extensible to multiple types of backend drivers. nvme-target needs a way to absorb new backend drivers, that does not effect existing configfs group layout or attributes. Looking at the nvmet/configfs layout as-is, there are no multiple backend types defined, nor a way to control backend

Re: NVMe over Fabrics target implementation

*) Extensible to multiple types of backend drivers. nvme-target needs a way to absorb new backend drivers, that does not effect existing configfs group layout or attributes. Looking at the nvmet/configfs layout as-is, there are no multiple backend types defined, nor a way to control backend

Re: NVMe over Fabrics target implementation

On Tue, Jun 07, 2016 at 10:21:41PM -0700, Nicholas A. Bellinger wrote: > *) Extensible to multiple types of backend drivers. > > nvme-target needs a way to absorb new backend drivers, that > does not effect existing configfs group layout or attributes. > > Looking at the nvmet/configfs layout

Re: NVMe over Fabrics target implementation

On Tue, Jun 07, 2016 at 10:21:41PM -0700, Nicholas A. Bellinger wrote: > *) Extensible to multiple types of backend drivers. > > nvme-target needs a way to absorb new backend drivers, that > does not effect existing configfs group layout or attributes. > > Looking at the nvmet/configfs layout

Re: NVMe over Fabrics target implementation

On Tue, 2016-06-07 at 12:55 +0200, Christoph Hellwig wrote: > There is absolutely no point in dragging in an overcomplicated configfs > structure for a very simple protocol which also is very different from > SCSI in it's nitty gritty details. Please be more specific wrt the two individual

Re: NVMe over Fabrics target implementation

On Tue, 2016-06-07 at 12:55 +0200, Christoph Hellwig wrote: > There is absolutely no point in dragging in an overcomplicated configfs > structure for a very simple protocol which also is very different from > SCSI in it's nitty gritty details. Please be more specific wrt the two individual

Re: NVMe over Fabrics target implementation

On Tue, Jun 7, 2016 at 2:02 PM, Andy Grover wrote: > On 06/06/2016 11:23 PM, Nicholas A. Bellinger wrote: >> >> Hi HCH & Co, >> >> On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote: >>> >>> This patch set adds a generic NVMe over Fabrics target. The >>> implementation

Re: NVMe over Fabrics target implementation

On Tue, Jun 7, 2016 at 2:02 PM, Andy Grover wrote: > On 06/06/2016 11:23 PM, Nicholas A. Bellinger wrote: >> >> Hi HCH & Co, >> >> On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote: >>> >>> This patch set adds a generic NVMe over Fabrics target. The >>> implementation conforms to the

Re: NVMe over Fabrics target implementation

On 06/06/2016 11:23 PM, Nicholas A. Bellinger wrote: Hi HCH & Co, On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote: This patch set adds a generic NVMe over Fabrics target. The implementation conforms to the NVMe 1.2b specification (which includes Fabrics) and provides the NVMe over

Re: NVMe over Fabrics target implementation

On 06/06/2016 11:23 PM, Nicholas A. Bellinger wrote: Hi HCH & Co, On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote: This patch set adds a generic NVMe over Fabrics target. The implementation conforms to the NVMe 1.2b specification (which includes Fabrics) and provides the NVMe over

Re: NVMe over Fabrics target implementation

On 06/07/2016 10:31 AM, Christoph Hellwig wrote: Of course you can, and every user of configfs relies on being able to create directories from the kernel using either the default_groups list, or through the use of configfs_register_group(). Apparently configfs_register_group() has been added

Re: NVMe over Fabrics target implementation

On 06/07/2016 10:31 AM, Christoph Hellwig wrote: Of course you can, and every user of configfs relies on being able to create directories from the kernel using either the default_groups list, or through the use of configfs_register_group(). Apparently configfs_register_group() has been added

Re: NVMe over Fabrics target implementation

Hi Bart, > As you know with configfs it is not allowed to create directories in the > configfs hierarchy from inside the kernel. Of course you can, and every user of configfs relies on being able to create directories from the kernel using either the default_groups list, or through the use of

Re: NVMe over Fabrics target implementation

Hi Bart, > As you know with configfs it is not allowed to create directories in the > configfs hierarchy from inside the kernel. Of course you can, and every user of configfs relies on being able to create directories from the kernel using either the default_groups list, or through the use of

Re: NVMe over Fabrics target implementation

On 06/06/2016 02:22 PM, Christoph Hellwig wrote: The target is configured using configfs, and configurable entities are: - NVMe subsystems and namespaces - NVMe over Fabrics ports and referrals - Host ACLs for primitive access control - NVMe over Fabrics access control is still work in

Re: NVMe over Fabrics target implementation

On 06/06/2016 02:22 PM, Christoph Hellwig wrote: The target is configured using configfs, and configurable entities are: - NVMe subsystems and namespaces - NVMe over Fabrics ports and referrals - Host ACLs for primitive access control - NVMe over Fabrics access control is still work in

Re: NVMe over Fabrics target implementation

There is absolutely no point in dragging in an overcomplicated configfs structure for a very simple protocol which also is very different from SCSI in it's nitty gritty details. Keeping the nvme target self contains allows it to be both much simpler and much easier to understand, as well as much

Re: NVMe over Fabrics target implementation

There is absolutely no point in dragging in an overcomplicated configfs structure for a very simple protocol which also is very different from SCSI in it's nitty gritty details. Keeping the nvme target self contains allows it to be both much simpler and much easier to understand, as well as much

Re: NVMe over Fabrics target implementation

Hi HCH & Co, On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote: > This patch set adds a generic NVMe over Fabrics target. The > implementation conforms to the NVMe 1.2b specification (which > includes Fabrics) and provides the NVMe over Fabrics access > to Linux block devices. > Thanks

Re: NVMe over Fabrics target implementation

Hi HCH & Co, On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote: > This patch set adds a generic NVMe over Fabrics target. The > implementation conforms to the NVMe 1.2b specification (which > includes Fabrics) and provides the NVMe over Fabrics access > to Linux block devices. > Thanks

NVMe over Fabrics target implementation

This patch set adds a generic NVMe over Fabrics target. The implementation conforms to the NVMe 1.2b specification (which includes Fabrics) and provides the NVMe over Fabrics access to Linux block devices. The target implementation consists of several elements: - NVMe target core: defines and

NVMe over Fabrics target implementation

This patch set adds a generic NVMe over Fabrics target. The implementation conforms to the NVMe 1.2b specification (which includes Fabrics) and provides the NVMe over Fabrics access to Linux block devices. The target implementation consists of several elements: - NVMe target core: defines and