Date: Wed, 25 May 2011 10:20:43 +0300 From: Daniel Braniss <danny@cs.huji.ac.il> To: mj@feral.com Cc: freebsd-scsi@freebsd.org Subject: Re: iscsi_initiator and tag opening problem Message-ID: <E1QP8OZ-000CmK-GP@kabab.cs.huji.ac.il> In-Reply-To: <alpine.BSF.2.00.1105241105550.40287@ns1.feral.com> References: <E1QOqI2-0000Hy-NI@kabab.cs.huji.ac.il> <4DDBB3F7.20303@feral.com> <E1QOsMz-00028p-LN@kabab.cs.huji.ac.il> <alpine.BSF.2.00.1105241105550.40287@ns1.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >
> > it's a CAM thing not PDU/BHS, or at least that is my undertanding.
> > myabe it's time to read the RFC again
> >
>
> No, what I meant can be seen in the following from iscsi_subr.c:
>
> /*
> | map tag option, default is UNTAGGED
> */
> switch(csio->tag_action) {
> case MSG_SIMPLE_Q_TAG: cmd->attr = iSCSI_TASK_SIMPLE; break;
> case MSG_HEAD_OF_Q_TAG: cmd->attr = iSCSI_TASK_HOFQ; break;
> case MSG_ORDERED_Q_TAG: cmd->attr = iSCSI_TASK_ORDER; break;
> case MSG_ACA_TASK: cmd->attr = iSCSI_TASK_ACA; break;
> }
>
how emabarrassing! in my defense I wrote this back in 2004 and never looked
at it again :-)
>
> That is, you're translating from CAM to iSCSI task attributes. Or, rather,
> iSCSI transport related task attributes. The same thing can be seen in the
> isp FibreChannel driver:
>
> if (ttype == REQFLAG_OTAG) {
> ttype = FCP_CMND_TASK_ATTR_ORDERED;
> } else if (ttype == REQFLAG_HTAG) {
> ttype = FCP_CMND_TASK_ATTR_HEAD;
> } else {
> ttype = FCP_CMND_TASK_ATTR_SIMPLE;
> }
> ((ispreqt7_t *)reqp)->req_task_attribute = ttype;
>
> (yes, mine is skipping ACA, oops)
>
> These are attributes of SAM task management. CAM, like any other SCSI
> midlayer, is quite right to attach the specified attribute. Whether the
> underlying transport can faithfully support those attributes is another
> matter.
is this somehow detectable? or a list of '[non]complaint' targets is needed?
>
> The RFC has the following:
>
> 3.5.1.1. SCSI-Command
>
> This request carries the SCSI CDB and all the other SCSI execute
> command procedure call (see [SAM2]) IN arguments such as task
> attributes, Expected Data Transfer Length for one or both transfer
> directions
>
> This would imply that iSCSI is supposed to support task attributes.
>
> Now, it turns out that the linux openiscsi implementation only uses the
> iSCSI_TASK_SIMPLE attribute, so perhaps the simplest fix here is to just
> do that for the FreeBSD initiator driver.
any side effects? or should I make it tunable?
Thanks Matthew, you made my day!
danny
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1QP8OZ-000CmK-GP>