[Stgt-devel] uSpace Transport Patch

[Tom Tucker]

Tomo:

At this point, I'm in thee middle of writing the kernel side of the  
iSER transport. It would be no big deal to switch to user mode.  
Should I do it?

We might want to look at the OpenFabric's stack to see how they  
implement kernel bypass. This code has been accepted by kernel.org  
and might provide a workable model or at least a starting point for  
the user-mode iSER target implementation. It supports a very high  
bandwidth, zero copy mechanism for exchanging data and events with  
the kernel.

On Aug 29, 2006, at 9:31 AM, FUJITA Tomonori wrote:

> From: FUJITA Tomonori <fujita.tomonori at lab.ntt.co.jp>
> Subject: Re: [Stgt-devel] uSpace Transport Patch
> Date: Tue, 22 Aug 2006 08:11:29 +0900
>
>> From: Tom Tucker <tom at opengridcomputing.com>
>> Subject: [Stgt-devel] uSpace Transport Patch
>> Date: Mon, 21 Aug 2006 16:29:40 -0500
>>
>>> Tomo:
>>>
>>> Enclosed is a patch that allows you to plug in multiple  
>>> transports. It
>>> has a few benefits over the last approach:
>>
>> Thanks.
>>
>>
>>> 1. The TCP side can remain exactly the same. i.e. user-mode  
>>> connection
>>> management and login send/recv.
>>>
>>> 2. The stgtd implementation still uses pollfd to receive I/O  
>>> events. The
>>>    iser side will provide an fd that can be polled.
>>>
>>>
>>> I have built and run this patch with the current code and  
>>> connected with
>>> a iscsi initiator over TCP. I did encounter problems, however,  
>>> trying to
>>> do disk i/o.
>>
>> The write path code is broken. I will fix it if the kernel-mode
>> approach would likely be accepted into mainline.
>
> Mike posted the kernel-mode iSCSI target patch to scsi-ml several days
> ago.
>
> http://marc.theaimsgroup.com/?l=linux-scsi&m=115639258024577&w=2
>
> We've got any responses so far. It means that we might get a refusal
> later on after some effort on the kernel-mode approach. That inclines
> me to go with the user-space approach...
> _______________________________________________
> Stgt-devel mailing list
> Stgt-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/stgt-devel