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

[Ravi Anand <ravi.anand@qlogic.com>]

>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