lkml.org 
[lkml]   [2015]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [target:nvme_of 3/3] drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?
From
Date
On Wed, 2015-01-07 at 22:26 +0200, Sagi Grimberg wrote:
> >> On Wed, 2015-01-07 at 10:57 +0200, Sagi Grimberg wrote:
> >>> On 1/7/2015 12:44 AM, Nicholas A. Bellinger wrote:

<SNIP>

> >> Hey Nic,
> >>
> >> Hope all is well.
> >>
> >> So this skeleton is interesting to me. As this is a fabric module I
> >> assume this would be the NVMEoFabrics target mode driver for upstream
> >> which would be able to talk to NVMEoFabrics initiator (which by
> >> the way makes LIO something more than a SCSI target - will this be
> >> accepted?).
> >
> > That is currently the plan.
> >
> > It's still unclear how this will work wrt to existing target code, but
> > given the amount of logic that NVMe is borrowing from SCSI on the
> > command set side (PR, ALUA, VAAI, DIF), I'm sure there is an opportunity
> > for code sharing between NVMe and SCSI based fabrics.
>
> Right, but I assume there will be a different method to provision this
> stuff given that the target exposes NVME SQs.
>

Yeah, it's not clear how this is going to work yet, but I'd expect a new
backend driver will be required for exposing NVMe hardware queues into
target -> fabric driver code.

> >
> >> I'm currently participating in nvmexpress working group defining the
> >> standard of protocol, specifically in the context of RDMA (naturally).
> >
> > Glad to hear that your involved. ;)
>
> Should say passively involved, at the moment I'm just following this
> stuff.
>
> >
> >> I'm interested in taking an active role in this project, It is
> >> important to build this layered from day one - separating the fabric
> >> logic (RDMA or FCoE) from the core layer.
> >>
> >> Moreover, I know that Mellanox has some plans on accelerating this
> >> area in future devices and we are currently looking into ways to
> >> do that. I want to see that the SW will be able to support that.
> >>
> >> So, Thoughts?
> >
> > FYI, Kiran and Dave (CC'ed) from Intel will be driving upstream NVME-OF
> > target development.
> >
> > I'll be primarily focused on figuring out how NVMe and SCSI can play
> > nicely in target-core, and helping out on the NVMe-OF side where
> > necessary.
>
> Is there something open that I can start playing around with? What is
> the status here? I imagine that the initiator is developed as well...
>

I don't believe any public code is available yet, and considering the
draft spec is only available to members of the NVMe consortium, it's
likely going to be a while before that happens.

However, Dave mentioned off-list that sharing early code amongst NVMe
consortium members should not be an issue.

--nab



\
 
 \ /
  Last update: 2015-01-07 22:41    [W:0.053 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site