From: Bart Van Assche <bvanassche@acm.org>
To: linux-scsi <linux-scsi@vger.kernel.org>,
"Nicholas A. Bellinger" <nab@linux-iscsi.org>,
Roland Dreier <roland@purestorage.com>,
target-devel@vger.kernel.org,
James Bottomley <jbottomley@parallels.com>
Subject: Re: [RFC-v4 0/3] qla2xxx: v3.4 target mode LLD changes + tcm_qla2xxx fabric module
Date: Sun, 13 May 2012 15:55:34 +0000 [thread overview]
Message-ID: <4FAFD976.8090409@acm.org> (raw)
On Sunday December 18, 2011 Nicholas Bellinger wrote:
> So to get the ball rolling on remaining items, one question is still how to
> resolve mixed target/initiator mode operation on a HW per port context basis..?
>
> This is currently done with a qla2xxx module parameter, but to do mixed mode
> properly we will need something smarter between scsi-core and target-core ports.
> Note we currently set qlini_mode = QLA2XXX_INI_MODE_STR_DISABLED, so by default
> patch #1 will effectively disable initiator mode by skipping scsi_scan_host()
> from being called in to avoid scsi-core timeouts when performing immediate
> transition from initiator mode -> target mode via ISP reset.
>
> What we would like to eventually do is run qla2xxx LLD to allow both initiator
> and target mode access based on the physical HW port. We tried some simple
> qla_target.c changes this make this work, but to really do it properly
> and address current qlini_mode = QLA2XXX_INI_MODE_STR_DISABLED usage it will
> need to involve scsi-core so that individual HW port can be configured and
> dynamically changed across different access modes.
(sorry for the late reply)
Dynamically switching between initiator mode, target mode or even using both
modes simultaneously is already possible for iSCSI over Ethernet and for SRP
over InfiniBand with the current SCSI core. Why would the SCSI core have to be
modified in order to make the same possible for FCP ? Am I missing something ?
If SCSI initiator timeouts during initiator-to-target mode transitions are an
issue, why not to abort pending SCSI commands before performing the transition ?
Bart.
next reply other threads:[~2012-05-13 15:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-13 15:55 Bart Van Assche [this message]
2012-05-14 3:29 ` [RFC-v4 0/3] qla2xxx: v3.4 target mode LLD changes + tcm_qla2xxx fabric module Nicholas A. Bellinger
2012-05-14 12:50 ` Bart Van Assche
2012-05-14 23:12 ` Nicholas A. Bellinger
2012-05-15 14:21 ` Bart Van Assche
-- strict thread matches above, loose matches on Subject: below --
2011-12-18 2:02 Nicholas A. Bellinger
2011-12-21 17:11 ` Christoph Hellwig
2011-12-22 22:25 ` Andrew Vasquez
2011-12-23 21:59 ` Nicholas A. Bellinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FAFD976.8090409@acm.org \
--to=bvanassche@acm.org \
--cc=jbottomley@parallels.com \
--cc=linux-scsi@vger.kernel.org \
--cc=nab@linux-iscsi.org \
--cc=roland@purestorage.com \
--cc=target-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.