Re: [PATCH] iscsid to run in conjunction with the Broadcom uIP stack
Mike Christie wrote: > On 06/12/2009 07:10 AM, Rakesh Ranjan wrote: >> Mike Christie wrote: >>> On 06/09/2009 12:50 PM, Benjamin Li wrote: 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. >>> I like this idea too. I can help. >> >> Hi Mike, >> >> What's your opinion about interfaces, that iscsid should provide to >> support uIP/vendor library scheme. I am working on this, it would be >> helpful to have your thoughts on it. >> > > At this point I am not sure. What are you guys planning on using from > their uip and where are you guys breaking from it? Maybe a rough draft > implemtnation would be good. It does not have to work or even compile. > Just something high level (even a RFC email would do) so I can get a > idea of what craziness everyone is doing :) Okay, RFC would be good. I will post it soon :). 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 -~--~~~~--~~--~--~---
Re: [PATCH] iscsid to run in conjunction with the Broadcom uIP stack
On 06/12/2009 07:10 AM, Rakesh Ranjan wrote: > Mike Christie wrote: >> On 06/09/2009 12:50 PM, Benjamin Li wrote: >>> 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. >>> >> I like this idea too. I can help. > > Hi Mike, > > What's your opinion about interfaces, that iscsid should provide to > support uIP/vendor library scheme. I am working on this, it would be > helpful to have your thoughts on it. > At this point I am not sure. What are you guys planning on using from their uip and where are you guys breaking from it? Maybe a rough draft implemtnation would be good. It does not have to work or even compile. Just something high level (even a RFC email would do) so I can get a idea of what craziness everyone is doing :) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [PATCH] iscsid to run in conjunction with the Broadcom uIP stack
Mike Christie wrote: > On 06/09/2009 12:50 PM, Benjamin Li wrote: >> 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. >> > > I like this idea too. I can help. Hi Mike, What's your opinion about interfaces, that iscsid should provide to support uIP/vendor library scheme. I am working on this, it would be helpful to have your thoughts on it. 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 -~--~~~~--~~--~--~---
Re: [PATCH] iscsid to run in conjunction with the Broadcom uIP stack
On 06/09/2009 12:50 PM, Benjamin Li wrote: > 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. > I like this idea too. I can help. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [PATCH] iscsid to run in conjunction with the Broadcom uIP stack
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 -~--~~~~--~~--~--~---
Re: [PATCH] iscsid to run in conjunction with the Broadcom uIP stack
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 -~--~~~~--~~--~--~---
Re: [PATCH] iscsid to run in conjunction with the Broadcom uIP stack
On Thu, 2009-06-04 at 03:51 -0700, Rakesh Ranjan wrote: > Benjamin Li wrote: > > > > Note: There is still some legacy code where I need a make a cleaner > > division between the stack and hardware implementation. This is because > > there is still some areas in the uIP stack where it makes an assumption > > that UIO will be used to talk directly to the hardware and to send data. > > > Hi Li, > > It would be really nice if tight dependency between uIP and UIO could be > converted intro more generic ones, so that even other mechanism could be > hooked into uIP other than UIO based. > > Regards > Rakesh Ranjan > > > > 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. Thanks again. -Ben --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [PATCH] iscsid to run in conjunction with the Broadcom uIP stack
Hi Mike, I will discuss how uio will be distributed with Michael tomorrow, and we will get back with you. I agree with your line of thinking in creating a unified front on iscsi configuration. But, there is still work to be done to eliminate the uio configuration file completely. I haven't gotten a chance to write any documentation on how to hook additional software. But Chelsio could hook in via a shared library, like how the Broadcom CNIC/BNX2I hooks into the uio stack. They can take a look at the example cnic.c source in the directory, 'src/unix/libs/' of the uio tarbarll. They can focus particularly on exporting a get_ops() function, the nic_lib_ops structure and nic_ops structure. These are the main entry points into the uIP stack and the callback's that uio will use. Note: There is still some legacy code where I need a make a cleaner division between the stack and hardware implementation. This is because there is still some areas in the uIP stack where it makes an assumption that UIO will be used to talk directly to the hardware and to send data. Please feel free to contact me with any questions. Thanks again. -Ben On Wed, 2009-06-03 at 13:39 -0700, Mike Christie wrote: > Benjamin Li wrote: > > Hi Mike, > > > > I have attached the uio source here in this email. This should be the > > same as the tarfile I have attached to the RHEL 442418 bugzilla report > > on 2009-05-21 23:05 EDT. Please let me know if the tarfiles aren't the > > same. The website to host the uIP is still not just quite ready yet. > > > > So are you guys planning on distrubuting uio with open-iscsi or separately? > > My preference is with open-iscsi because I think it will be easier for > users to have it all in one place/package. If we could also avoid having > multiple config files or at least multiple config file formats it would > be nice too. If users did not have to sit and think about if something > goes in a uip or iscsid config file and what format the config file used > it would be nice for them. It is weird to configure part of the > initiator with one format and the other part of the initiator with > another (I do not think this is a high priority at first). > > > For the code, I was wondering if there is any pointers on how to hook in > other drivers. The Chelsio devs have started looking into this. > > > > Thanks again. > > > > -Ben > > > > On Mon, 2009-06-01 at 16:03 -0700, Mike Christie wrote: > >> Benjamin Li wrote: > >>> Hi All, > >>> > >>> This patch is used in conjunction with the bnx2i patch Michael Chan sent > >>> eariler to the scsi mailing lists. This is part of the userspace > >>> portion of the Broadcom iSCSI offload solution. This patch is needed > >>> because the uIP stack will use some of the configuration data from the > >>> iface file to determine the iSCSI IP address. > >>> > >>> The uIP source code will be posted to the web soon, and I will provide a > >>> link when the website is up and running. > >>> > >>> Please feel free to contact me with any questions or concerns. > >>> Thanks again. > >>> > >> I am doing some cleanup to this code. Do you by any change have any uio > >> parts you can share? I do not care if it is production ready. I just > >> want to check for regressions in my changes., > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [PATCH] iscsid to run in conjunction with the Broadcom uIP stack
Benjamin Li wrote: > Hi Mike, > > I have attached the uio source here in this email. This should be the > same as the tarfile I have attached to the RHEL 442418 bugzilla report > on 2009-05-21 23:05 EDT. Please let me know if the tarfiles aren't the > same. The website to host the uIP is still not just quite ready yet. > So are you guys planning on distrubuting uio with open-iscsi or separately? My preference is with open-iscsi because I think it will be easier for users to have it all in one place/package. If we could also avoid having multiple config files or at least multiple config file formats it would be nice too. If users did not have to sit and think about if something goes in a uip or iscsid config file and what format the config file used it would be nice for them. It is weird to configure part of the initiator with one format and the other part of the initiator with another (I do not think this is a high priority at first). For the code, I was wondering if there is any pointers on how to hook in other drivers. The Chelsio devs have started looking into this. > Thanks again. > > -Ben > > On Mon, 2009-06-01 at 16:03 -0700, Mike Christie wrote: >> Benjamin Li wrote: >>> Hi All, >>> >>> This patch is used in conjunction with the bnx2i patch Michael Chan sent >>> eariler to the scsi mailing lists. This is part of the userspace >>> portion of the Broadcom iSCSI offload solution. This patch is needed >>> because the uIP stack will use some of the configuration data from the >>> iface file to determine the iSCSI IP address. >>> >>> The uIP source code will be posted to the web soon, and I will provide a >>> link when the website is up and running. >>> >>> Please feel free to contact me with any questions or concerns. >>> Thanks again. >>> >> I am doing some cleanup to this code. Do you by any change have any uio >> parts you can share? I do not care if it is production ready. I just >> want to check for regressions in my changes., > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [PATCH] iscsid to run in conjunction with the Broadcom uIP stack
Benjamin Li wrote: > Hi All, > > This patch is used in conjunction with the bnx2i patch Michael Chan sent > eariler to the scsi mailing lists. This is part of the userspace > portion of the Broadcom iSCSI offload solution. This patch is needed > because the uIP stack will use some of the configuration data from the > iface file to determine the iSCSI IP address. > > The uIP source code will be posted to the web soon, and I will provide a > link when the website is up and running. > > Please feel free to contact me with any questions or concerns. > Thanks again. > I am doing some cleanup to this code. Do you by any change have any uio parts you can share? I do not care if it is production ready. I just want to check for regressions in my changes. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[PATCH] iscsid to run in conjunction with the Broadcom uIP stack
Hi All, This patch is used in conjunction with the bnx2i patch Michael Chan sent eariler to the scsi mailing lists. This is part of the userspace portion of the Broadcom iSCSI offload solution. This patch is needed because the uIP stack will use some of the configuration data from the iface file to determine the iSCSI IP address. The uIP source code will be posted to the web soon, and I will provide a link when the website is up and running. Please feel free to contact me with any questions or concerns. Thanks again. -Ben Benjamin Li (1): iscsid: Broadcast iface record to uIP usr/Makefile |2 +- usr/initiator.c|5 +++ usr/transport.c|5 +++ usr/transport.h|3 ++ usr/uip_mgmt_ipc.c | 41 +++ usr/uip_mgmt_ipc.h | 71 +++ usr/util.c | 78 ++-- usr/util.h |3 ++ 8 files changed, 204 insertions(+), 4 deletions(-) create mode 100644 usr/uip_mgmt_ipc.c create mode 100644 usr/uip_mgmt_ipc.h --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
