Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1417345

Re: NVMe over Fabrics target implementation

From Christoph Hellwig <hch@lst.de>
Newsgroups linux.kernel
Subject Re: NVMe over Fabrics target implementation
Date 2016-06-08 14:20 +0200
Message-ID <rHKCK-8sB-17@gated-at.bofh.it> (permalink)
References <rHafT-1OH-15@gated-at.bofh.it> <rHiGt-7uM-1@gated-at.bofh.it> <rHmTL-1Cx-3@gated-at.bofh.it> <rHEdY-4hc-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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 as-is, there are no multiple
> backend types defined, nor a way to control backend feature bits
> exposed to nvme namespaces at runtime.

And that's very much intentional.  We have a very well working block
layer which we're going to use, no need to reivent it.  The block
layer supports NVMe pass through just fine in case we'll need it,
as I spent the last year preparing it for that.

> Why does it ever make sense for $SUBSYSTEM_NQN_0 with $PORT_DRIVER_FOO
> to block operation of $SUBSYSTEM_NQN_1 with $PORT_DRIVER_BAR..?

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 easier to maintain if we don't bother with fine grained
locking outside the fast path, especially as it significantly simplifies
the discovery implementation.   If if it ever turns out to be an
issue we can change it easily as the implementation is well encapsulated.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

NVMe over Fabrics target implementation Christoph Hellwig <hch@lst.de> - 2016-06-06 23:30 +0200
  [PATCH 3/3] nvme-loop: add a NVMe loopback host driver Christoph Hellwig <hch@lst.de> - 2016-06-06 23:30 +0200
  Re: NVMe over Fabrics target implementation "Nicholas A. Bellinger" <nab@linux-iscsi.org> - 2016-06-07 08:30 +0200
    Re: NVMe over Fabrics target implementation Christoph Hellwig <hch@lst.de> - 2016-06-07 13:00 +0200
      Re: NVMe over Fabrics target implementation "Nicholas A. Bellinger" <nab@linux-iscsi.org> - 2016-06-08 07:30 +0200
        Re: NVMe over Fabrics target implementation Christoph Hellwig <hch@lst.de> - 2016-06-08 14:20 +0200
          Re: NVMe over Fabrics target implementation Sagi Grimberg <sagi@lightbits.io> - 2016-06-08 15:20 +0200
            Re: NVMe over Fabrics target implementation Christoph Hellwig <hch@lst.de> - 2016-06-08 15:50 +0200
            Re: NVMe over Fabrics target implementation "Nicholas A. Bellinger" <nab@linux-iscsi.org> - 2016-06-09 06:40 +0200
              Re: NVMe over Fabrics target implementation Christoph Hellwig <hch@lst.de> - 2016-06-09 15:50 +0200
          Re: NVMe over Fabrics target implementation "Nicholas A. Bellinger" <nab@linux-iscsi.org> - 2016-06-09 05:40 +0200
    Re: NVMe over Fabrics target implementation Andy Grover <agrover@redhat.com> - 2016-06-07 23:10 +0200
      Re: NVMe over Fabrics target implementation Ming Lin <mlin@kernel.org> - 2016-06-07 23:20 +0200
  Re: NVMe over Fabrics target implementation Christoph Hellwig <hch@lst.de> - 2016-06-07 19:40 +0200

csiph-web