On 2/3/2015 8:45 PM, Michael Christie wrote:
On Feb 3, 2015, at 12:28 PM, Michael Christie <michaelc@xxxxxxxxxxx> wrote:
On Feb 3, 2015, at 4:55 AM, Sagi Grimberg <sagig@xxxxxxxxxxxxxxxxxx> wrote:
On 1/30/2015 11:50 PM, Nicholas A. Bellinger wrote:
if (!text_in) {
- pr_err("Unable to locate text_in buffer for sendtargets"
- " discovery\n");
- goto reject;
+ if (conn->sess->sess_ops->SessionType) {
+ /* Assume this is a consecutive sendtargets */
+ cmd->cmd_flags |= IFC_SENDTARGETS_ALL;
+ cmd->targ_xfer_tag = be32_to_cpu(hdr->ttt);
+ goto empty_sendtargets;
+ } else {
+ pr_err("Unable to locate text_in buffer for sendtargets"
+ " discovery\n");
+ goto reject;
+ }
Btw, why is this restricted to SessionType=Discovery..? AFAICT it
should work as expected for SessionType=Normal as well, no..?
I guess it can, but is the initiator allowed to send us sendtargets
request in a normal session? I assume this is IFC_SENDTARGETS_ALL
(although I guess I don't need to assume that if I locate the cmd from
the hdr->tty).
It says you can send SendTargets discovery sessions and in “operational sessions”. For the latter, you just info for the target you are connected to.
Oh yeah, was there a asc/ascq combo in the newer SAMs/SPCs that indicated the ports/paths changed? Was it 3F/12, 3F/13 and 3F/14 (iscsi ip address added/removed/changed)? I thought this came up when discussing RFC 7144 on some list. The target would send sense indicating the paths/ports changed, then the initiator could do SendTargets and updates its MCS/multipath config on the fly.
Thanks Mike for clearing this...
Sagi.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
