[PATCH] iscsi driver update 4.0.1.8

[PATCH] iscsi driver update 4.0.1.8

[Naveen Burmi]

This version of the iSCSI driver (4.0.1.8) contains the following changes
since 4.0.1.7:

1. The issue of deadlock due to multiple kmaps has been partially resolved.
   We now use sendpage along the xmit path.
2. The driver used to overwrite scsi midlayer naming. This has been removed.
   Now proc_name field is used for iSCSI device lookup in sysfs.
3. The driver's queuecommand now returns SCSI_MLQUEUE_DEVICE_BUSY and
   SCSI_MLQUEUE_HOST_BUSY on failure.
4. We have removed bus reset handler from the code.

The following items are being worked on/debated:

a) Per target probe via hotplug.
In earlier reviews, it was debated that the hotplug mechanism should be used
for target activation. Though scsi_scan_host() is exported,
scsi_scan_host_selected() isn't. So, an adapter scan is exported to LLDD
whereas anything else (target or lun scan) has to go through hotplug.
Network oriented storage like iSCSI has to deal with delays in targets
getting discovered through SendTargets discovery and poll for SLP
discoveries.
It would help a lot to use scsi_scan_host_selected() in such cases and needs
to be exported for such LLDDs.

b) Removal of multiple kmaps from recv path.

c) Use of TCQ from include/linux/scsi_tcq.h

4.0.1.8 release of linux iscsi driver also contains an incremental patch 
against 4.0.1.7 release. (linux-iscsi-kernel-4.0.1.7-incremental.patch)

The driver was not included as a patch because the file is too big, but it can 
be downloaded from:

http://sourceforge.net/project/showfiles.php?group_id=26396&package_id=106938&release_id=252559

P.S. The current driver is tested against 2.6.7 linux kernel.

Thanks,
Naveen.

Re: [PATCH] iscsi driver update 4.0.1.8

[Matthew Wilcox]

On Thu, Jul 15, 2004 at 04:02:45PM +0530, Naveen Burmi wrote:
> The driver was not included as a patch because the file is too big, but it can 
> be downloaded from:
> 
> http://sourceforge.net/project/showfiles.php?group_id=26396&package_id=106938&release_id=252559

$ wget 'http://sourceforge.net/project/showfiles.php?group_id=26396&package_id=106938&release_id=252559'
--07:26:36--  http://sourceforge.net/project/showfiles.php?group_id=26396&package_id=106938&release_id=252559
           => `showfiles.php?group_id=26396&package_id=106938&release_id=252559'
Resolving sourceforge.net... 66.35.250.203
Connecting to sourceforge.net[66.35.250.203]:80... connected.
HTTP request sent, awaiting response... 404 Not Found
07:26:36 ERROR 404: Not Found.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

RE: [PATCH] iscsi driver update 4.0.1.8

[Surekha.PC]

FYI, Sourceforge site is currently down for maintenance reason.
Hence the link is unaccessible.

thanks,
surekha

> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org 
> [mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Matthew Wilcox
> Sent: Thursday, July 15, 2004 4:57 PM
> To: Naveen Burmi
> Cc: Linux-SCSI Mailing List
> Subject: Re: [PATCH] iscsi driver update 4.0.1.8
> 
> 
> On Thu, Jul 15, 2004 at 04:02:45PM +0530, Naveen Burmi wrote:
> > The driver was not included as a patch because the file is too big, 
> > but it can
> > be downloaded from:
> > 
> > 
> http://sourceforge.net/project/showfiles.php?> group_id=26396&package_id
> > =106938&release_id=252559
> 
> $ wget 
> 'http://sourceforge.net/project/showfiles.php?group_id=26396&p
ackage_id=106938&release_id=252559'
--07:26:36--
http://sourceforge.net/project/showfiles.php?group_id=26396&package_id=106938&release_id=252559
           => `showfiles.php?group_id=26396&package_id=106938&release_id=252559'
Resolving sourceforge.net... 66.35.250.203
Connecting to sourceforge.net[66.35.250.203]:80... connected. HTTP request sent, awaiting
response... 404 Not Found 07:26:36 ERROR 404: Not Found.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and
will diligently study them, and refuse to examine any refutations of them; and thus he will by and
by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain
-
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: [PATCH] iscsi driver update 4.0.1.8

[Matthew Wilcox]

On Thu, Jul 15, 2004 at 05:08:10PM +0530, Surekha.PC wrote:
> 
> FYI, Sourceforge site is currently down for maintenance reason.
> Hence the link is unaccessible.

Could you post the patch somewhere more reliable?  It's kind of hard to
review it when you can't get it ;-)  If all else fails, send me a copy
privately and I'll stick it somewhere.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [PATCH] iscsi driver update 4.0.1.8

[Mike Christie]

Naveen Burmi wrote:

> This version of the iSCSI driver (4.0.1.8) contains the following changes
> since 4.0.1.7:
> 
> 1. The issue of deadlock due to multiple kmaps has been partially resolved.
>    We now use sendpage along the xmit path.
> 2. The driver used to overwrite scsi midlayer naming. This has been removed.
>    Now proc_name field is used for iSCSI device lookup in sysfs.
> 3. The driver's queuecommand now returns SCSI_MLQUEUE_DEVICE_BUSY and
>    SCSI_MLQUEUE_HOST_BUSY on failure.
> 4. We have removed bus reset handler from the code.
> 
> The following items are being worked on/debated:
> 
> a) Per target probe via hotplug.
> In earlier reviews, it was debated that the hotplug mechanism should be used
> for target activation. Though scsi_scan_host() is exported,
> scsi_scan_host_selected() isn't. So, an adapter scan is exported to LLDD
> whereas anything else (target or lun scan) has to go through hotplug.
> Network oriented storage like iSCSI has to deal with delays in targets
> getting discovered through SendTargets discovery and poll for SLP
> discoveries.
> It would help a lot to use scsi_scan_host_selected() in such cases and needs
> to be exported for such LLDDs.

What is wrong with doing everything from userspace? If we do discovery 
in userspace and send down that info from usrspace, why not kick off the 
scanning from userspace once the establish session ioctl has completed? 
The driver today does not handle userspace initiated scans correctly, so 
this needs to be addressed regardless?

The other question is are you advocating that the report luns data 
changed event no longer be handled from userspace? If 
scsi_scan_host_selected() is exported are you going to detect the event 
in the driver, kick off to userpace, then have some event agent go back 
down to the driver to use scsi_scan_host_selected()? Or are you wanting 
scsi_scan_host_selected() for your lun masking. I sent patches to kill 
the latter and it will hopefully not exists in this lld in the near future.

Re: [PATCH] iscsi driver update 4.0.1.8

[Mike Christie]

Mike Christie wrote:

> Naveen Burmi wrote:
> down to the driver to use scsi_scan_host_selected()? Or are you wanting 
> scsi_scan_host_selected() for your lun masking. I sent patches to kill 
> the latter and it will hopefully not exists in this lld in the near future.

Oh yeah the argument that you need the lun masking due to the lun limits 
is BS. I sent patches to fix this too.

Re: [PATCH] iscsi driver update 4.0.1.8

[Mike Christie]

Mike Christie wrote:

> down to the driver to use scsi_scan_host_selected()? Or are you wanting 
> scsi_scan_host_selected() for your lun masking. I sent patches to kill 
> the latter and it will hopefully not exists in this lld in the near future.

Oh yeah the argument that you need the lun masking due to the lun limits 
is BS. I sent patches to fix this too.

Re: [PATCH] iscsi driver update 4.0.1.8

[Mike Christie]

Mike Christie wrote:

> Naveen Burmi wrote:
> 
>> This version of the iSCSI driver (4.0.1.8) contains the following changes
>> since 4.0.1.7:
>>
>> 1. The issue of deadlock due to multiple kmaps has been partially 
>> resolved.
>>    We now use sendpage along the xmit path.
>> 2. The driver used to overwrite scsi midlayer naming. This has been 
>> removed.
>>    Now proc_name field is used for iSCSI device lookup in sysfs.
>> 3. The driver's queuecommand now returns SCSI_MLQUEUE_DEVICE_BUSY and
>>    SCSI_MLQUEUE_HOST_BUSY on failure.
>> 4. We have removed bus reset handler from the code.
>>
>> The following items are being worked on/debated:
>>
>> a) Per target probe via hotplug.
>> In earlier reviews, it was debated that the hotplug mechanism should 
>> be used
>> for target activation. Though scsi_scan_host() is exported,
>> scsi_scan_host_selected() isn't. So, an adapter scan is exported to LLDD
>> whereas anything else (target or lun scan) has to go through hotplug.
>> Network oriented storage like iSCSI has to deal with delays in targets
>> getting discovered through SendTargets discovery and poll for SLP
>> discoveries.
>> It would help a lot to use scsi_scan_host_selected() in such cases and 
>> needs
>> to be exported for such LLDDs.
> 
> 
> What is wrong with doing everything from userspace? If we do discovery 
> in userspace and send down that info from usrspace, why not kick off the 
> scanning from userspace once the establish session ioctl has completed? 
> The driver today does not handle userspace initiated scans correctly, so 
> this needs to be addressed regardless?
> 

I sent a patch to linux-iscsi yesterday that implements James's 
suggestion to do a scsi-host-per-transport-endpoint. As we discussed, 
with this change we do not have any special needs (like to scan specific 
targets), so we can just use scsi_scan_host() like regular drivers do.

Also per our discussion, handling the report luns data changed 
asynchronous event is not critical to the driver at this point, so it 
may be best to work on critical cleanups and worry about events when 
SCSI-ml has a well designed event mechanism or when we have finished the 
basic driver items. This should also reduce the work any reviewer would 
have to do for the driver when we feel we are ready for a review.