[LSF/MM TOPIC] [ATTEND] qla2xxx FC target mode

[LSF/MM TOPIC] [ATTEND] qla2xxx FC target mode

[Nicholas A. Bellinger]

Hello,

Given the interest getting the Qlogic FC Target driver merged into
mainline during the v3.4 -> v3.5 time frame, I would like to propose a
LSF storage track discussion for some of the longer term items wrt
qla2xxx target mode that are stretching across SCSI + target subsystems.

We would like to eventually support mixed SCSI initiator / target mode
on a per HW port context basis.  Before that can happen in mainline some
of the interaction between SCSI core and target core will need to be
sorted out..

This includes:

- I -> T transition between active initiator mode LLD LUNs 
  + active TCM ports in same LLD
- T -> I transition + rescan of ports without having to restart SCSI LLD
- mixed mode running on the same physical/virtual port
- target core dependencies in SCSI core to make this work..?

More background is available in the RFC-v4 posting here:
http://www.spinics.net/lists/target-devel/msg01424.html

Thanks!

--nab

Re: [LSF/MM TOPIC] [ATTEND] qla2xxx FC target mode

[Nicholas A. Bellinger]

James & Co,

Ping..?  Any thoughts on this topic yet..?

Thanks,

--nab

On Sat, 2012-01-28 at 16:27 -0800, Nicholas A. Bellinger wrote:
> Hello,
> 
> Given the interest getting the Qlogic FC Target driver merged into
> mainline during the v3.4 -> v3.5 time frame, I would like to propose a
> LSF storage track discussion for some of the longer term items wrt
> qla2xxx target mode that are stretching across SCSI + target subsystems.
> 
> We would like to eventually support mixed SCSI initiator / target mode
> on a per HW port context basis.  Before that can happen in mainline some
> of the interaction between SCSI core and target core will need to be
> sorted out..
> 
> This includes:
> 
> - I -> T transition between active initiator mode LLD LUNs 
>   + active TCM ports in same LLD
> - T -> I transition + rescan of ports without having to restart SCSI LLD
> - mixed mode running on the same physical/virtual port
> - target core dependencies in SCSI core to make this work..?
> 
> More background is available in the RFC-v4 posting here:
> http://www.spinics.net/lists/target-devel/msg01424.html
> 
> Thanks!
> 
> --nab
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Lsf-pc] [LSF/MM TOPIC] [ATTEND] qla2xxx FC target mode

[James Bottomley]

On Fri, 2012-03-16 at 16:40 -0700, Nicholas A. Bellinger wrote:
> James & Co,
> 
> Ping..?  Any thoughts on this topic yet..?

Not really ... we're trying to get the participants to plan the topics
this year.

James

Re: [Lsf-pc] [LSF/MM TOPIC] [ATTEND] qla2xxx FC target mode

[Nicholas A. Bellinger]

On Sun, 2012-03-18 at 09:22 +0000, James Bottomley wrote:
> On Fri, 2012-03-16 at 16:40 -0700, Nicholas A. Bellinger wrote:
> > James & Co,
> > 
> > Ping..?  Any thoughts on this topic yet..?
> 
> Not really ... we're trying to get the participants to plan the topics
> this year.
> 

Hi James,

I'm asking because the invites for an LSF slot this year to discuss this
topic with the development community has not materialized, and you've
been completely silent to qla2xxx target RFCs + patches that involve the
subject thus far..

The reasons why a face to face discussion at LSF would be useful:

*) It effects existing qla2xxx LLD mainline code
*) It effects future SCSI LLDs + target fabric modules that also want to
   run in mixed mode operation with scsi-core <-> target-core
*) Other subsystem + filesystem maintainers, and key developers have 
   been helping push the code forward for an initial merge
*) Qlogic is supporting us in the mainline effort

So aside from LSF discussion material, I'm really more interested in
determining a plan at how interaction between scsi-core and target-core
subsystems for mixed mode is really going to operate outside of LLD HW
specifics.  Without starting to get some form of feedback from you and
other SCSI core folks, it's difficult to get moving on for-3.5
integration work that I'd like to get started on soon.

So that said, I'll be collecting ACKs for what has been posted last week
in target-pending/for-next-merge that makes qla2xxx by default run with
target mode explicitly disabled, and requires qlini_mode="disabled" in
order to access qla2xxx WWPNs within the TFO->fabric_make_wwn() handler
for tcm_qla2xx.ko code.

Please have a look and let me know if you have objections to the
existing code changes with a for-3.4 merge.

Thanks,

--nab

Re: [Lsf-pc] [LSF/MM TOPIC] [ATTEND] qla2xxx FC target mode

[James Bottomley]

On Sun, 2012-03-18 at 17:22 -0700, Nicholas A. Bellinger wrote:
> On Sun, 2012-03-18 at 09:22 +0000, James Bottomley wrote:
> > On Fri, 2012-03-16 at 16:40 -0700, Nicholas A. Bellinger wrote:
> > > James & Co,
> > > 
> > > Ping..?  Any thoughts on this topic yet..?
> > 
> > Not really ... we're trying to get the participants to plan the topics
> > this year.
> > 
> 
> Hi James,
> 
> I'm asking because the invites for an LSF slot this year to discuss this
> topic with the development community has not materialized, and you've
> been completely silent to qla2xxx target RFCs + patches that involve the
> subject thus far..

It's not my driver, it's qlogic's ... I'm not really going to say
anything until they do.

James

Re: [Lsf-pc] [LSF/MM TOPIC] [ATTEND] qla2xxx FC target mode

[Nicholas A. Bellinger]

On Mon, 2012-03-19 at 08:54 +0000, James Bottomley wrote:
> On Sun, 2012-03-18 at 17:22 -0700, Nicholas A. Bellinger wrote:
> > On Sun, 2012-03-18 at 09:22 +0000, James Bottomley wrote:
> > > On Fri, 2012-03-16 at 16:40 -0700, Nicholas A. Bellinger wrote:
> > > > James & Co,
> > > > 
> > > > Ping..?  Any thoughts on this topic yet..?
> > > 
> > > Not really ... we're trying to get the participants to plan the topics
> > > this year.
> > > 
> > 
> > Hi James,
> > 
> > I'm asking because the invites for an LSF slot this year to discuss this
> > topic with the development community has not materialized, and you've
> > been completely silent to qla2xxx target RFCs + patches that involve the
> > subject thus far..
> 
> It's not my driver, it's qlogic's ... I'm not really going to say
> anything until they do.

Well, I think most of the questions unresolved around mixed mode that
need to be addressed between scsi-core and target-core for-3.5 are
really quite generic in nature to the individual scsi LLD.

Currently where we run into difficultly with a storage stack that is
made to allow 'hot' transition between different modes of operation, is
how to relinquish initiator mode operation w/o having to unload the
whole SCSI LLD, and also how to re-enable initiator mode when an
individual TCM fabric port have been released by a generic wwn_group
object under /sys/kernel/config/target/$FABRIC/$FABRIC_WWPN

So considering these current limitations here between subsystems for the
initial for-3.4 merge of qla_target.c logic, we now enforce the use of a
qla2xxx specific module parameter to enable/disable different modes
globally for all qla_hw_data ports at LLD load time.

I've asked Andrew V. and Co. to take another look at today's linux-next
tree to verify the changes for existing code in patch #2 for >= qla24xx
series target mode support do not negatively effect the existing
initiator mode operation of qla2xxx in any way.

Please let us know if you have any concerns.

Thanks,

--nab

Re: [Lsf-pc] [LSF/MM TOPIC] [ATTEND] qla2xxx FC target mode

[James Bottomley]

On Mon, 2012-03-19 at 17:15 -0700, Nicholas A. Bellinger wrote:
> On Mon, 2012-03-19 at 08:54 +0000, James Bottomley wrote:
> > On Sun, 2012-03-18 at 17:22 -0700, Nicholas A. Bellinger wrote:
> > > On Sun, 2012-03-18 at 09:22 +0000, James Bottomley wrote:
> > > > On Fri, 2012-03-16 at 16:40 -0700, Nicholas A. Bellinger wrote:
> > > > > James & Co,
> > > > > 
> > > > > Ping..?  Any thoughts on this topic yet..?
> > > > 
> > > > Not really ... we're trying to get the participants to plan the topics
> > > > this year.
> > > > 
> > > 
> > > Hi James,
> > > 
> > > I'm asking because the invites for an LSF slot this year to discuss this
> > > topic with the development community has not materialized, and you've
> > > been completely silent to qla2xxx target RFCs + patches that involve the
> > > subject thus far..
> > 
> > It's not my driver, it's qlogic's ... I'm not really going to say
> > anything until they do.
> 
> Well, I think most of the questions unresolved around mixed mode that
> need to be addressed between scsi-core and target-core for-3.5 are
> really quite generic in nature to the individual scsi LLD.

They are?  I understood it was highly firmware (and even hardware)
dependent from conversations with various manufacturers.

> Currently where we run into difficultly with a storage stack that is
> made to allow 'hot' transition between different modes of operation, is
> how to relinquish initiator mode operation w/o having to unload the
> whole SCSI LLD, and also how to re-enable initiator mode when an
> individual TCM fabric port have been released by a generic wwn_group
> object under /sys/kernel/config/target/$FABRIC/$FABRIC_WWPN
> 
> So considering these current limitations here between subsystems for the
> initial for-3.4 merge of qla_target.c logic, we now enforce the use of a
> qla2xxx specific module parameter to enable/disable different modes
> globally for all qla_hw_data ports at LLD load time.
> 
> I've asked Andrew V. and Co. to take another look at today's linux-next
> tree to verify the changes for existing code in patch #2 for >= qla24xx
> series target mode support do not negatively effect the existing
> initiator mode operation of qla2xxx in any way.
> 
> Please let us know if you have any concerns.

Why can't it just work like scsi_tgt?  That has a separate queue for
target.  The two queue model is then mediated inside the LLD.  If the
LLD can't switch at all, it only accepts one queue attachment at init
time (either target or initiator).  If there's some pain to switching,
you still have to unload one before switching to the other (effectingely
this means quiescing and stopping the unloaded queue), and if it can
autoswitch, you just run two queues and let it sort out the ordering.

James

Re: [Lsf-pc] [LSF/MM TOPIC] [ATTEND] qla2xxx FC target mode

[Nicholas A. Bellinger]

On Tue, 2012-03-20 at 09:03 +0000, James Bottomley wrote:
> On Mon, 2012-03-19 at 17:15 -0700, Nicholas A. Bellinger wrote:
> > On Mon, 2012-03-19 at 08:54 +0000, James Bottomley wrote:
> > > On Sun, 2012-03-18 at 17:22 -0700, Nicholas A. Bellinger wrote:
> > > > On Sun, 2012-03-18 at 09:22 +0000, James Bottomley wrote:
> > > > > On Fri, 2012-03-16 at 16:40 -0700, Nicholas A. Bellinger wrote:
> > > > > > James & Co,
> > > > > > 
> > > > > > Ping..?  Any thoughts on this topic yet..?
> > > > > 
> > > > > Not really ... we're trying to get the participants to plan the topics
> > > > > this year.
> > > > > 
> > > > 
> > > > Hi James,
> > > > 
> > > > I'm asking because the invites for an LSF slot this year to discuss this
> > > > topic with the development community has not materialized, and you've
> > > > been completely silent to qla2xxx target RFCs + patches that involve the
> > > > subject thus far..
> > > 
> > > It's not my driver, it's qlogic's ... I'm not really going to say
> > > anything until they do.
> > 
> > Well, I think most of the questions unresolved around mixed mode that
> > need to be addressed between scsi-core and target-core for-3.5 are
> > really quite generic in nature to the individual scsi LLD.
> 
> They are?  I understood it was highly firmware (and even hardware)
> dependent from conversations with various manufacturers.

There are certainly fw/hw specific considerations for transitions
between modes in order to safety shutdown active I/O, manage active port
state, reallocate hw resources, etc.

I think we now are reasonably clear on the qla2xxx specifics required to
do these transitions, but we are currently lacking some extra glue
between scsi-core and target-core to make this work beyond what's
proposed for v3.4 to use module parameters + requiring an LLD re-load in
order to switch active modes.

> > Currently where we run into difficultly with a storage stack that is
> > made to allow 'hot' transition between different modes of operation, is
> > how to relinquish initiator mode operation w/o having to unload the
> > whole SCSI LLD, and also how to re-enable initiator mode when an
> > individual TCM fabric port have been released by a generic wwn_group
> > object under /sys/kernel/config/target/$FABRIC/$FABRIC_WWPN
> > 
> > So considering these current limitations here between subsystems for the
> > initial for-3.4 merge of qla_target.c logic, we now enforce the use of a
> > qla2xxx specific module parameter to enable/disable different modes
> > globally for all qla_hw_data ports at LLD load time.
> > 
> > I've asked Andrew V. and Co. to take another look at today's linux-next
> > tree to verify the changes for existing code in patch #2 for >= qla24xx
> > series target mode support do not negatively effect the existing
> > initiator mode operation of qla2xxx in any way.
> > 
> > Please let us know if you have any concerns.
> 
> Why can't it just work like scsi_tgt?  That has a separate queue for
> target.  The two queue model is then mediated inside the LLD.  If the
> LLD can't switch at all, it only accepts one queue attachment at init
> time (either target or initiator).  If there's some pain to switching,
> you still have to unload one before switching to the other (effectingely
> this means quiescing and stopping the unloaded queue), and if it can
> autoswitch, you just run two queues and let it sort out the ordering.
> 

So I think one part we need is the ability of scsi-core to be able to
quiesce queues and release initiator mode SCSI LUNs, but not release
struct scsi_host (or unload the LLD).  The ability to do this and set
hostt->supported_mode = MODE_TARGET is IMHO a requirement for properly
doing active mode transition properly across scsi and target subsystems.

We also need to ability to reset hostt->supported_mode = MODE_INITIATOR,
and force a scsi-core rescan (via scsi sysfs) once struct scsi_host has
been relinquished by an /sys/kernel/config/target/$FABRIC/$FABRIC_WWPN/
configfs object reference.  I think this part is more straight-forward
than the first, and should be able to re-use existing rescan logic for
doing this..

Do you have any preference about how these scsi sysfs trigger might
look..?

--nab