On 9 Feb 2012, at 23:51, Stefan Richter wrote: > On Feb 09 Chris Boot wrote: >> On 09/02/2012 14:30, Stefan Richter wrote: >>> World-wide uniqueness of this identification of an IEEE 1212 'unit' >>> comes from the combination of the 'unit's or 'node's EUI-64 and the >>> 'unit's 24 bits wide directory ID. >>> >>> Consistent with that, SAM-2...SAM-4 Annex A table A.2 says that SBP-3 >>> target port identifiers are 11 bytes wide. > [...] >> Very interesting, I didn't realise this fully until you mentioned it. In >> fact SAM-3 says it's 11 bytes, and table A.3 says it's the concatenation >> of the EUI-64 with the 'Discovery ID', defined in IEEE-1212. I only >> looked briefly but I couldn't find any mention of the Discovery ID in >> IEEE-1212-2001. I didn't check SAM-2 or SAM-4. > > SAM-2 says "Discovery ID"/ "See IEEE Std P1212...", SAM-4 says "Discovery > ID"/ "See ISO/IEC 13213:1994...". Perhaps it was indeed called Discovery > ID in one early P1212 version. Or perhaps a SAM editor mistyped it. There > is no such thing in ISO/IEC 13213 = IEEE 1212-1994 nor in IEEE 1212-2001. So really, going by the standards as written, we're no clearer as to exactly what makes up the target port identifier... Handy! Though I agree it would make sense that it in fact refers to a Directory ID, which is the correct size to make up 11 bytes with the GUID. >> I just posted a commit to my github repo which does the following: >> >> 1. Maps SAM target ports to IEEE-1212 units. >> 2. Insists that a target port within the target framework is named using >> an EUI-64/GUID and exposes this in the IEEE-1212 unit directory's >> Unit_Unique_ID property. > > So now we need to support unit unique ID in our initiator too. I can volunteer to do that if you like. I could prepare a patchset for firewire-sbp2 including taking notice of Unit_Unique_ID, ignoring the local node and fixing a couple of minor issues in sbp2_status_to_sense_data() where we mishandle the VALID, MARK, EOM and ILI bits. As for my target code, should I be including an explicit Directory ID as part of my target port name in the target? It seems as though that's something that should be settable seeing as the directory is not necessarily in a constant location in the config ROM at all - but making the target ports that long and complex seems a bit harsh, especially considering all the rules that go along with it... An example target port name in this case could be: 5254000b8f01e6f6:000000 I would have to ensure the directory ID was unique in my target code (or even the whole firewire subsystem) as well as make sure it was not between 0x400 and 0x43f (the range of possible implicit directory IDs in Juju) as IEEE-1212 says "The value of directory_ID in a Directory_ID entry shall be unique among all of a node’s directory IDs, both explicit and implicit." To me it feels like SBP-2/3 wanted the Unit_Unique_ID to be the identifier by itself (falling back to the node's GUID if that entry was not present), but SAM seems to ignore the Unit_Unique_ID and go for a combination of the node's GUID and the Directory_ID as would have been by IEEE-1212's design. Confusing. There is also an added difficulty in that a directory can't be added to a single card's Config ROM in Juju, but instead is added to all cards on the system. This is why I think it's important to include an explicit Unit_Unique_ID, as if you have two cards possibly on the same bus an initiator would see the two units on different nodes as different units instead of two instances of the same unit. What does everyone think? >> 3. Limits the SAM target port to only contain one TPG (target port >> group), which I believe only really make sense for iSCSI. > > OK... So this is about multipathing, but not iSCSI specific in principle. > SAM allows a logical unit to be reached through more than one target port. > Building on that, SPC-3/-4 defines > - target port asymmetric access state: The characteristic that defines > the behavior of a target port and the allowable command set for a > logical unit when commands and task management functions are routed > through the target port maintaining that state, > - target port group: A set of target ports that are in the same target > port asymmetric access state at all times. > A logical unit which canbe reached through a whole bunch of target ports > can some of those ports into groups. Some details are specified in > SPC-3/-4 section 5.8 in a transport-agnostic manner. A transport > specification would certainly need to offer a mapping for all that. > SBP-2/-3 doesn't. Cheers, Chris -- Chris Boot bootc@xxxxxxxxx -- 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
