Hi Rakesh,

Your idea of eliminating the 'brcm_iscsiuio' daemon and integrating that
code as a shared library into iscsid is a great idea.  Just having the
iscsid daemon to configure and run would make it easier for the end
user.  But pushing for this would be an long term goal for me because
currently, I do not have enough free cycles to accomplish this in the
foreseeable future.

The following changes would need to occur for this idea to work:

*  change iscsid to recognize the new configuration options
*  eliminate the UNIX socket layer code between 'brcm_iscsiuio' and
iscsid and replace it with new code so that the uIP could directly
access iscsid data
*  stabilize the uIP code so that a crash/hang doesn't take down iscsid,
also the uIP code still is changing and should be stabilized
*  continue to separate the uIP stack with hardware specific UIO code.
*  change uIP utility functions (ie. logging, wrappers) to use the
routines provided by iscsid.

I think it is a great idea, if I or someone get some time to work on
this, I think it would make the iscsi offload solution much simpler.

Thanks again.

-Ben


On Tue, 2009-06-09 at 04:50 -0700, Rakesh Ranjan wrote: 
> Benjamin Li wrote:
> > On Thu, 2009-06-04 at 03:51 -0700, Rakesh Ranjan wrote:
> 
> >>>
> > Hi Rakesh,
> > 
> > Converting the dependency between uIP and UIO shouldn't be a problem.
> > We can make them more generic.  I apologize if it is a tad bit of a
> > mess.  The coupling of uIP and UIO was from early versions of uIP; I
> > haven't had the time to think, work, and clean up the code to accomplish
> > this.  =(
> > 
> > Please let me know what your plans are on how the Chelsio driver will
> > communicate from user-space to the hardware and we can add/modify the
> > hooks in the uIP stack.
> > 
> 
> Hi Li,
> 
> Isn't it possible to get rid of __brcm_iscsiuio__ daemon and move the 
> related userspace UIO implementation into vendor provided library and do 
> the needed modification into __iscsid__, so that depending upon 
> configuration __iscsid__ would utilize the vendor provided hooks inside 
> the vendor library to send/recv events. IMHO it would be neat approach.
> 
> To provide configurable option to vendor library we could use 
> __iface/nic0__ interface.
> 
> Ex.
> 
> iface.nic_handler = "lib_handler.so";
> iface.rx_poll_usec = "10";
> iface.nic_dev = "/dev/uio0"
> 
> Regards
> Rakesh Ranjan
> 



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to