What "tarnsport attributes" are really for?

What "tarnsport attributes" are really for?

[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:

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.


-- 
Sergey Panov <sipan@sipan.org>
Home

Re: What "tarnsport attributes" are really for?

[James Bottomley]

On Mon, 2004-08-30 at 01:00, Sergey Panov wrote:
> 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.

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

Re: What "tarnsport attributes" are really for?

[Sergey Panov]

On Mon, 2004-08-30 at 09:59, James Bottomley wrote:
>  ... 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? 

>   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. 
 

> 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? 

-- 
Sergey Panov <sipan@sipan.org>
Home

Re: What "tarnsport attributes" are really for?

[James Bottomley]

On Tue, 2004-08-31 at 00:46, Sergey Panov wrote:
> 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.

> 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.

> > 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.

> 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

> 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?

[Sergey Panov]

On Tue, 2004-08-31 at 07:49, James Bottomley wrote:
> On Tue, 2004-08-31 at 00:46, Sergey Panov wrote:
> > 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.
 
> > 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.

> 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)? 

> > 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.

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. 

-- 
Sergey Panov <sipan@sipan.org>
Home