[RFC] qla4xxx: TODO for re-submission

[RFC] qla4xxx: TODO for re-submission

[Doug Maxey]

Subject: [RFC] qla4xxx: TODO for re-submission

Howdy!

The qla4xxx driver for the QLogic ISP4XXX chipset will be getting a
little janitorial love along the lines of:

A) a rework of the 2006-06-06 Qlogic submitted qla4xxx code to get the
   driver to be in line with the kernel coding style.
B) being made more compliant with the scsi_mid_low_api.txt.  Being
   compiled for M$ does not count as an alternative OS. :)  In
   particular, move all the code to single .c file.  If and when
   another chipset comes along that can utilize some of the bits, look
   into splitting it back up.
C) removal of unreachable or unused code.
D) a rework of the function layout and size, including linewidth adjustments
E) fixups to printk formatting, and moving to dev_printk().  For the
   first pass, just remove the debug printk()'s

This will not be a re-write of the driver per se, just a refactoring
going on in parallel to the work of the QLogic folks and mike, in an
effort to get this driver into mainline.

The plan is to:
1) submit the Documentation/LICENSE.qla4xxx.txt file and check
   the provenance with the original submitters..
2) pull all the data structs into the file, swizzle the types to be
   kernel compliant.
3) pull the core driver initialization (module_init(), pci init et al)
   into the file drivers/scsi/qla4xxx.c
4) add the iscsi transport code.
5) add the block layer code.
6) add the device firmware access.
7) add the hooks for the Kconfig and Makefile

Does this appear to be a workable plan?  Should the struct cleanup
wait and come in on an as needed basis?

All comments will be appreciated.

++doug

Re: [RFC] qla4xxx: TODO for re-submission

[Ravi Anand]

>On Sat, 10 Jun 2006, Doug Maxey wrote:
> 
> Subject: [RFC] qla4xxx: TODO for re-submission
> 
> Howdy!
> 
> The qla4xxx driver for the QLogic ISP4XXX chipset will be getting a
> little janitorial love along the lines of:
> 
> A) a rework of the 2006-06-06 Qlogic submitted qla4xxx code to get the
>    driver to be in line with the kernel coding style.
     
     Agreed. There are some cleanup's that still need to be done.
     If you have the patch please forward it over.
		
> B) being made more compliant with the scsi_mid_low_api.txt.
    
     OK. Whats the missing piece ? 
	
>    Being compiled for M$ does not count as an alternative OS. :)  In
>    particular, move all the code to single .c file.  If and when
>    another chipset comes along that can utilize some of the bits, look
>    into splitting it back up.
    
     Layout of the file is pretty intutive and we would like to it
     pretty much inline like the qla2xxx FC driver. 
     Anyway this is very low down the priroity. Getting the other
     items done which you have outlined below is more important.	

> C) removal of unreachable or unused code.
     Agreed.

> D) a rework of the function layout and size, including linewidth adjustments

     Patch would help to understand.

> E) fixups to printk formatting, and moving to dev_printk().  For the
>    first pass, just remove the debug printk()'s

     Agreed. 
> 
> This will not be a re-write of the driver per se, just a refactoring
> going on in parallel to the work of the QLogic folks and mike, in an
> effort to get this driver into mainline.
> 
> The plan is to:
> 1) submit the Documentation/LICENSE.qla4xxx.txt file and check
>    the provenance with the original submitters..
      
     We already submitted it. Will be updating it most probably.    

> 2) pull all the data structs into the file, swizzle the types to be
>    kernel compliant.
     OK.

> 3) pull the core driver initialization (module_init(), pci init et al)
>    into the file drivers/scsi/qla4xxx.c
     Same as outlined in  B.

> 4) add the iscsi transport code.
> 5) add the block layer code.

     In my mind item 4 & 5 are the important one's that we need to accomplish.
     Mike I believe has done some of the modifications in the latest patch
     set which he send out recently on open-iscsi reflector.
> 6) add the device firmware access.
     
     Not sure about this.

> 7) add the hooks for the Kconfig and Makefile
> 
    In one of the later patches we did update the top level Makefile and Kconfig.

> Does this appear to be a workable plan?  Should the struct cleanup
> wait and come in on an as needed basis?

  Yes, it is. Prioritising the work is important. Broadly speaking item 4 & 5 are the imporantant
  ones as well cleaning up the code to be more compliant with the linux style.

  Apart from what David Somayajulu is working on, there are other stuff which we need to do
  on the driver side. Important piece is the sysfs stuff which I am working on.

  If you can takeup the item 4 & 5 that would be great. Cleanup part let me know what part 
  want to do  and I can do the rest.
  
> 
> All comments will be appreciated.
> 

Thanx for putting it together.

Ravi

Re: [RFC] qla4xxx: TODO for re-submission

[Mike Christie]

Ravi Anand wrote:
>> 4) add the iscsi transport code.
>> 5) add the block layer code.
> 
>      In my mind item 4 & 5 are the important one's that we need to accomplish.
>      Mike I believe has done some of the modifications in the latest patch
>      set which he send out recently on open-iscsi reflector.

Doug, could you post a link to the git tree for Ravi and them if it is
ready so we can all sync up our patches?

Re: [RFC] qla4xxx: TODO for re-submission

[Ravi Anand]

>On Mon, 12 Jun 2006, Mike Christie wrote:
> Ravi Anand wrote:
> >> 4) add the iscsi transport code.
> >> 5) add the block layer code.
> > 
> >      In my mind item 4 & 5 are the important one's that we need to accomplish.
> >      Mike I believe has done some of the modifications in the latest patch
> >      set which he send out recently on open-iscsi reflector.
> 
> Doug, could you post a link to the git tree for Ravi and them if it is
> ready so we can all sync up our patches?

That would be great. Internally we are also rolling those patches.
Just want to make sure that we are in sync.

Thanx
Ravi

Re: [RFC] qla4xxx: TODO for re-submission

[Mike Christie]

Doug Maxey wrote:
> Subject: [RFC] qla4xxx: TODO for re-submission
> 
> Howdy!
> 
> The qla4xxx driver for the QLogic ISP4XXX chipset will be getting a
> little janitorial love along the lines of:
> 
> A) a rework of the 2006-06-06 Qlogic submitted qla4xxx code to get the
>    driver to be in line with the kernel coding style.
> B) being made more compliant with the scsi_mid_low_api.txt.  Being
>    compiled for M$ does not count as an alternative OS. :)  In
>    particular, move all the code to single .c file.  If and when
>    another chipset comes along that can utilize some of the bits, look
>    into splitting it back up.
> C) removal of unreachable or unused code.
> D) a rework of the function layout and size, including linewidth adjustments
> E) fixups to printk formatting, and moving to dev_printk().  For the
>    first pass, just remove the debug printk()'s
> 
> This will not be a re-write of the driver per se, just a refactoring
> going on in parallel to the work of the QLogic folks and mike, in an
> effort to get this driver into mainline.
> 
> The plan is to:
> 1) submit the Documentation/LICENSE.qla4xxx.txt file and check
>    the provenance with the original submitters..
> 2) pull all the data structs into the file, swizzle the types to be
>    kernel compliant.
> 3) pull the core driver initialization (module_init(), pci init et al)
>    into the file drivers/scsi/qla4xxx.c
> 4) add the iscsi transport code.
> 5) add the block layer code.
> 6) add the device firmware access.
> 7) add the hooks for the Kconfig and Makefile
> 
> Does this appear to be a workable plan?  Should the struct cleanup
> wait and come in on an as needed basis?
> 

I think I am fine with what I have already said needs to be done + all
the cleanup issues where the coding style got mixed up during driver
writer transitions.

I don't think putting everything in one file is very nice. There will be
code that will want the seperation that is being worked on right now
like the target code.

What is the struct cleanup though? typedef->just struct usage?

Re: [RFC] qla4xxx: TODO for re-submission

[Mike Christie]

Mike Christie wrote:
> Doug Maxey wrote:
>> Subject: [RFC] qla4xxx: TODO for re-submission
>>
>> Howdy!
>>
>> The qla4xxx driver for the QLogic ISP4XXX chipset will be getting a
>> little janitorial love along the lines of:
>>
>> A) a rework of the 2006-06-06 Qlogic submitted qla4xxx code to get the
>>    driver to be in line with the kernel coding style.
>> B) being made more compliant with the scsi_mid_low_api.txt.  Being
>>    compiled for M$ does not count as an alternative OS. :)  In
>>    particular, move all the code to single .c file.  If and when
>>    another chipset comes along that can utilize some of the bits, look
>>    into splitting it back up.
>> C) removal of unreachable or unused code.
>> D) a rework of the function layout and size, including linewidth adjustments
>> E) fixups to printk formatting, and moving to dev_printk().  For the
>>    first pass, just remove the debug printk()'s
>>
>> This will not be a re-write of the driver per se, just a refactoring
>> going on in parallel to the work of the QLogic folks and mike, in an
>> effort to get this driver into mainline.
>>
>> The plan is to:
>> 1) submit the Documentation/LICENSE.qla4xxx.txt file and check
>>    the provenance with the original submitters..
>> 2) pull all the data structs into the file, swizzle the types to be
>>    kernel compliant.
>> 3) pull the core driver initialization (module_init(), pci init et al)
>>    into the file drivers/scsi/qla4xxx.c
>> 4) add the iscsi transport code.
>> 5) add the block layer code.
>> 6) add the device firmware access.
>> 7) add the hooks for the Kconfig and Makefile
>>
>> Does this appear to be a workable plan?  Should the struct cleanup
>> wait and come in on an as needed basis?
>>
> 
> I think I am fine with what I have already said needs to be done + all
> the cleanup issues where the coding style got mixed up during driver
> writer transitions.

The removing of the dead/unused code should of course be done too.

Re: [RFC] qla4xxx: TODO for re-submission

[Mike Christie]

Doug Maxey wrote:
> 5) add the block layer code.

Some related issues that we have discussed offlist about this and should
probably be discussed here are:

- Are we supposed to follow FC's lead and remove the devices (rport,
session, target, scsi_device, etc) if the dev_loss_tmo fires. Currently
for software iscsi, we leave the devices/session. This was to reduce
memory allocations and because software iscsi has to basically poll the
connection during connect as part of the relogin process. So unlike FC
or hw iscsi, if we remove the devices/structs we have to end up
rebuilding some of them right away anyways.

Removing the devices has the benefit of simplifying the scsi/iscsi code.

- Scanning. We currently do scanning for open-iscsi in userspace. For
iscsi root this requires distro support. SUSE has it. Fedora is working
on it. There is also Debian and Gentoo users or maintainers posting
about working on it. For qla4xxx, we could stick the scanning in the
kernel like FC and distros would not have to worry about it, but since
they have to get this working for software iscsi do we just keep the
scanning in userspace?

Re: [RFC] qla4xxx: TODO for re-submission

[Doug Maxey]

On Mon, 12 Jun 2006 09:49:34 PDT, Ravi Anand wrote:
> >On Sat, 10 Jun 2006, Doug Maxey wrote:
> > 
> > Subject: [RFC] qla4xxx: TODO for re-submission
> > 
> > Howdy!
> > 
> > The qla4xxx driver for the QLogic ISP4XXX chipset will be getting a
> > little janitorial love along the lines of:
> > 
> > A) a rework of the 2006-06-06 Qlogic submitted qla4xxx code to get the
> >    driver to be in line with the kernel coding style.
>      
>      Agreed. There are some cleanup's that still need to be done.
>      If you have the patch please forward it over.
> 		
> > B) being made more compliant with the scsi_mid_low_api.txt.
>     
>      OK. Whats the missing piece ? 

Right now, the original driver is in functional separate pieces,
which is good from a development team standpoint.  One of the requests
(directives?) from smla is to have the driver in one file.  Dunno,
really not that big deal to me, but with function re-order, we could
shrink the line count by roughly 30%, from my current estimate.

Once that is done, the patch submissions could flow from functionally
standalone pieces that compile, but may not actually do anything.
The subsequent patches would add the layers of current functionality
(and the newer transport stuff) in layers, and be in small enough pieces
to allow easy review.

Making the driver patches suitable for easy review is really my goal...

> 	
> >    Being compiled for M$ does not count as an alternative OS. :)  In
> >    particular, move all the code to single .c file.  If and when
> >    another chipset comes along that can utilize some of the bits, look
> >    into splitting it back up.
>     
>      Layout of the file is pretty intutive and we would like to it
>      pretty much inline like the qla2xxx FC driver. 
>      Anyway this is very low down the priroity. Getting the other
>      items done which you have outlined below is more important.

maybe on your list. :)  Mike may have Christoph's and James' ears,
but the earlier offline comments lead me to believe otherwise, at least
style-wise.  Of course, Mike is the QB on this, so anxiously awaiting 
his comments.

> 
> > C) removal of unreachable or unused code.
>      Agreed.
> 
> > D) a rework of the function layout and size, including linewidth adjustments
> 
>      Patch would help to understand.

Yeah, let me wade through this once first.
 
> 
> > E) fixups to printk formatting, and moving to dev_printk().  For the
> >    first pass, just remove the debug printk()'s
> 
>      Agreed. 

wilco.

> > 
> > This will not be a re-write of the driver per se, just a refactoring
> > going on in parallel to the work of the QLogic folks and mike, in an
> > effort to get this driver into mainline.
> > 
> > The plan is to:
> > 1) submit the Documentation/LICENSE.qla4xxx.txt file and check
> >    the provenance with the original submitters..
>       
>      We already submitted it. Will be updating it most probably.

Yes, but see my response for B).  :->

> 
> > 2) pull all the data structs into the file, swizzle the types to be
> >    kernel compliant.
>      OK.
> 
> > 3) pull the core driver initialization (module_init(), pci init et al)
> >    into the file drivers/scsi/qla4xxx.c
>      Same as outlined in  B.
> 
> > 4) add the iscsi transport code.
> > 5) add the block layer code.
> 
>      In my mind item 4 & 5 are the important one's that we need to accomplish.
>      Mike I believe has done some of the modifications in the latest patch
>      set which he send out recently on open-iscsi reflector.
> > 6) add the device firmware access.
>      
>      Not sure about this.

simply an ordering of patches.  Maybe that should go in as step 2.

> 
> > 7) add the hooks for the Kconfig and Makefile
> > 
>     In one of the later patches we did update the top level Makefile and Kconfig.

Am thinking this would be the last of the series, no need to build if it 
does not get accepted. 

> 
> > Does this appear to be a workable plan?  Should the struct cleanup
> > wait and come in on an as needed basis?
> 
>   Yes, it is. Prioritising the work is important. Broadly speaking item 4 & 5 are the imporantant
>   ones as well cleaning up the code to be more compliant with the linux style.
> 
>   Apart from what David Somayajulu is working on, there are other stuff which we need to do
>   on the driver side. Important piece is the sysfs stuff which I am working on.
> 
>   If you can takeup the item 4 & 5 that would be great. Cleanup part let me know what part 
>   want to do  and I can do the rest.
>   
> > 
> > All comments will be appreciated.
> > 
> 
> Thanx for putting it together.
> 
> Ravi
> 

Re: [RFC] qla4xxx: TODO for re-submission

[Doug Maxey]

On Mon, 12 Jun 2006 12:43:09 CDT, Mike Christie wrote:
> Doug Maxey wrote:
> > Subject: [RFC] qla4xxx: TODO for re-submission
> > 
> > Howdy!
> > 
> > The qla4xxx driver for the QLogic ISP4XXX chipset will be getting a
> > little janitorial love along the lines of:
> > 
> > A) a rework of the 2006-06-06 Qlogic submitted qla4xxx code to get the
> >    driver to be in line with the kernel coding style.
> > B) being made more compliant with the scsi_mid_low_api.txt.  Being
> >    compiled for M$ does not count as an alternative OS. :)  In
> >    particular, move all the code to single .c file.  If and when
> >    another chipset comes along that can utilize some of the bits, look
> >    into splitting it back up.
> > C) removal of unreachable or unused code.
> > D) a rework of the function layout and size, including linewidth adjustments
> > E) fixups to printk formatting, and moving to dev_printk().  For the
> >    first pass, just remove the debug printk()'s
> > 
> > This will not be a re-write of the driver per se, just a refactoring
> > going on in parallel to the work of the QLogic folks and mike, in an
> > effort to get this driver into mainline.
> > 
> > The plan is to:
> > 1) submit the Documentation/LICENSE.qla4xxx.txt file and check
> >    the provenance with the original submitters..
> > 2) pull all the data structs into the file, swizzle the types to be
> >    kernel compliant.
> > 3) pull the core driver initialization (module_init(), pci init et al)
> >    into the file drivers/scsi/qla4xxx.c
> > 4) add the iscsi transport code.
> > 5) add the block layer code.
> > 6) add the device firmware access.
> > 7) add the hooks for the Kconfig and Makefile
> > 
> > Does this appear to be a workable plan?  Should the struct cleanup
> > wait and come in on an as needed basis?
> > 
> 
> I think I am fine with what I have already said needs to be done + all
> the cleanup issues where the coding style got mixed up during driver
> writer transitions.
> 
> I don't think putting everything in one file is very nice. There will be
> code that will want the seperation that is being worked on right now
> like the target code.

Ah, ok.  We can do it that way.

> 
> What is the struct cleanup though? typedef->just struct usage?
> 

mainly, yes.  do we need to track the sparse types (__le*) for device 
data?

Re: [RFC] qla4xxx: TODO for re-submission

[Doug Maxey]

On Mon, 12 Jun 2006 11:52:16 CDT, Mike Christie wrote:
> Ravi Anand wrote:
> >> 4) add the iscsi transport code.
> >> 5) add the block layer code.
> > 
> >      In my mind item 4 & 5 are the important one's that we need to accomplish.
> >      Mike I believe has done some of the modifications in the latest patch
> >      set which he send out recently on open-iscsi reflector.
> 
> Doug, could you post a link to the git tree for Ravi and them if it is
> ready so we can all sync up our patches?
> 

Oh yes, no problem.  Just nothing has been checked in yet.  Am about 
50% of the way through the cleanup.  Once I get a clean compile out of 
this, will post the tree.

++doug

Re: [RFC] qla4xxx: TODO for re-submission

[Mike Christie]

Doug Maxey wrote:
>> What is the struct cleanup though? typedef->just struct usage?
>>
> 
> mainly, yes. 

Ok. I am fine if you want to do that. For iscsi_tcp and friends we fixed
this, but nobody ever said anything about the typedef usage during the
initial qla4xxx postings so I thought we had been overly careful/picky.

For scsi I never saw anyone complain about the single file issue either.
However for the netdev review it looks like the qlogic net driver got
that comment and the typedef one.

What about the mixed case variable names and other junk? Some people get
a way with them and others don't. For scsi is the policy to not be that
picky or did some drivers sneak in?


> do we need to track the sparse types (__le*) for device 
> data?
> 

Yeah I think so. I do not think you were CCd on the coding style todo.
Qlogic and I sometimes drop you form CCs and forget to add you back on
later. Sorry about that.

Re: [RFC] qla4xxx: TODO for re-submission

[Ravi Anand]

>On Mon, 12 Jun 2006, Mike Christie wrote:
> Doug Maxey wrote:
> > 5) add the block layer code.
> 
> Some related issues that we have discussed offlist about this and should
> probably be discussed here are:
> 
> - Are we supposed to follow FC's lead and remove the devices (rport,
> session, target, scsi_device, etc) if the dev_loss_tmo fires. Currently
> for software iscsi, we leave the devices/session. This was to reduce
> memory allocations and because software iscsi has to basically poll the
> connection during connect as part of the relogin process. So unlike FC
> or hw iscsi, if we remove the devices/structs we have to end up
> rebuilding some of them right away anyways.
> 
> Removing the devices has the benefit of simplifying the scsi/iscsi code.
> 
> - Scanning. We currently do scanning for open-iscsi in userspace. For
> iscsi root this requires distro support. SUSE has it. Fedora is working
> on it. There is also Debian and Gentoo users or maintainers posting
> about working on it. For qla4xxx, we could stick the scanning in the
> kernel like FC and distros would not have to worry about it, but since
> they have to get this working for software iscsi do we just keep the
> scanning in userspace?

Our preference is also to have the scanning for all the HBA's which
does the discovery of the tgt's in the kernel space. This way we are
consistent with all the HBA's which does the port discovery like 
the FC HBA's. Our iSCSI HBA's is similar in that regard.

As you have already stated, it simplies support from distro perspective 
as well.

Ravi

Re: [RFC] qla4xxx: TODO for re-submission

[Mike Christie]

Ravi Anand wrote:
>> On Mon, 12 Jun 2006, Mike Christie wrote:
>> Doug Maxey wrote:
>>> 5) add the block layer code.
>> Some related issues that we have discussed offlist about this and should
>> probably be discussed here are:
>>
>> - Are we supposed to follow FC's lead and remove the devices (rport,
>> session, target, scsi_device, etc) if the dev_loss_tmo fires. Currently
>> for software iscsi, we leave the devices/session. This was to reduce
>> memory allocations and because software iscsi has to basically poll the
>> connection during connect as part of the relogin process. So unlike FC
>> or hw iscsi, if we remove the devices/structs we have to end up
>> rebuilding some of them right away anyways.
>>
>> Removing the devices has the benefit of simplifying the scsi/iscsi code.
>>
>> - Scanning. We currently do scanning for open-iscsi in userspace. For
>> iscsi root this requires distro support. SUSE has it. Fedora is working
>> on it. There is also Debian and Gentoo users or maintainers posting
>> about working on it. For qla4xxx, we could stick the scanning in the
>> kernel like FC and distros would not have to worry about it, but since
>> they have to get this working for software iscsi do we just keep the
>> scanning in userspace?
> 
> Our preference is also to have the scanning for all the HBA's which
> does the discovery of the tgt's in the kernel space. This way we are
> consistent with all the HBA's which does the port discovery like 
> the FC HBA's. Our iSCSI HBA's is similar in that regard.

Yeah, but your HBA can also function in connection mode and just use
open-iscsi's login code too. I am not saying that is that way to go. I
am just saying that there are alternatives.

> 
> As you have already stated, it simplies support from distro perspective 
> as well.
> 

It does for qla4xxx, but I think you then have to go and fix it so
iscsi_tcp and iscsi_iser sync up with userspace correctly if you convert
them. Either that or we maintain two ways of scanning for iscsi drivers.
For iscsi_tcp/iser we have some sync code to avoid the async scanning
root disk problem, but that code is in userspace.

Re: [RFC] qla4xxx: TODO for re-submission

[Mike Christie]

Mike Christie wrote:
> Ravi Anand wrote:
>>> On Mon, 12 Jun 2006, Mike Christie wrote:
>>> Doug Maxey wrote:
>>>> 5) add the block layer code.
>>> Some related issues that we have discussed offlist about this and should
>>> probably be discussed here are:
>>>
>>> - Are we supposed to follow FC's lead and remove the devices (rport,
>>> session, target, scsi_device, etc) if the dev_loss_tmo fires. Currently
>>> for software iscsi, we leave the devices/session. This was to reduce
>>> memory allocations and because software iscsi has to basically poll the
>>> connection during connect as part of the relogin process. So unlike FC
>>> or hw iscsi, if we remove the devices/structs we have to end up
>>> rebuilding some of them right away anyways.
>>>
>>> Removing the devices has the benefit of simplifying the scsi/iscsi code.
>>>
>>> - Scanning. We currently do scanning for open-iscsi in userspace. For
>>> iscsi root this requires distro support. SUSE has it. Fedora is working
>>> on it. There is also Debian and Gentoo users or maintainers posting
>>> about working on it. For qla4xxx, we could stick the scanning in the
>>> kernel like FC and distros would not have to worry about it, but since
>>> they have to get this working for software iscsi do we just keep the
>>> scanning in userspace?
>> Our preference is also to have the scanning for all the HBA's which
>> does the discovery of the tgt's in the kernel space. This way we are
>> consistent with all the HBA's which does the port discovery like 
>> the FC HBA's. Our iSCSI HBA's is similar in that regard.
> 
> Yeah, but your HBA can also function in connection mode and just use
> open-iscsi's login code too. I am not saying that is that way to go. I
> am just saying that there are alternatives.
> 
>> As you have already stated, it simplies support from distro perspective 
>> as well.
>>
> 
> It does for qla4xxx, but I think you then have to go and fix it so
> iscsi_tcp and iscsi_iser sync up with userspace correctly if you convert
> them. Either that or we maintain two ways of scanning for iscsi drivers.
> For iscsi_tcp/iser we have some sync code to avoid the async scanning
> root disk problem, but that code is in userspace.


Oh yeah for install, do all your cards have the ability to be able to
set values like a discovery address from a bios or open firmware screen?
Is this ability on the card when you first get it or do you have to
download it or do you just have to download it for older cards?

Re: [RFC] qla4xxx: TODO for re-submission

[Ravi Anand]

>On Mon, 12 Jun 2006, Mike Christie wrote:

> Date: Mon, 12 Jun 2006 16:35:45 -0500
> From: Mike Christie <michaelc@cs.wisc.edu>
> To: Ravi Anand <ravi.anand@qlogic.com>
> CC: Doug Maxey <dwm@bebe.enoyolf.org>,
> 	David Somayajulu <davidcs2005@gmail.com>,
> 	Duane Grigsby <duane.grigsby@qlogic.com>,
> 	linux-scsi@vger.kernel.org, dwm@austin.ibm.com
> Subject: Re: [RFC] qla4xxx: TODO for re-submission
> User-Agent: Thunderbird 1.5 (X11/20060313)
> 
> Ravi Anand wrote:
> >> On Mon, 12 Jun 2006, Mike Christie wrote:
> >> Doug Maxey wrote:
> >>> 5) add the block layer code.
> >> Some related issues that we have discussed offlist about this and should
> >> probably be discussed here are:
> >>
> >> - Are we supposed to follow FC's lead and remove the devices (rport,
> >> session, target, scsi_device, etc) if the dev_loss_tmo fires. Currently
> >> for software iscsi, we leave the devices/session. This was to reduce
> >> memory allocations and because software iscsi has to basically poll the
> >> connection during connect as part of the relogin process. So unlike FC
> >> or hw iscsi, if we remove the devices/structs we have to end up
> >> rebuilding some of them right away anyways.
> >>
> >> Removing the devices has the benefit of simplifying the scsi/iscsi code.
> >>
> >> - Scanning. We currently do scanning for open-iscsi in userspace. For
> >> iscsi root this requires distro support. SUSE has it. Fedora is working
> >> on it. There is also Debian and Gentoo users or maintainers posting
> >> about working on it. For qla4xxx, we could stick the scanning in the
> >> kernel like FC and distros would not have to worry about it, but since
> >> they have to get this working for software iscsi do we just keep the
> >> scanning in userspace?
> > 
> > Our preference is also to have the scanning for all the HBA's which
> > does the discovery of the tgt's in the kernel space. This way we are
> > consistent with all the HBA's which does the port discovery like 
> > the FC HBA's. Our iSCSI HBA's is similar in that regard.
> 
> Yeah, but your HBA can also function in connection mode and just use
> open-iscsi's login code too. I am not saying that is that way to go. I
> am just saying that there are alternatives.

Agreed. But it was added later on. So the driver always used the session mode.
> 
> > 
> > As you have already stated, it simplies support from distro perspective 
> > as well.
> > 
> 
> It does for qla4xxx, but I think you then have to go and fix it so
> iscsi_tcp and iscsi_iser sync up with userspace correctly if you convert
> them. Either that or we maintain two ways of scanning for iscsi drivers.

I like the later part. Keeping it seperate.

Ravi

Re: [RFC] qla4xxx: TODO for re-submission

[Ravi Anand]

>On Mon, 12 Jun 2006, Mike Christie wrote:
> Mike Christie wrote:
> > Ravi Anand wrote:
> >>> On Mon, 12 Jun 2006, Mike Christie wrote:
> >>> Doug Maxey wrote:
> >>>> 5) add the block layer code.
> >>> Some related issues that we have discussed offlist about this and should
> >>> probably be discussed here are:
> >>>
> >>> - Are we supposed to follow FC's lead and remove the devices (rport,
> >>> session, target, scsi_device, etc) if the dev_loss_tmo fires. Currently
> >>> for software iscsi, we leave the devices/session. This was to reduce
> >>> memory allocations and because software iscsi has to basically poll the
> >>> connection during connect as part of the relogin process. So unlike FC
> >>> or hw iscsi, if we remove the devices/structs we have to end up
> >>> rebuilding some of them right away anyways.
> >>>
> >>> Removing the devices has the benefit of simplifying the scsi/iscsi code.
> >>>
> >>> - Scanning. We currently do scanning for open-iscsi in userspace. For
> >>> iscsi root this requires distro support. SUSE has it. Fedora is working
> >>> on it. There is also Debian and Gentoo users or maintainers posting
> >>> about working on it. For qla4xxx, we could stick the scanning in the
> >>> kernel like FC and distros would not have to worry about it, but since
> >>> they have to get this working for software iscsi do we just keep the
> >>> scanning in userspace?
> >> Our preference is also to have the scanning for all the HBA's which
> >> does the discovery of the tgt's in the kernel space. This way we are
> >> consistent with all the HBA's which does the port discovery like 
> >> the FC HBA's. Our iSCSI HBA's is similar in that regard.
> > 
> > Yeah, but your HBA can also function in connection mode and just use
> > open-iscsi's login code too. I am not saying that is that way to go. I
> > am just saying that there are alternatives.
> > 
> >> As you have already stated, it simplies support from distro perspective 
> >> as well.
> >>
> > 
> > It does for qla4xxx, but I think you then have to go and fix it so
> > iscsi_tcp and iscsi_iser sync up with userspace correctly if you convert
> > them. Either that or we maintain two ways of scanning for iscsi drivers.
> > For iscsi_tcp/iser we have some sync code to avoid the async scanning
> > root disk problem, but that code is in userspace.
> 
> 
> Oh yeah for install, do all your cards have the ability to be able to
> set values like a discovery address from a bios or open firmware screen?

Yes. On x86 system you have to use Ctrl+Q to enter the HBA bios and you 
can set it from there.

> Is this ability on the card when you first get it or do you have to
> download it or do you just have to download it for older cards?

Thats correct. Its built in when you first get it. In case its not
there, you can download the flashuitl to update it or better
just use SANSufer for iSCSI HBA's to udpate it.

Ravi

Re: [RFC] qla4xxx: TODO for re-submission

[Mike Christie]

Ravi Anand wrote:
>> On Mon, 12 Jun 2006, Mike Christie wrote:
> 
>> Date: Mon, 12 Jun 2006 16:35:45 -0500
>> From: Mike Christie <michaelc@cs.wisc.edu>
>> To: Ravi Anand <ravi.anand@qlogic.com>
>> CC: Doug Maxey <dwm@bebe.enoyolf.org>,
>> 	David Somayajulu <davidcs2005@gmail.com>,
>> 	Duane Grigsby <duane.grigsby@qlogic.com>,
>> 	linux-scsi@vger.kernel.org, dwm@austin.ibm.com
>> Subject: Re: [RFC] qla4xxx: TODO for re-submission
>> User-Agent: Thunderbird 1.5 (X11/20060313)
>>
>> Ravi Anand wrote:
>>>> On Mon, 12 Jun 2006, Mike Christie wrote:
>>>> Doug Maxey wrote:
>>>>> 5) add the block layer code.
>>>> Some related issues that we have discussed offlist about this and should
>>>> probably be discussed here are:
>>>>
>>>> - Are we supposed to follow FC's lead and remove the devices (rport,
>>>> session, target, scsi_device, etc) if the dev_loss_tmo fires. Currently
>>>> for software iscsi, we leave the devices/session. This was to reduce
>>>> memory allocations and because software iscsi has to basically poll the
>>>> connection during connect as part of the relogin process. So unlike FC
>>>> or hw iscsi, if we remove the devices/structs we have to end up
>>>> rebuilding some of them right away anyways.
>>>>
>>>> Removing the devices has the benefit of simplifying the scsi/iscsi code.
>>>>
>>>> - Scanning. We currently do scanning for open-iscsi in userspace. For
>>>> iscsi root this requires distro support. SUSE has it. Fedora is working
>>>> on it. There is also Debian and Gentoo users or maintainers posting
>>>> about working on it. For qla4xxx, we could stick the scanning in the
>>>> kernel like FC and distros would not have to worry about it, but since
>>>> they have to get this working for software iscsi do we just keep the
>>>> scanning in userspace?
>>> Our preference is also to have the scanning for all the HBA's which
>>> does the discovery of the tgt's in the kernel space. This way we are
>>> consistent with all the HBA's which does the port discovery like 
>>> the FC HBA's. Our iSCSI HBA's is similar in that regard.
>> Yeah, but your HBA can also function in connection mode and just use
>> open-iscsi's login code too. I am not saying that is that way to go. I
>> am just saying that there are alternatives.
> 
> Agreed. But it was added later on. So the driver always used the session mode.


And we never redo iscsi drivers right ;)


>>> As you have already stated, it simplies support from distro perspective 
>>> as well.
>>>
>> It does for qla4xxx, but I think you then have to go and fix it so
>> iscsi_tcp and iscsi_iser sync up with userspace correctly if you convert
>> them. Either that or we maintain two ways of scanning for iscsi drivers.
> 
> I like the later part. Keeping it seperate.
> 

I think I was only kidding about that option. But now we have votes for
every possible solution :)

You also still have the iSNS issue. That will be in userspace, so one
day you will have to modify the distros to do iscsi root when using iSNS
and use iSNS for installer targets.

Re: [RFC] qla4xxx: TODO for re-submission

[Doug Maxey]

On Mon, 12 Jun 2006 22:30:22 CDT, Mike Christie wrote:
> Ravi Anand wrote:
> >> On Mon, 12 Jun 2006, Mike Christie wrote:
> > 
> >> Date: Mon, 12 Jun 2006 16:35:45 -0500
> >> From: Mike Christie <michaelc@cs.wisc.edu>
> >> To: Ravi Anand <ravi.anand@qlogic.com>
> >> CC: Doug Maxey <dwm@bebe.enoyolf.org>,
> >> 	David Somayajulu <davidcs2005@gmail.com>,
> >> 	Duane Grigsby <duane.grigsby@qlogic.com>,
> >> 	linux-scsi@vger.kernel.org, dwm@austin.ibm.com
> >> Subject: Re: [RFC] qla4xxx: TODO for re-submission
> >> User-Agent: Thunderbird 1.5 (X11/20060313)
> >>
> >> Ravi Anand wrote:
> >>>> On Mon, 12 Jun 2006, Mike Christie wrote:
> >>>> Doug Maxey wrote:
> >>>>> 5) add the block layer code.
> >>>> Some related issues that we have discussed offlist about this and should
> >>>> probably be discussed here are:
> >>>>
> >>>> - Are we supposed to follow FC's lead and remove the devices (rport,
> >>>> session, target, scsi_device, etc) if the dev_loss_tmo fires. Currently
> >>>> for software iscsi, we leave the devices/session. This was to reduce
> >>>> memory allocations and because software iscsi has to basically poll the
> >>>> connection during connect as part of the relogin process. So unlike FC
> >>>> or hw iscsi, if we remove the devices/structs we have to end up
> >>>> rebuilding some of them right away anyways.
> >>>>
> >>>> Removing the devices has the benefit of simplifying the scsi/iscsi code.
> >>>>
> >>>> - Scanning. We currently do scanning for open-iscsi in userspace. For
> >>>> iscsi root this requires distro support. SUSE has it. Fedora is working
> >>>> on it. There is also Debian and Gentoo users or maintainers posting
> >>>> about working on it. For qla4xxx, we could stick the scanning in the
> >>>> kernel like FC and distros would not have to worry about it, but since
> >>>> they have to get this working for software iscsi do we just keep the
> >>>> scanning in userspace?
> >>> Our preference is also to have the scanning for all the HBA's which
> >>> does the discovery of the tgt's in the kernel space. This way we are
> >>> consistent with all the HBA's which does the port discovery like 
> >>> the FC HBA's. Our iSCSI HBA's is similar in that regard.
> >> Yeah, but your HBA can also function in connection mode and just use
> >> open-iscsi's login code too. I am not saying that is that way to go. I
> >> am just saying that there are alternatives.
> > 
> > Agreed. But it was added later on. So the driver always used the session mode.
> 
> 
> And we never redo iscsi drivers right ;)
> 
> 
> >>> As you have already stated, it simplies support from distro perspective 
> >>> as well.
> >>>
> >> It does for qla4xxx, but I think you then have to go and fix it so
> >> iscsi_tcp and iscsi_iser sync up with userspace correctly if you convert
> >> them. Either that or we maintain two ways of scanning for iscsi drivers.
> > 
> > I like the later part. Keeping it seperate.
> > 
> 
> I think I was only kidding about that option. But now we have votes for
> every possible solution :)
> 
> You also still have the iSNS issue. That will be in userspace, so one
> day you will have to modify the distros to do iscsi root when using iSNS
> and use iSNS for installer targets.
> 

Having a common solution (ala ethtool) for the user/admin, across all
SWI, all HBAs, and all distros would be optimal in my view.  Although
the QLogic tools are out there, they only work AFAIK, for the other,
non-mainline drivers.   It is enough pain to manage the targets,  
making one end of the configuration common would be a big bonus.

Re: [RFC] qla4xxx: TODO for re-submission

[Jeff Garzik]

Doug Maxey wrote:
> Having a common solution (ala ethtool) for the user/admin, across all
> SWI, all HBAs, and all distros would be optimal in my view.  Although
> the QLogic tools are out there, they only work AFAIK, for the other,
> non-mainline drivers.   It is enough pain to manage the targets,  
> making one end of the configuration common would be a big bonus.


Why, in fact...  that's the purpose of blktool :)

Vendor-specific code in blktool is quite welcome.  The general idea is 
to manage various vendor-specific capabilities which fit common patterns.

git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/blktool.git
http://sourceforge.net/projects/gkernel/

	Jeff

Re: [RFC] qla4xxx: TODO for re-submission

[Doug Maxey]

On Tue, 13 Jun 2006 00:31:36 EDT, Jeff Garzik wrote:
> Doug Maxey wrote:
> > Having a common solution (ala ethtool) for the user/admin, across all
> > SWI, all HBAs, and all distros would be optimal in my view.  Although
> > the QLogic tools are out there, they only work AFAIK, for the other,
> > non-mainline drivers.   It is enough pain to manage the targets,  
> > making one end of the configuration common would be a big bonus.
> 
> 
> Why, in fact...  that's the purpose of blktool :)

Eureka! You really are prescient. ;)

> 
> Vendor-specific code in blktool is quite welcome.  The general idea is 
> to manage various vendor-specific capabilities which fit common patterns.
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/blktool.git
> http://sourceforge.net/projects/gkernel/

Will check it out.  Thank you.  

++Doug

RE: [RFC] qla4xxx: TODO for re-submission

[berthiaume_wayne]

A one tool fits all is the best solution if your interest is to get
iSCSI and Linux accepted in the enterprise and, especially, the SMB
markets. This should be the goal.  

-----Original Message-----
From: linux-scsi-owner@vger.kernel.org
[mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Jeff Garzik
Sent: Tuesday, June 13, 2006 12:32 AM
To: Doug Maxey
Cc: Mike Christie; Ravi Anand; David Somayajulu; Duane Grigsby;
linux-scsi@vger.kernel.org
Subject: Re: [RFC] qla4xxx: TODO for re-submission

Doug Maxey wrote:
> Having a common solution (ala ethtool) for the user/admin, across all
> SWI, all HBAs, and all distros would be optimal in my view.  Although
> the QLogic tools are out there, they only work AFAIK, for the other,
> non-mainline drivers.   It is enough pain to manage the targets,  
> making one end of the configuration common would be a big bonus.


Why, in fact...  that's the purpose of blktool :)

Vendor-specific code in blktool is quite welcome.  The general idea is 
to manage various vendor-specific capabilities which fit common
patterns.

git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/blktool.git
http://sourceforge.net/projects/gkernel/

	Jeff


-
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

Re: [RFC] qla4xxx: TODO for re-submission

[Ravi Anand]

>On Mon, 12 Jun 2006, Mike Christie wrote:
> Ravi Anand wrote:
> >> On Mon, 12 Jun 2006, Mike Christie wrote:
> > 
> >> Date: Mon, 12 Jun 2006 16:35:45 -0500
> >> From: Mike Christie <michaelc@cs.wisc.edu>
> >> To: Ravi Anand <ravi.anand@qlogic.com>
> >> CC: Doug Maxey <dwm@bebe.enoyolf.org>,
> >> 	David Somayajulu <davidcs2005@gmail.com>,
> >> 	Duane Grigsby <duane.grigsby@qlogic.com>,
> >> 	linux-scsi@vger.kernel.org, dwm@austin.ibm.com
> >> Subject: Re: [RFC] qla4xxx: TODO for re-submission
> >> User-Agent: Thunderbird 1.5 (X11/20060313)
> >>
> >> Ravi Anand wrote:
> >>>> On Mon, 12 Jun 2006, Mike Christie wrote:
> >>>> Doug Maxey wrote:
> >>>>> 5) add the block layer code.
> >>>> Some related issues that we have discussed offlist about this and should
> >>>> probably be discussed here are:
> >>>>
> >>>> - Are we supposed to follow FC's lead and remove the devices (rport,
> >>>> session, target, scsi_device, etc) if the dev_loss_tmo fires. Currently
> >>>> for software iscsi, we leave the devices/session. This was to reduce
> >>>> memory allocations and because software iscsi has to basically poll the
> >>>> connection during connect as part of the relogin process. So unlike FC
> >>>> or hw iscsi, if we remove the devices/structs we have to end up
> >>>> rebuilding some of them right away anyways.
> >>>>
> >>>> Removing the devices has the benefit of simplifying the scsi/iscsi code.
> >>>>
> >>>> - Scanning. We currently do scanning for open-iscsi in userspace. For
> >>>> iscsi root this requires distro support. SUSE has it. Fedora is working
> >>>> on it. There is also Debian and Gentoo users or maintainers posting
> >>>> about working on it. For qla4xxx, we could stick the scanning in the
> >>>> kernel like FC and distros would not have to worry about it, but since
> >>>> they have to get this working for software iscsi do we just keep the
> >>>> scanning in userspace?
> >>> Our preference is also to have the scanning for all the HBA's which
> >>> does the discovery of the tgt's in the kernel space. This way we are
> >>> consistent with all the HBA's which does the port discovery like 
> >>> the FC HBA's. Our iSCSI HBA's is similar in that regard.
> >> Yeah, but your HBA can also function in connection mode and just use
> >> open-iscsi's login code too. I am not saying that is that way to go. I
> >> am just saying that there are alternatives.
> > 
> > Agreed. But it was added later on. So the driver always used the session mode.
> 
> 
> And we never redo iscsi drivers right ;)
> 
> 
> >>> As you have already stated, it simplies support from distro perspective 
> >>> as well.
> >>>
> >> It does for qla4xxx, but I think you then have to go and fix it so
> >> iscsi_tcp and iscsi_iser sync up with userspace correctly if you convert
> >> them. Either that or we maintain two ways of scanning for iscsi drivers.
> > 
> > I like the later part. Keeping it seperate.
> > 
> 
> I think I was only kidding about that option. But now we have votes for
> every possible solution :)
> 
> You also still have the iSNS issue. That will be in userspace, so one
> day you will have to modify the distros to do iscsi root when using iSNS
> and use iSNS for installer targets.

Re: [RFC] qla4xxx: TODO for re-submission

[Ravi Anand]

>On Mon, 12 Jun 2006, Mike Christie wrote:
> Ravi Anand wrote:
> >> On Mon, 12 Jun 2006, Mike Christie wrote:
> > 
> >> Date: Mon, 12 Jun 2006 16:35:45 -0500
> >> From: Mike Christie <michaelc@cs.wisc.edu>
> >> To: Ravi Anand <ravi.anand@qlogic.com>
> >> CC: Doug Maxey <dwm@bebe.enoyolf.org>,
> >> 	David Somayajulu <davidcs2005@gmail.com>,
> >> 	Duane Grigsby <duane.grigsby@qlogic.com>,
> >> 	linux-scsi@vger.kernel.org, dwm@austin.ibm.com
> >> Subject: Re: [RFC] qla4xxx: TODO for re-submission
> >> User-Agent: Thunderbird 1.5 (X11/20060313)
> >>
> >> Ravi Anand wrote:
> >>>> On Mon, 12 Jun 2006, Mike Christie wrote:
> >>>> Doug Maxey wrote:
> >>>>> 5) add the block layer code.
> >>>> Some related issues that we have discussed offlist about this and should
> >>>> probably be discussed here are:
> >>>>
> >>>> - Are we supposed to follow FC's lead and remove the devices (rport,
> >>>> session, target, scsi_device, etc) if the dev_loss_tmo fires. Currently
> >>>> for software iscsi, we leave the devices/session. This was to reduce
> >>>> memory allocations and because software iscsi has to basically poll the
> >>>> connection during connect as part of the relogin process. So unlike FC
> >>>> or hw iscsi, if we remove the devices/structs we have to end up
> >>>> rebuilding some of them right away anyways.
> >>>>
> >>>> Removing the devices has the benefit of simplifying the scsi/iscsi code.
> >>>>
> >>>> - Scanning. We currently do scanning for open-iscsi in userspace. For
> >>>> iscsi root this requires distro support. SUSE has it. Fedora is working
> >>>> on it. There is also Debian and Gentoo users or maintainers posting
> >>>> about working on it. For qla4xxx, we could stick the scanning in the
> >>>> kernel like FC and distros would not have to worry about it, but since
> >>>> they have to get this working for software iscsi do we just keep the
> >>>> scanning in userspace?
> >>> Our preference is also to have the scanning for all the HBA's which
> >>> does the discovery of the tgt's in the kernel space. This way we are
> >>> consistent with all the HBA's which does the port discovery like 
> >>> the FC HBA's. Our iSCSI HBA's is similar in that regard.
> >> Yeah, but your HBA can also function in connection mode and just use
> >> open-iscsi's login code too. I am not saying that is that way to go. I
> >> am just saying that there are alternatives.
> > 
> > Agreed. But it was added later on. So the driver always used the session mode.
> And we never redo iscsi drivers right ;)

This is the one which I wanted to send out. Please discard the previous one.

We really want to fit in with the open-iscsi model. But at this point of time
we will have to live with this for the existing products. Reason being we are
so far down the road with the session mode support in the driver that's it not
possible to revert back to connection mode.

For the future products we are definitely committed to be using connection
mode which fits in very well with the open-iscsi.

And since in the session mode, all the targets has already been discovered
and logged in, it make more sense for  HW iscsi driver to initiate tgt port
scan in the kernel space like we do for FC-rport. I dont think in that
regard iSCSI/FC is any different.

For open-iscsi if I am not mistaken it really initiates the scanning from
userspace thru sysfs, but still tgt/lun scanning happens in the kernel space.

This really simplifies for HW iscsi from booting perspective as well.


> 
> >>> As you have already stated, it simplies support from distro perspective 
> >>> as well.
> >>>
> >> It does for qla4xxx, but I think you then have to go and fix it so
> >> iscsi_tcp and iscsi_iser sync up with userspace correctly if you convert
> >> them. Either that or we maintain two ways of scanning for iscsi drivers.
> > 
> > I like the later part. Keeping it seperate.
> > 
> 
> I think I was only kidding about that option. But now we have votes for
> every possible solution :)
> 
> You also still have the iSNS issue. That will be in userspace, so one
> day you will have to modify the distros to do iscsi root when using iSNS
> and use iSNS for installer targets.

For iSNS in our case, the App's just present the targets, but it still need
to be saved in the flash for it to persistently bound and automatically logged in.
So again its pretty much the same in terms of behaviour from driver perspective
even for non iSNS scenario.


Ravi

Re: [RFC] qla4xxx: TODO for re-submission

[Mike Christie]

Ravi Anand wrote:
>> On Mon, 12 Jun 2006, Mike Christie wrote:
>> Ravi Anand wrote:
>>>> On Mon, 12 Jun 2006, Mike Christie wrote:
>>>> Date: Mon, 12 Jun 2006 16:35:45 -0500
>>>> From: Mike Christie <michaelc@cs.wisc.edu>
>>>> To: Ravi Anand <ravi.anand@qlogic.com>
>>>> CC: Doug Maxey <dwm@bebe.enoyolf.org>,
>>>> 	David Somayajulu <davidcs2005@gmail.com>,
>>>> 	Duane Grigsby <duane.grigsby@qlogic.com>,
>>>> 	linux-scsi@vger.kernel.org, dwm@austin.ibm.com
>>>> Subject: Re: [RFC] qla4xxx: TODO for re-submission
>>>> User-Agent: Thunderbird 1.5 (X11/20060313)
>>>>
>>>> Ravi Anand wrote:
>>>>>> On Mon, 12 Jun 2006, Mike Christie wrote:
>>>>>> Doug Maxey wrote:
>>>>>>> 5) add the block layer code.
>>>>>> Some related issues that we have discussed offlist about this and should
>>>>>> probably be discussed here are:
>>>>>>
>>>>>> - Are we supposed to follow FC's lead and remove the devices (rport,
>>>>>> session, target, scsi_device, etc) if the dev_loss_tmo fires. Currently
>>>>>> for software iscsi, we leave the devices/session. This was to reduce
>>>>>> memory allocations and because software iscsi has to basically poll the
>>>>>> connection during connect as part of the relogin process. So unlike FC
>>>>>> or hw iscsi, if we remove the devices/structs we have to end up
>>>>>> rebuilding some of them right away anyways.
>>>>>>
>>>>>> Removing the devices has the benefit of simplifying the scsi/iscsi code.
>>>>>>
>>>>>> - Scanning. We currently do scanning for open-iscsi in userspace. For
>>>>>> iscsi root this requires distro support. SUSE has it. Fedora is working
>>>>>> on it. There is also Debian and Gentoo users or maintainers posting
>>>>>> about working on it. For qla4xxx, we could stick the scanning in the
>>>>>> kernel like FC and distros would not have to worry about it, but since
>>>>>> they have to get this working for software iscsi do we just keep the
>>>>>> scanning in userspace?
>>>>> Our preference is also to have the scanning for all the HBA's which
>>>>> does the discovery of the tgt's in the kernel space. This way we are
>>>>> consistent with all the HBA's which does the port discovery like 
>>>>> the FC HBA's. Our iSCSI HBA's is similar in that regard.
>>>> Yeah, but your HBA can also function in connection mode and just use
>>>> open-iscsi's login code too. I am not saying that is that way to go. I
>>>> am just saying that there are alternatives.
>>> Agreed. But it was added later on. So the driver always used the session mode.
>> And we never redo iscsi drivers right ;)
> 
> This is the one which I wanted to send out. Please discard the previous one.
> 
> We really want to fit in with the open-iscsi model. But at this point of time
> we will have to live with this for the existing products. Reason being we are
> so far down the road with the session mode support in the driver that's it not
> possible to revert back to connection mode.
> 
> For the future products we are definitely committed to be using connection
> mode which fits in very well with the open-iscsi.
> 
> And since in the session mode, all the targets has already been discovered
> and logged in, it make more sense for  HW iscsi driver to initiate tgt port
> scan in the kernel space like we do for FC-rport. I dont think in that
> regard iSCSI/FC is any different.
>

See below.


> For open-iscsi if I am not mistaken it really initiates the scanning from
> userspace thru sysfs, but still tgt/lun scanning happens in the kernel space.

I think I see where you are going, but for both of these as you can see
from the work JamesS did with the FC class, we are more talking about
the thread work and iscsi state machine bits that are pushed to
userspace. The initiation of the scanning is a big part too, but that is
not all we are talking about.

My only opinion is that if we go to the kernel both should go. I do not
want to mess around with maintaining two paths like we have to with the
connect code. Ditto for the block/unblock code.

> 
> This really simplifies for HW iscsi from booting perspective as well.

Yeah we went over this, I agree if we always are talking about
persistent targets and if we use your FW vs the common open-iscsi db and
if we are assuming distros are not going to add open-iscsi root boot
support.

> 
> 
>>>>> As you have already stated, it simplies support from distro perspective 
>>>>> as well.
>>>>>
>>>> It does for qla4xxx, but I think you then have to go and fix it so
>>>> iscsi_tcp and iscsi_iser sync up with userspace correctly if you convert
>>>> them. Either that or we maintain two ways of scanning for iscsi drivers.
>>> I like the later part. Keeping it seperate.
>>>
>> I think I was only kidding about that option. But now we have votes for
>> every possible solution :)
>>
>> You also still have the iSNS issue. That will be in userspace, so one
>> day you will have to modify the distros to do iscsi root when using iSNS
>> and use iSNS for installer targets.
> 
> For iSNS in our case, the App's just present the targets, but it still need
> to be saved in the flash for it to persistently bound and automatically logged in.
> So again its pretty much the same in terms of behaviour from driver perspective
> even for non iSNS scenario.

So normally when you say target you mean portal. I mean for sendtargets
we set a portals as persistent not a whole target right (this is from
jsut using iscli)? For iSNS, can't we get updates that there are new
portals popping in the san? You are not saying that normally we want to
handle this by starting up a config app and setting them as persistent.
I thought we would want to dyncallically add them to the system.

What is the point of using iSNS and setting the targets as persistent in
the initiator DB anyways? I thought one of the benefits of iSNS is that
we would manage all the targets and initiator access from a central
location?

RE: [RFC] qla4xxx: TODO for re-submission

[David Somayajulu]

> 
> So normally when you say target you mean portal. I mean for
sendtargets
iSCSI Target when there is an iSCSI Name associated with it, otherwise a
portal. I guess it would be clear to say Target Portal and Node instead.

> we set a portals as persistent not a whole target right (this is from
> jsut using iscli)? For iSNS, can't we get updates that there are new
> portals popping in the san? You are not saying that normally we want
to
> handle this by starting up a config app and setting them as
persistent.
That is correct we should field SCN (state change notification) and ESI
(entity status inquiry) events.
> I thought we would want to dyncallically add them to the system.
That is correct.
> 
> What is the point of using iSNS and setting the targets as persistent
in
> the initiator DB anyways? I thought one of the benefits of iSNS is
that
> we would manage all the targets and initiator access from a central
> location?
The HBA architecture allows any iSCSI Target Node or Portal (in case of
Send targets) to be made persistent. It is up to the user to determine
which ones need to be persistent.