On 09/02/2012 14:30, Stefan Richter wrote:
On Feb 09 Chris Boot wrote:
That's one bit I'm still uncertain of,
as I'm sure I've taken a skewiff view of target ports and TPGs... I
didn't really have anything to go on so at the moment ports have no real
meaning at all, and TPGs are mapped to FireWire units.
I think the mapping needs to change around a bit, but I'm not sure it's
valid to restrict a port to having a single TPG inside, is it? The port
identifier could then be the EUI-64 to uniquely identify the unit, which
I currently don't include in the FireWire unit directory at all - it's
optional in the SBP-2/SBP-3 specs, but the way the target works I really
think it needs to be included.
What does TPG mean?
A TPG is a Target Port Group, a concept which I'm not entirely clear
about. I know it's used in iSCSI but I really don't understand if it's
relevant outside that.
Be careful with termini involving "units". There are the FireWire
units (and each SBP-2 attached SCSI target is represented by one unit);
and each target may in turn contain one or more SCSI logical units. Here
is how the bus architecture and unit architecture define it all:
- One IEEE 1394/ IEEE 1212 'node' may contain 0..n IEEE 1212 'units'.
Each IEEE 1212 unit identifies itself by a unit directory in the
Configuration ROM of the 'node'. [Current IEEE 1212 also has instance
directories, but you can ignore those; I have never seen them
implemented. Furthermore, there is the concept of an IEEE 1212
'module' specified, each module containing 1..n IEEE 1212 nodes, but I
have never seen this manifested in real nodes' Configuration ROMs.]
- An IEEE 1212 'unit' which implements SBP-2/-3 represents one SCSI
Architecture Model 'target port', if I am not mistaken. How the SAM
concepts of 'target device' and 'target port' map to the FireWire
world is not 100% clear to me, but 'target port' being an IEEE 1212
'unit' is how I understand it.
- Finally, this 'target port' (?) may present 1..n SCSI Architecture
Model 'logical units' to initiators. [As mentioned earlier, SBP-2/-3
may transport non-SCSI command set protocols, but this curiosity can
be ignored for this discussion.]
Many multi-unit SBP-2 devices present their units by means of several IEEE
1212 units which all contain only a single SCSI logical unit, rather than
by stuffing all their units as SCSI logical units into a single IEEE 1212
unit.
Yes I have noticed devices doing this both ways, both as multiple
IEEE-1212 units and multiple SCSI LUNs within a unit.
And this is how node, unit ( = target port), and logical unit are
identified:
- An IEEE 1212 'node' is persistently and world-wide uniquely identified
by the EUI-64 which is found in the Configuration ROM bus information
block. This is the node unique ID.
- An IEEE 1212 'unit' is persistently and world-wide uniquely identified
by either an EUI-64 entry within the unit directory, or if such an
entry is not present, by the 'node's EUI-64. The latter is the case
in most if not all implementations that I have seen. So this EUI-64
is the unit unique ID and is usually, but not necessarily, equal to
the node unique ID. [Now that I am writing this down, I notice that
our firewire-sbp2 initiator ignores an explicit unit unique ID and
always only looks at the node unique ID of a target.]
Furthermore, an IEEE 1212 'unit' is world-wide uniquely (and if done
according to the spec, persistently) identified by the index of its
directory in the Configuration ROM, or by a Directory_ID entry within
the unit directory. In absence of such an explicit Directory_ID, the
least significant 24 bits of the base address of the directory within
node address space. In this latter case, IEEE 1212 demands that the
location of the directory within the Configuration ROM persists. Hence
both explicit and implicit directory are persistent and unique per
node.
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.
In contrast, SBP-2 speaks of a SAM-2 "target identifier", says
that it were 64 bits wide and equal to the unit unique ID (or node
unique ID as fallback). SBP-3 says the same but calls it SAM-2
"target port identifier".
So who do we follow, SAM or SBP? As you can see in the firewire-sbp2
initiator code, I adopted SAM's 11 bytes instead of SBP's meager 8
bytes.
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.
- A SCSI Architecture Model 'logical unit' is world-wide uniquely (but
not necessarily persistently, depending on node firmware) identified
by the Logical Unit Number. An SBP-2/-3 attached SCSI Architecture
Model 'logical unit's Logical Unit Number is presented in the
Configuration ROM in SAM's 16-bit format. The LUN is taken as
"logical unit identifier".
World-wide uniqueness of this identification of an SBP-2/-3 attached
'logical unit' comes from the combination of the 'unit's or 'node's
EUI-64 and the 'unit's 24-bit directory ID and the 'logical unit's
16-bit LUN.
In other words, world-wide uniqueness of this identification of an
SBP-2/-3 attached 'logical unit' comes from the combination of the
target port identifier and the logical unit identifier.
Wow that's a very clear discussion of how things fit together, much
better than I could describe! Thanks.
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.
3. Limits the SAM target port to only contain one TPG (target port
group), which I believe only really make sense for iSCSI.
Before this, you could create as many 'target ports' as you liked and
name them what you wanted, but this had no impact on what went in the
config ROM. I mapped the TPGs to IEEE-1212 units, calling them
"unit_%d", but did not create the Unit_Unique_ID property. You could
then create as many "units" as you liked.
The handling of LUNs is unchanged, whereby each TPG can contain any
number of LUNs. One thing that is certain is creating more than one LUN
0 is invalid within a single target port / IEEE-1212 SBP-2/3 unit.
I also would really appreciate someone having a look at my use of
atomics and total lack of locking
I am very interested to look at it for sure, but don't know yet when I can
spend time on it.
Cheers,
Chris
--
Chris Boot
bootc@xxxxxxxxx
Tel: 01271 414100
--
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
