What "tarnsport attributes" are really for?
Hello,
I searched and read all threads about "transport attributes" I could find in linux-scsi archive, but real design goals of this API still is not clear. Is it supposed to be:
1) way to store and expose to admin (via syfs) specifics of the underlying transport layer (such as FC, iSCSI, SPI, ...).
2) way to store transport specific per-device (per LUN) attributes.
3) way to access transport specific per-device (per LUN) attributes stored in the driver.
?
It looks like that current implementation is aiming to be case (2), but in reality it is just case (3). I noticed that every time attribute is queried via sysfs LLD is asked to update it.
I hope the actual goal is (1). In that case we should be able to add transport specific host attributes and may prevent unnecessary replication of the same FC/iSCSI info for every LUN on some big storage array.
Before I looked at /sys/class/fc_transport, I expected to find there a tree for every host, with some extra host info in the root dir and subdirs for every known transport end-point. In that tree you should also see links to entries in /sys/class/scsi_host/ and /sys/class/scsi_device/ , and not links to PCI device dir and SD driver dir, which are there now.
Signature · 2 lines
Sergey Panov <[email protected]> Home
Quoted 5 lines · Sergey Panov
Hello,
I searched and read all threads about "transport attributes" I could find in linux-scsi archive, but real design goals of this API still is not clear. Is it supposed to be:
Quoted 7 lines
1) way to store and expose to admin (via syfs) specifics of the underlying transport layer (such as FC, iSCSI, SPI, ...).
2) way to store transport specific per-device (per LUN) attributes.
3) way to access transport specific per-device (per LUN) attributes stored in the driver.
Well, it's not really supposed to be any of them. The goal is to create a library that encapsulates the service delivery subsystem (transport) part of SAM. The ideal is not to have a transport API between the mid-layer and the transport classes but instead have the transport class provide autonomous services to the drivers, but I still don't know if this is possible. It's a class because it exposes the additional transport attributes to the user via sysfs.
The FC transport class is pretty vestigial at the moment, if you want to see the capabilities of doing this, look at the SPI one.here we've been moving the fairly complex DV code out of the drivers and into the transport class.
James
Quoted 3 lines · James Bottomley
... The goal is to create
a library that encapsulates the service delivery subsystem (transport) part of SAM. ...
Then current scheme does not look sufficient. Does it mean we should expect drastic changes in the near future?
Quoted 4 lines
The ideal is not to have a transport API between the
mid-layer and the transport classes but instead have the transport class provide autonomous services to the drivers, but I still don't know if this is possible.
If I am not mistaken, mid-layer is responsible only for adding extra storage space in every new SCSI device and for initializing it by calling shost->transportt->setup(). The second tasks is trivial enough to be delegated to LLD. As for the extra space in every SCSI device, it might be a bit excessive -- an array with 256 LUNs is just one target device (FC or iSCSI device) and there is no need to replicate its properties 256 times.
Quoted 4 lines
The FC transport class is pretty vestigial at the moment, if you want to see the capabilities of doing this, look at the SPI one.here we've been moving the fairly complex DV code out of the drivers and into the transport class.
I can see a set of functions common to SPI LLDs. But those functions are not aware of any SPI specific data (e.g. SPI transport attributes). I also do not see there any support for keeping track of HBA transport attributes.
When I asked my original question, I meant to ask if that transport module would ever stop being a transport specific extension of the mid-layer(extra attributes in every scsi_device) and turn into transport specific extension of the LLD?
E.g. it looks like both iSCSI and FC LLDs are aware of the target device way before mid-layer queries its LUNs. It seems logical to replace current "extra attributes per device" scheme with some primitive data base of transport endpoints. It might even have common, transport neutral API (add_node, remove_node, for_each). Mid-layer SCSI device will lose its transport extension, but might get a pointer to a generic node/port/target. Transport module then would extend nodes to store transport specific attributes and may add function calls to search that DB by some of of the attributes.
I wonder, if change like one described above is too disruptive to make its way into the kernel any time soon?
Signature · 2 lines
Sergey Panov <[email protected]> Home
Quoted 4 lines · Sergey Panov
If I am not mistaken, mid-layer is responsible only for adding extra storage space in every new SCSI device and for initializing it by calling
shost->transportt->setup(). The second tasks is trivial enough to be delegated to LLD.
But it would be another thing for LLD writers to forget. Having it where it is is the correct place for it.
Quoted 4 lines
As for the extra space in every SCSI
device, it might be a bit excessive -- an array with 256 LUNs is just one target device (FC or iSCSI device) and there is no need to replicate its properties 256 times.
There is if the property is different.
Quoted 9 lines
Quoted 4 lines
The FC transport class is pretty vestigial at the moment, if you want to see the capabilities of doing this, look at the SPI one.here we've been moving the fairly complex DV code out of the drivers and into the transport class.
I can see a set of functions common to SPI LLDs. But those functions are not aware of any SPI specific data (e.g. SPI transport attributes). I also do not see there any support for keeping track of HBA transport attributes.
They are in my copy ... you probably need a more up to date kernel.
Quoted 4 lines
When I asked my original question, I meant to ask if that transport module would ever stop being a transport specific extension of the mid-layer(extra attributes in every
scsi_device) and turn into transport specific extension of the LLD?
It's not a transport extension of the mid-layer, it's a library of transport services to the LLD, so in that sense it *is* a transport specific extension for a class of LLDs
Quoted 9 lines
E.g. it looks like both iSCSI and FC LLDs are aware of the target device way before mid-layer queries its LUNs. It seems logical to replace current "extra attributes per device" scheme with some primitive data base of transport endpoints. It might even have common, transport neutral API (
add_node,remove_node,for_each). Mid-layer SCSI device will lose its transport extension, but might get a pointer to a generic node/port/target. Transport module then would extend nodes to store transport specific attributes and may add function calls to search that DB by some of of the attributes.
This was a perennial debate when sysfs and the generic driver model were first proposed. To cope with this, SCSI actually has the ability to set arbitrary sysfs (not transport) attributes for LLDs.
James
Re: What "transport attributes" are really for?
Quoted 7 lines · James Bottomley
Quoted 4 lines · Sergey Panov
As for the extra space in every SCSI
device, it might be a bit excessive -- an array with 256 LUNs is just one target device (FC or iSCSI device) and there is no need to replicate its properties 256 times.There is if the property is different.
It can not be different, because a target device is a transport (SPI, FC, iSCSI) end point. LUNs are units inside that target device and can not possibly have different transport attributes.
Quoted 6 lines
Quoted 4 lines
I can see a set of functions common to SPI LLDs. But those functions are not aware of any SPI specific data (e.g. SPI transport attributes). I also do not see there any support for keeping track of HBA transport attributes.
They are in my copy ... you probably need a more up to date kernel.
Sorry, but I was looking at the most recent snapshot from BK and the only transport attributes I could find there are per scsi_device (per LUN) attributes. May be it is different in your private tree.
Quoted 3 lines
It's not a transport extension of the mid-layer, it's a library of transport services to the LLD, so in that sense it *is* a transport specific extension for a class of LLDs
Then why transport specific data is stored in every scsi_device (mid layer object) and not associated with Scsi_Host(still mid-layer object, but closely associated with LLD)?
Quoted 10 lines
Quoted 9 lines
E.g. it looks like both iSCSI and FC LLDs are aware of the target device way before mid-layer queries its LUNs. It seems logical to replace current "extra attributes per device" scheme with some primitive data base of transport endpoints. It might even have common, transport neutral API (
add_node,remove_node,for_each). Mid-layer SCSI device will lose its transport extension, but might get a pointer to a generic node/port/target. Transport module then would extend nodes to store transport specific attributes and may add function calls to search that DB by some of of the attributes.
Quoted 3 lines
This was a perennial debate when sysfs and the generic driver model were first proposed. To cope with this, SCSI actually has the ability to set arbitrary sysfs (not transport) attributes for LLDs.
Is that debate is archived somewhere? May I get a link?
I was looking for relevant discussion in linux-scsi and did not find
anything prior to the first code submission. It could have been an interesting discussion - while target device is not the final destination for I/O, it an important player in the transport layer.
It is target ID, which LLD (at least in case of FC and iSCSI) binds to transport endpoint (port, node, ...). And, as a result of that binding, it is a target device, which is can be discovered, lost, and rediscovered again. I do not know how you can avoid target centric code in the transport layer.
Signature · 2 lines
Sergey Panov <[email protected]> Home