* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-07 21:05 ` Scott M. Ferris
@ 2004-09-07 21:12 ` Mike Christie
2004-09-07 21:24 ` Scott M. Ferris
2004-09-07 21:33 ` James Bottomley
2004-09-07 21:14 ` James Bottomley
2004-09-08 2:33 ` Douglas Gilbert
2 siblings, 2 replies; 29+ messages in thread
From: Mike Christie @ 2004-09-07 21:12 UTC (permalink / raw)
To: Scott M. Ferris
Cc: James Bottomley, Mike Christie, Matthew Wilcox, Christoph Hellwig,
iscsi -devel, David Wysochanski, Surekha.PC, SCSI Mailing List
Scott M. Ferris wrote:
> James Bottomley wrote:
>
>>On Tue, 2004-09-07 at 15:19, Scott M. Ferris wrote:
>>
>>
>>>That's not a very helpful analogy, since only SPI and FC-AL resemble a
>>>bus, and all of the newer SCSI transports are switched fabrics.
>>
>>Well, I'm at a bit of a loss to make it plainer ... a host is somewhere
>>you plug your bus this is an obvious concept even for switched
>>fabrics.
>
>
> So a host is where you plug your (non-existent) bus? I think it would
> be clearer to use terminology from SAM.
>
>
>>>>In iSCSI that's really the other end point. Using abstractions
>>>>incorrectly (like a single host for the entire iSCSI system) is
>>>>bound to end up with problems due to the concept mismatch.
>>>
>>>I have trouble understanding your viewpoint. Your answers to the
>>>following questions will hopefully clear things up.
>>
>>I doubt it, but I'll try.
>
>
> Thanks.
>
>
>>>Do you think Linux hosts should be used in a similar way by all
>>>switched SCSI transports (e.g. FC-SW, iSCSI, SAS)? If not, why not?
>>
>>Yes.
>
>
> I'm glad we agree on that.
>
>
>>>Do you think switched SCSI transports should allocate one Linux host
>>>for each I_T nexus?
>>
>>No.
>
>
> This is exactly why I ask these questions. The iSCSI driver
> developers just implemented this, because they thought this is what
> you and Christoph were asking for. Apparently it's not what you
> wanted.
Thank you for clarifying this. So we should go back to a single linux host,
right? The iscsi session is an I_T nexus, so the only way to store the
session state in the host is to allocate a session per host.
>
>>>Do you think switched SCSI transports should allocate one Linux host
>>>for each (SAM-2 or SAM-3) SCSI initiator port?
>>
>>Yes.
>
>
> Thank you. This is a much clear statement of your intent.
>
>
>>>Do you think switched SCSI transports should allocate one Linux host
>>>for each (SAM-2 or SAM-3) SCSI initiator device?
>>
>>No.
>
>
> Should all drivers that currently use one host for each SCSI initiator
> device, and a channel for each initiator port on each device, be
> modified to use a host for each initiator port?
>
> Documentation/scsi/scsi_mid_low_api.txt says that a host corresponds
> to a SCSI initiator device. Could someone change that to say SCSI
> initiator port instead, since that seems to be the new goal?
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-07 21:12 ` Mike Christie
@ 2004-09-07 21:24 ` Scott M. Ferris
2004-09-07 21:33 ` James Bottomley
1 sibling, 0 replies; 29+ messages in thread
From: Scott M. Ferris @ 2004-09-07 21:24 UTC (permalink / raw)
To: Mike Christie
Cc: Scott M. Ferris, James Bottomley, Mike Christie, Matthew Wilcox,
Christoph Hellwig, iscsi -devel, David Wysochanski, Surekha.PC,
SCSI Mailing List
Mike Christie wrote:
> >
> > This is exactly why I ask these questions. The iSCSI driver
> > developers just implemented this, because they thought this is what
> > you and Christoph were asking for. Apparently it's not what you
> > wanted.
>
> Thank you for clarifying this. So we should go back to a single linux host,
> right? The iscsi session is an I_T nexus, so the only way to store the
> session state in the host is to allocate a session per host.
Sometimes, but not always. I believe the goal is now one host for
each initiator port (with iSCSI, combination of InitiatorName and
ISID).
If you're trying to create multiple iSCSI sessions to different target
portals within the same SCSI target port (i.e. to TargetAddresses of
the same TargetName with the same TargetPortalGroupTag), you'd need to
use a different SCSI initiator port (typically by using a different
ISID), which means you'd need to allocate multiple hosts.
--
Scott M. Ferris,
sferris@acm.org
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-07 21:12 ` Mike Christie
2004-09-07 21:24 ` Scott M. Ferris
@ 2004-09-07 21:33 ` James Bottomley
2004-09-07 21:37 ` Mike Christie
1 sibling, 1 reply; 29+ messages in thread
From: James Bottomley @ 2004-09-07 21:33 UTC (permalink / raw)
To: Mike Christie
Cc: Scott M. Ferris, Mike Christie, Matthew Wilcox, Christoph Hellwig,
iscsi -devel, David Wysochanski, Surekha.PC, SCSI Mailing List
On Tue, 2004-09-07 at 17:12, Mike Christie wrote:
> > This is exactly why I ask these questions. The iSCSI driver
> > developers just implemented this, because they thought this is what
> > you and Christoph were asking for. Apparently it's not what you
> > wanted.
>
> Thank you for clarifying this. So we should go back to a single linux host,
> right? The iscsi session is an I_T nexus, so the only way to store the
> session state in the host is to allocate a session per host.
No; for iscsi, the host and target for I_T is the right thing to do.
The reason why doesn't lie in terminology or a specification, it lies in
the code.
When the cisco-iscsi driver was first presented, it had a single host
for everything and a huge connection management resource array hanging
off that. This was clearly wrong beacuse there was a huge overhead
managing the array. The correct approach was to make the host
correspond to a single element of that array and use the mid-layer host
management functions instead of home grown resource management
functions. Doing it this way makes both the management and presentation
of the information more logical and the code cleaner.
James
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-07 21:33 ` James Bottomley
@ 2004-09-07 21:37 ` Mike Christie
2004-09-07 22:05 ` James Bottomley
0 siblings, 1 reply; 29+ messages in thread
From: Mike Christie @ 2004-09-07 21:37 UTC (permalink / raw)
To: James Bottomley
Cc: Mike Christie, Scott M. Ferris, Matthew Wilcox, Christoph Hellwig,
iscsi -devel, David Wysochanski, Surekha.PC, SCSI Mailing List
James Bottomley wrote:
> On Tue, 2004-09-07 at 17:12, Mike Christie wrote:
>
>>>This is exactly why I ask these questions. The iSCSI driver
>>>developers just implemented this, because they thought this is what
>>>you and Christoph were asking for. Apparently it's not what you
>>>wanted.
>>
>>Thank you for clarifying this. So we should go back to a single linux host,
>>right? The iscsi session is an I_T nexus, so the only way to store the
>>session state in the host is to allocate a session per host.
>
>
> No; for iscsi, the host and target for I_T is the right thing to do.
>
> The reason why doesn't lie in terminology or a specification, it lies in
> the code.
>
> When the cisco-iscsi driver was first presented, it had a single host
> for everything and a huge connection management resource array hanging
> off that. This was clearly wrong beacuse there was a huge overhead
> managing the array. The correct approach was to make the host
> correspond to a single element of that array and use the mid-layer host
> management functions instead of home grown resource management
> functions. Doing it this way makes both the management and presentation
> of the information more logical and the code cleaner.
Ok. If the new magic iscsi transport specific target code handles target
data like the scsi_host does for hostdata then would it be better to put
our session struct in the target data? I think this also simplifies
refcounting. Most session stuff makes sense hanging off the target so
this might be easier, right?
> James
>
>
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-07 21:37 ` Mike Christie
@ 2004-09-07 22:05 ` James Bottomley
2004-09-07 22:40 ` Mike Christie
0 siblings, 1 reply; 29+ messages in thread
From: James Bottomley @ 2004-09-07 22:05 UTC (permalink / raw)
To: Mike Christie
Cc: Mike Christie, Scott M. Ferris, Matthew Wilcox, Christoph Hellwig,
iscsi -devel, David Wysochanski, Surekha.PC, SCSI Mailing List
On Tue, 2004-09-07 at 17:37, Mike Christie wrote:
> Ok. If the new magic iscsi transport specific target code handles target
> data like the scsi_host does for hostdata then would it be better to put
> our session struct in the target data? I think this also simplifies
> refcounting. Most session stuff makes sense hanging off the target so
> this might be easier, right?
Possibly, but only if the way its handled would be the same on all iscsi
initiator drivers. Otherwise, if it's specific to the driver
implementation, it would be in hostdata. Regardless, you'd still have
one host per one of these entities.
The transport class is to abstract out common code from multiple
drivers, so what goes in there must genuinely be common. Even if you
put the common session data in the target, you probably still end up
having driver specific data in the host.
James
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-07 22:05 ` James Bottomley
@ 2004-09-07 22:40 ` Mike Christie
2004-09-07 22:57 ` Mike Christie
2004-09-07 23:34 ` James Bottomley
0 siblings, 2 replies; 29+ messages in thread
From: Mike Christie @ 2004-09-07 22:40 UTC (permalink / raw)
To: James Bottomley
Cc: Mike Christie, Scott M. Ferris, Matthew Wilcox, Christoph Hellwig,
iscsi -devel, David Wysochanski, Surekha.PC, SCSI Mailing List
James Bottomley wrote:
> On Tue, 2004-09-07 at 17:37, Mike Christie wrote:
>
>>Ok. If the new magic iscsi transport specific target code handles target
>>data like the scsi_host does for hostdata then would it be better to put
>>our session struct in the target data? I think this also simplifies
>>refcounting. Most session stuff makes sense hanging off the target so
>>this might be easier, right?
>
>
> Possibly, but only if the way its handled would be the same on all iscsi
> initiator drivers. Otherwise, if it's specific to the driver
> implementation, it would be in hostdata.
Yes, ok. That is what I am striving for. By us hanging things like
target name on the target instead of on the scsi device or scsi host
will help us conform to other HW iscsi drivers.
Regardless, you'd still have
> one host per one of these entities.
One host per I_T nexus/session? But I thought the only reason against
using a single host for all nexii (ignoring the port/channel
discussion), was that the driver would need its own refcounting.
If the target has some place for driver target data (with the common
iscsi code going in the appropriate transport class stucts) couldn't we
just do sometihng similar to how a scsi_device has the hostdata pointers
and drivers seem to assume when slave_destroy is called they can just
free what was allocated in slave_alloc. And when the driver does its
final scsi_host_put it assumes the hostdata will get freed when all the
handles are released. If the midlayer could provide any similar lifetime
management functionality for targets the iscsi driver would not need any
private structures that are refcounted internally since everything could
fall under the host, device, or target's managemnet.
> The transport class is to abstract out common code from multiple
> drivers, so what goes in there must genuinely be common. Even if you
> put the common session data in the target, you probably still end up
> having driver specific data in the host.
> James
>
>
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-07 22:40 ` Mike Christie
@ 2004-09-07 22:57 ` Mike Christie
2004-09-08 10:27 ` Mike Christie
2004-09-07 23:34 ` James Bottomley
1 sibling, 1 reply; 29+ messages in thread
From: Mike Christie @ 2004-09-07 22:57 UTC (permalink / raw)
To: Mike Christie
Cc: James Bottomley, Mike Christie, Scott M. Ferris, Matthew Wilcox,
Christoph Hellwig, iscsi -devel, David Wysochanski, Surekha.PC,
SCSI Mailing List
Mike Christie wrote:
> James Bottomley wrote:
>
>> On Tue, 2004-09-07 at 17:37, Mike Christie wrote:
>>
>>> Ok. If the new magic iscsi transport specific target code handles
>>> target data like the scsi_host does for hostdata then would it be
>>> better to put our session struct in the target data? I think this
>>> also simplifies refcounting. Most session stuff makes sense hanging
>>> off the target so this might be easier, right?
>>
>>
>>
>> Possibly, but only if the way its handled would be the same on all iscsi
>> initiator drivers. Otherwise, if it's specific to the driver
>> implementation, it would be in hostdata.
>
>
> Yes, ok. That is what I am striving for. By us hanging things like
> target name on the target instead of on the scsi device or scsi host
> will help us conform to other HW iscsi drivers.
>
> Regardless, you'd still have
>
>> one host per one of these entities.
>
>
> One host per I_T nexus/session? But I thought the only reason against
> using a single host for all nexii (ignoring the port/channel
> discussion), was that the driver would need its own refcounting.
Oh yeah by ignoring Scott's comments I just did not want to complicate
things as to what should be done when the isid is the same but the
target port is different. In that case are we supposed to reuse scsi hosts.
> If the target has some place for driver target data (with the common
> iscsi code going in the appropriate transport class stucts) couldn't we
> just do sometihng similar to how a scsi_device has the hostdata pointers
> and drivers seem to assume when slave_destroy is called they can just
> free what was allocated in slave_alloc. And when the driver does its
> final scsi_host_put it assumes the hostdata will get freed when all the
> handles are released. If the midlayer could provide any similar lifetime
> management functionality for targets the iscsi driver would not need any
> private structures that are refcounted internally since everything could
> fall under the host, device, or target's managemnet.
>
>> The transport class is to abstract out common code from multiple
>> drivers, so what goes in there must genuinely be common. Even if you
>> put the common session data in the target, you probably still end up
>> having driver specific data in the host.
>
>
>
>> James
>>
>>
>>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-07 22:57 ` Mike Christie
@ 2004-09-08 10:27 ` Mike Christie
0 siblings, 0 replies; 29+ messages in thread
From: Mike Christie @ 2004-09-08 10:27 UTC (permalink / raw)
To: James Bottomley
Cc: Mike Christie, Scott M. Ferris, Matthew Wilcox, Christoph Hellwig,
iscsi -devel, David Wysochanski, Surekha.PC, SCSI Mailing List
Mike Christie wrote:
> Mike Christie wrote:
>
>> James Bottomley wrote:
>>
>>> On Tue, 2004-09-07 at 17:37, Mike Christie wrote:
>>>
>>>> Ok. If the new magic iscsi transport specific target code handles
>>>> target data like the scsi_host does for hostdata then would it be
>>>> better to put our session struct in the target data? I think this
>>>> also simplifies refcounting. Most session stuff makes sense hanging
>>>> off the target so this might be easier, right?
>>>
>>>
>>>
>>>
>>> Possibly, but only if the way its handled would be the same on all iscsi
>>> initiator drivers. Otherwise, if it's specific to the driver
>>> implementation, it would be in hostdata.
>>
>>
>>
>> Yes, ok. That is what I am striving for. By us hanging things like
>> target name on the target instead of on the scsi device or scsi host
>> will help us conform to other HW iscsi drivers.
>>
>> Regardless, you'd still have
>>
>>> one host per one of these entities.
>>
>>
>>
>> One host per I_T nexus/session? But I thought the only reason against
>> using a single host for all nexii (ignoring the port/channel
>> discussion), was that the driver would need its own refcounting.
>
>
> Oh yeah by ignoring Scott's comments I just did not want to complicate
> things as to what should be done when the isid is the same but the
> target port is different. In that case are we supposed to reuse scsi hosts.
>
Ignore that question and mistake in iscsi and scsi concepts and iscsi
vocab. Don't remember what I was trying to ask or thinking about.
>> If the target has some place for driver target data (with the common
>> iscsi code going in the appropriate transport class stucts) couldn't
>> we just do sometihng similar to how a scsi_device has the hostdata
>> pointers and drivers seem to assume when slave_destroy is called they
>> can just free what was allocated in slave_alloc. And when the driver
>> does its final scsi_host_put it assumes the hostdata will get freed
>> when all the handles are released. If the midlayer could provide any
>> similar lifetime management functionality for targets the iscsi driver
>> would not need any private structures that are refcounted internally
>> since everything could fall under the host, device, or target's
>> managemnet.
>>
>>> The transport class is to abstract out common code from multiple
>>> drivers, so what goes in there must genuinely be common. Even if you
>>> put the common session data in the target, you probably still end up
>>> having driver specific data in the host.
>>
>>
>>
>>
>>> James
>>>
>>>
>>>
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> linux-iscsi-devel mailing list
> linux-iscsi-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-iscsi-devel
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-07 22:40 ` Mike Christie
2004-09-07 22:57 ` Mike Christie
@ 2004-09-07 23:34 ` James Bottomley
2004-09-08 9:19 ` Mike Christie
1 sibling, 1 reply; 29+ messages in thread
From: James Bottomley @ 2004-09-07 23:34 UTC (permalink / raw)
To: Mike Christie
Cc: Mike Christie, Scott M. Ferris, Matthew Wilcox, Christoph Hellwig,
iscsi -devel, David Wysochanski, Surekha.PC, SCSI Mailing List
On Tue, 2004-09-07 at 18:40, Mike Christie wrote:
> > Possibly, but only if the way its handled would be the same on all iscsi
> > initiator drivers. Otherwise, if it's specific to the driver
> > implementation, it would be in hostdata.
>
> Yes, ok. That is what I am striving for. By us hanging things like
> target name on the target instead of on the scsi device or scsi host
> will help us conform to other HW iscsi drivers.
You're thinking of the qlogic one? They have an entire network stack
onboard and they do have resource restrictions per card. A virtual
driver doesn't.
> Regardless, you'd still have
> > one host per one of these entities.
>
> One host per I_T nexus/session? But I thought the only reason against
> using a single host for all nexii (ignoring the port/channel
> discussion), was that the driver would need its own refcounting.
It's not just refcounting, it's resource management. It seems to me,
given that you can allocate resources per connection that per connection
is the most efficient way to manage them.
> If the target has some place for driver target data (with the common
> iscsi code going in the appropriate transport class stucts) couldn't we
> just do sometihng similar to how a scsi_device has the hostdata pointers
> and drivers seem to assume when slave_destroy is called they can just
> free what was allocated in slave_alloc. And when the driver does its
> final scsi_host_put it assumes the hostdata will get freed when all the
> handles are released. If the midlayer could provide any similar lifetime
> management functionality for targets the iscsi driver would not need any
> private structures that are refcounted internally since everything could
> fall under the host, device, or target's managemnet.
Theoretically, I suppose. The mid-layer really prefers to think in
terms of hosts and devices. It doesn't really have much use for
targets.
James
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-07 23:34 ` James Bottomley
@ 2004-09-08 9:19 ` Mike Christie
2004-09-08 14:53 ` James Bottomley
0 siblings, 1 reply; 29+ messages in thread
From: Mike Christie @ 2004-09-08 9:19 UTC (permalink / raw)
To: James Bottomley
Cc: Mike Christie, Scott M. Ferris, Matthew Wilcox, Christoph Hellwig,
iscsi -devel, David Wysochanski, Surekha.PC, SCSI Mailing List
James Bottomley wrote:
> On Tue, 2004-09-07 at 18:40, Mike Christie wrote:
>
>>>Possibly, but only if the way its handled would be the same on all iscsi
>>>initiator drivers. Otherwise, if it's specific to the driver
>>>implementation, it would be in hostdata.
>>
>>Yes, ok. That is what I am striving for. By us hanging things like
>>target name on the target instead of on the scsi device or scsi host
>>will help us conform to other HW iscsi drivers.
>
>
> You're thinking of the qlogic one? They have an entire network stack
> onboard and they do have resource restrictions per card. A virtual
> driver doesn't.
>
I just meant that I am trying to get the iscsi transport class to have
common code across virtual and non virtual drivers. I was not striving
for virtual and non-virtual to alloc hosts alike. I was the one that
converted the iscsi driver to host per session and caused this mess :(
The reason I kept asking below is becuase I misunderstood the resource
comment, and was unsure if I did the right thing and was supposed to
convert the driver back to a single host.
>> Regardless, you'd still have
>>
>>>one host per one of these entities.
>>
>>One host per I_T nexus/session? But I thought the only reason against
>>using a single host for all nexii (ignoring the port/channel
>>discussion), was that the driver would need its own refcounting.
>
>
> It's not just refcounting, it's resource management. It seems to me,
> given that you can allocate resources per connection that per connection
> is the most efficient way to manage them.
>
>>If the target has some place for driver target data (with the common
>>iscsi code going in the appropriate transport class stucts) couldn't we
>>just do sometihng similar to how a scsi_device has the hostdata pointers
>>and drivers seem to assume when slave_destroy is called they can just
>>free what was allocated in slave_alloc. And when the driver does its
>>final scsi_host_put it assumes the hostdata will get freed when all the
>>handles are released. If the midlayer could provide any similar lifetime
>>management functionality for targets the iscsi driver would not need any
>>private structures that are refcounted internally since everything could
>>fall under the host, device, or target's managemnet.
>
>
> Theoretically, I suppose. The mid-layer really prefers to think in
> terms of hosts and devices. It doesn't really have much use for
> targets.
>
> James
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-08 9:19 ` Mike Christie
@ 2004-09-08 14:53 ` James Bottomley
0 siblings, 0 replies; 29+ messages in thread
From: James Bottomley @ 2004-09-08 14:53 UTC (permalink / raw)
To: Mike Christie
Cc: Mike Christie, Scott M. Ferris, Matthew Wilcox, Christoph Hellwig,
iscsi -devel, David Wysochanski, Surekha.PC, SCSI Mailing List
On Wed, 2004-09-08 at 05:19, Mike Christie wrote:
> I just meant that I am trying to get the iscsi transport class to have
> common code across virtual and non virtual drivers. I was not striving
> for virtual and non-virtual to alloc hosts alike. I was the one that
> converted the iscsi driver to host per session and caused this mess :(
I'm not sure that's a good idea; virtual and physical drivers are very
different things and the transport classes may end up being different to
support their different needs. I'd do the transport class for what you
have currently, which is a virtual driver, and when the physical one
comes along we'll see if it's possible to reuse pieces. As long as the
code itself is nicely clean and modular this shouldn't be too hard; so
anywhere you're doing something that could easily be more generally
abstracted, do it. Anywhere where an abstraction would be a contortion
of what you want to do, don't bother.
> The reason I kept asking below is becuase I misunderstood the resource
> comment, and was unsure if I did the right thing and was supposed to
> convert the driver back to a single host.
A host to the mid-layer is the place in which driver instance resources
are managed. We expect to have things like an overall command limit per
host, and manage host and device blocking caused by resource issues.
For a physical iscsi driver, one host per card is easy and obvious; each
instance of the driver controlling a single card. For a virtual iscsi
driver, the driver instances could be many things, but it seems logical
to me that your driver instances are per connection, thus you have one
host per iSCSI connection. Its certainly possible to write a virtual
iSCSI driver where there's a single set of resources for everything, and
thus a single host, but I really don't think that would end up being a
very efficient driver.
James
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-07 21:05 ` Scott M. Ferris
2004-09-07 21:12 ` Mike Christie
@ 2004-09-07 21:14 ` James Bottomley
2004-09-08 2:33 ` Douglas Gilbert
2 siblings, 0 replies; 29+ messages in thread
From: James Bottomley @ 2004-09-07 21:14 UTC (permalink / raw)
To: Scott M. Ferris
Cc: Mike Christie, Mike Christie, Matthew Wilcox, Christoph Hellwig,
iscsi -devel, David Wysochanski, Surekha.PC, SCSI Mailing List
On Tue, 2004-09-07 at 17:05, Scott M. Ferris wrote:
> So a host is where you plug your (non-existent) bus? I think it would
> be clearer to use terminology from SAM.
Actually, no. A host is a SAM implementation, not SAM itself. I think
the where are the resources question is the clearest way to look at it.
> > > Do you think switched SCSI transports should allocate one Linux host
> > > for each I_T nexus?
> >
> > No.
>
> This is exactly why I ask these questions. The iSCSI driver
> developers just implemented this, because they thought this is what
> you and Christoph were asking for. Apparently it's not what you
> wanted.
Well, that seems to be the correct thing to do. Most of the time (all
of the time?) your virtual connection is to a single storage target, so
its identical to a bus with one device on it, isn't it?
> > > Do you think switched SCSI transports should allocate one Linux host
> > > for each (SAM-2 or SAM-3) SCSI initiator device?
> >
> > No.
>
> Should all drivers that currently use one host for each SCSI initiator
> device, and a channel for each initiator port on each device, be
> modified to use a host for each initiator port?
I've made no secret about wanting to dump our channel abstraction.
However, I'm not going to force a change like this.
James
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-07 21:05 ` Scott M. Ferris
2004-09-07 21:12 ` Mike Christie
2004-09-07 21:14 ` James Bottomley
@ 2004-09-08 2:33 ` Douglas Gilbert
2004-09-08 14:38 ` Randy.Dunlap
2 siblings, 1 reply; 29+ messages in thread
From: Douglas Gilbert @ 2004-09-08 2:33 UTC (permalink / raw)
To: Scott M. Ferris
Cc: James Bottomley, Mike Christie, Mike Christie, Matthew Wilcox,
Christoph Hellwig, Surekha.PC, SCSI Mailing List
Scott M. Ferris wrote:
<snip>
>
> Should all drivers that currently use one host for each SCSI initiator
> device, and a channel for each initiator port on each device, be
> modified to use a host for each initiator port?
>
> Documentation/scsi/scsi_mid_low_api.txt says that a host corresponds
> to a SCSI initiator device. Could someone change that to say SCSI
> initiator port instead, since that seems to be the new goal?
Scott,
Yes, I can change that if we all agree. Randy Dunlap asked me some
time back to define what was meant by a "linux SCSI host" and that
was the best I could come up with at the time.
Interesting to see you mention SAS. There could be lots of fun
for the linux SCSI subsystem here:
- addressable switching elements (called "expanders") in the
SCSI domain ** service delivery subsystem. These are not
SCSI devices (in the SAM sense) but are pretty close. They
are controlled by a packetized protocol called SMP whose
initiator end sits on a host and target end sits on an
expander. [SMP has no concept of logical units.]
- discovery is either dead simple (for example when a disk is
directly connected to a HBA's phy [like SATA]) or something
that needs a breadth first, hierarchial descent through
expanders to end devices. The latter type of discovery is
probably better done from the user space.
- in SCSI, devices can have multiple ports and in SAS a port can
be made up of multiple phys (i.e. a wide link). The SCSI
subsystem can ignore phys and just talk about ports but
users can see and touch phys (e.g. those SATA red cables).
Also expander routing is done at the link level.
It would be great to see a transport class architecture that
could cope with this. Think about how a SMP target device
(i.e. an expander's control port) will be represented.
I don't think struct scsi_device is appropriate ...
** the term "bus" seems to have lost favour in SAM and been
replaced by the term "domain".
A few related matters:
Steven Fairchild dropped a proposal for SAS storage management
called "Common Storage Management Interface for SAS" in the
t10 "New Documents and Drafts" section. The url is:
http://www.t10.org/ftp/t10/document.04/04-284r0.pdf
A linux interface and driver is proposed.
A draft standard titled "SCSI-ATA translation" (SAT) is moving
along briskly. The primary target areas for this translator are
in a SAS host above an SAS domain when some of the "SCSI" devices
are SATA disks and SCSI-(p/s)ATA bridges.
Doug Gilbert
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-08 2:33 ` Douglas Gilbert
@ 2004-09-08 14:38 ` Randy.Dunlap
2004-09-08 18:11 ` Bryan Henderson
2004-09-09 0:40 ` Douglas Gilbert
0 siblings, 2 replies; 29+ messages in thread
From: Randy.Dunlap @ 2004-09-08 14:38 UTC (permalink / raw)
To: dougg
Cc: sferris, James.Bottomley, mikenc, michaelc, willy, hch, surekhap,
linux-scsi
On Wed, 08 Sep 2004 12:33:51 +1000 Douglas Gilbert wrote:
| Scott M. Ferris wrote:
| <snip>
| >
| > Should all drivers that currently use one host for each SCSI initiator
| > device, and a channel for each initiator port on each device, be
| > modified to use a host for each initiator port?
| >
| > Documentation/scsi/scsi_mid_low_api.txt says that a host corresponds
| > to a SCSI initiator device. Could someone change that to say SCSI
| > initiator port instead, since that seems to be the new goal?
|
| Scott,
| Yes, I can change that if we all agree. Randy Dunlap asked me some
| time back to define what was meant by a "linux SCSI host" and that
| was the best I could come up with at the time.
Sorry to be dense here, but what is an "initiator port" in this context?
Is it a physical connector or something else? A logical connector?
(whatever that means)
| Interesting to see you mention SAS. There could be lots of fun
| for the linux SCSI subsystem here:
| - addressable switching elements (called "expanders") in the
| SCSI domain ** service delivery subsystem. These are not
| SCSI devices (in the SAM sense) but are pretty close. They
| are controlled by a packetized protocol called SMP whose
| initiator end sits on a host and target end sits on an
| expander. [SMP has no concept of logical units.]
| - discovery is either dead simple (for example when a disk is
| directly connected to a HBA's phy [like SATA]) or something
| that needs a breadth first, hierarchial descent through
| expanders to end devices. The latter type of discovery is
| probably better done from the user space.
| - in SCSI, devices can have multiple ports and in SAS a port can
| be made up of multiple phys (i.e. a wide link). The SCSI
| subsystem can ignore phys and just talk about ports but
| users can see and touch phys (e.g. those SATA red cables).
| Also expander routing is done at the link level.
|
| It would be great to see a transport class architecture that
| could cope with this. Think about how a SMP target device
| (i.e. an expander's control port) will be represented.
| I don't think struct scsi_device is appropriate ...
|
|
| ** the term "bus" seems to have lost favour in SAM and been
| replaced by the term "domain".
|
|
| A few related matters:
|
| Steven Fairchild dropped a proposal for SAS storage management
"dropped" as in dropped (oh, as in deleted) or as in "added", "put",
or "placed" ? Seems to be "added"...
To me, this all boils down to "communication is hard" or
"it's too easy to be ambiguous".
| called "Common Storage Management Interface for SAS" in the
| t10 "New Documents and Drafts" section. The url is:
| http://www.t10.org/ftp/t10/document.04/04-284r0.pdf
| A linux interface and driver is proposed.
|
| A draft standard titled "SCSI-ATA translation" (SAT) is moving
| along briskly. The primary target areas for this translator are
| in a SAS host above an SAS domain when some of the "SCSI" devices
| are SATA disks and SCSI-(p/s)ATA bridges.
|
| Doug Gilbert
--
~Randy
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-08 14:38 ` Randy.Dunlap
@ 2004-09-08 18:11 ` Bryan Henderson
2004-09-09 0:40 ` Douglas Gilbert
1 sibling, 0 replies; 29+ messages in thread
From: Bryan Henderson @ 2004-09-08 18:11 UTC (permalink / raw)
To: Randy.Dunlap
Cc: dougg, hch, James.Bottomley, linux-scsi, linux-scsi-owner,
michaelc, mikenc, sferris, surekhap, willy
>Sorry to be dense here, but what is an "initiator port" in this context?
>Is it a physical connector or something else? A logical connector?
>(whatever that means)
The context is ISCSI; the ISCSI spec rigorously defines the term "SCSI
initiator port." But it defines it quite abstractly, which is why we can
have discussions like this one -- whether in a Linux implementation a SCSI
initiator port should map to a Linux SCSI host or channel or whatever.
The SCSI initiator port is what in simpler times was a physical connector.
In ISCSI it is just the initiator-side endpoint of an ISCSI
(initator-target) session. It is more abstract than a physical connector,
and even more abstract than a TCP port. A SCSI initiator port is
identified by an ISCSI initiator device name (= node name) and ISID. A
SCSI initiator port belongs to a particular SCSI initiator device.
Multiple SCSI initiator ports can go to a single SCSI initiator device. An
ISCSI target reaches a SCSI initiator device via a SCSI initiator port. An
ISCSI target reaches a SCSI initiator port via TCP ports, but not in any
simple mapping.
If you're asking how an ISCSI initiator port is _implemented_ in a
Linux-based initiator, that's what's under discussion. There's more than
one way to do it, and different people have done it different ways.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-08 14:38 ` Randy.Dunlap
2004-09-08 18:11 ` Bryan Henderson
@ 2004-09-09 0:40 ` Douglas Gilbert
2004-09-09 15:40 ` AJ Lewis
1 sibling, 1 reply; 29+ messages in thread
From: Douglas Gilbert @ 2004-09-09 0:40 UTC (permalink / raw)
To: Randy.Dunlap
Cc: sferris, James.Bottomley, mikenc, michaelc, willy, hch, surekhap,
linux-scsi
Randy.Dunlap wrote:
> On Wed, 08 Sep 2004 12:33:51 +1000 Douglas Gilbert wrote:
>
> | Scott M. Ferris wrote:
> | <snip>
> | >
> | > Should all drivers that currently use one host for each SCSI initiator
> | > device, and a channel for each initiator port on each device, be
> | > modified to use a host for each initiator port?
> | >
> | > Documentation/scsi/scsi_mid_low_api.txt says that a host corresponds
> | > to a SCSI initiator device. Could someone change that to say SCSI
> | > initiator port instead, since that seems to be the new goal?
> |
> | Scott,
> | Yes, I can change that if we all agree. Randy Dunlap asked me some
> | time back to define what was meant by a "linux SCSI host" and that
> | was the best I could come up with at the time.
>
> Sorry to be dense here, but what is an "initiator port" in this context?
> Is it a physical connector or something else? A logical connector?
> (whatever that means)
Probably the best place to start is the diagram at
http://www.t10.org under the "Architecture" tab near the
top of the left hand pane. The focus of that diagram is
the Architectural Model (SAM) of which
http://www.t10.org/ftp/t10/drafts/sam3/sam3r13.pdf
is the latest available draft. The transports are
along the bottom of that diagram and the command sets
are along the top.
The concepts of initiator, target, port and delivery
subsystems are defined (abstractly) in SAM-3.
It then falls to the various transports (e.g. FCP,
iSCSI and SPI) to put "meat" on these abstractions
and add some of their own terms (e.g. "logical connector"
from iSCSI). Transports that are not exclusively used
by SCSI command sets (e.g. iSCSI uses IP) come with
their own architectural models and jargon.
SCSI has been around for over 20 years (see wikipedia.org)
and for the first 15 years was synonymous with the "SCSI Parallel
Interface" (SPI) but that is no longer the case. That
change has been very slow getting out to the wider technical
community (as reflected by the SCSI entry in wikipedia.org)
<snip/>
> |
> | A few related matters:
> |
> | Steven Fairchild dropped a proposal for SAS storage management
>
> "dropped" as in dropped (oh, as in deleted) or as in "added", "put",
> or "placed" ? Seems to be "added"...
Sorry, just sloppy usage. Authors put proposals on that site
for comment.
Doug Gilbert
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [linux-iscsi-devel] Re: [PATCH RFC] replace ioctl for sysfs take 2
2004-09-09 0:40 ` Douglas Gilbert
@ 2004-09-09 15:40 ` AJ Lewis
0 siblings, 0 replies; 29+ messages in thread
From: AJ Lewis @ 2004-09-09 15:40 UTC (permalink / raw)
To: Douglas Gilbert
Cc: Randy.Dunlap, sferris, James.Bottomley, mikenc, michaelc, willy,
hch, surekhap, linux-scsi
[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]
On Thu, Sep 09, 2004 at 10:40:04AM +1000, Douglas Gilbert wrote:
> Probably the best place to start is the diagram at
> http://www.t10.org under the "Architecture" tab near the
> top of the left hand pane. The focus of that diagram is
> the Architectural Model (SAM) of which
> http://www.t10.org/ftp/t10/drafts/sam3/sam3r13.pdf
> is the latest available draft. The transports are
> along the bottom of that diagram and the command sets
> are along the top.
Just FYI in case you haven't seen it, there's an updated draft at:
http://www.t10.org/ftp/t10/drafts/sam3/sam3r13a.pdf
though I can't find the revision history in it anywhere, so I don't know how
it differs from sam3r13...
--
AJ Lewis Voice: 612-638-0500
Red Hat Inc. E-Mail: alewis@redhat.com
720 Washington Ave. SE, Suite 200
Minneapolis, MN 55414
Current GPG fingerprint = D9F8 EDCE 4242 855F A03D 9B63 F50C 54A8 578C 8715
Grab the key at: http://people.redhat.com/alewis/gpg.html or one of the
many keyservers out there...
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread