Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
On Tue, 2013-06-11 at 13:26 -0500, Mike Christie wrote: > On 06/11/2013 12:43 PM, Eddie Wai wrote: > > > > On Tue, 2013-06-11 at 12:25 -0500, Mike Christie wrote: > >> On 6/10/13 10:47 PM, Vikas Chaudhary wrote: > >>> > >>> > >>> -Original Message- > >>> From: Eddie Wai > >>> Date: Wednesday 5 June 2013 7:00 AM > >>> To: "shyam_i...@dell.com" > >>> Cc: "open-iscsi@googlegroups.com" , Vikas > >>> , Lalit Chandivade > >>> , Ravi Anand , > >>> Poornima Vonti , Manish Rangankar > >>> , Adheer Chandravanshi > >>> > >>> Subject: RE: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt > >>> support > >>> > >>>> > >>>> On Wed, 2013-05-29 at 14:37 -0700, shyam_i...@dell.com wrote: > >>>>> > >>>>>> -Original Message- > >>>>>> From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] > >>>>>> On Behalf Of Mike Christie > >>>>>> Sent: Wednesday, May 29, 2013 1:30 PM > >>>>>> To: open-iscsi@googlegroups.com > >>>>>> Cc: Eddie Wai; vikas.chaudh...@qlogic.com; > >>>>> lalit.chandiv...@qlogic.com; > >>>>>> ravi.an...@qlogic.com; poornima.vo...@qlogic.com; > >>>>>> manish.rangan...@qlogic.com; Adheer Chandravanshi > >>>>>> Subject: Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node > >>>>> mgmt > >>>>>> support > >>>>>> > >>>>>> On 05/29/2013 12:23 PM, Eddie Wai wrote: > >>>>>>> > >>>>>>> On Wed, 2013-05-29 at 10:26 -0500, Mike Christie wrote: > >>>>>>>> On 05/28/2013 07:35 PM, Eddie Wai wrote: > >>>>>>>>> Hello Mike, Vikas, and all, > >>>>>>>>> > >>>>>>>>> Thanks for the great work in creating the flash node mechanism! > >>>>>>>>> > >>>>>>>>> To extend the conversation we had to add support for software and > >>>>>>>>> other offload solutions that requires iscsid/iscsiadm to create > >>>>> the > >>>>>>>>> sessions, the following needs to be further discussed: > >>>>>>>>> > >>>>>>>>> 1. Flash node creation. > >>>>>>>>> > >>>>>>>>> The current solution relies on the transport driver to initiate > >>>>> the > >>>>>>>>> flash node sysfs creation upon iscsi_host allocation. This > >>>>> presents > >>>>>>>>> a fundamental problem for software iSCSI as new iscsi_host > >>>>> instance > >>>>>>>>> won't get created until there's a session initiation. > >>>>>>>>> > >>>>>>>>> Per our conversation, I think it makes sense to move the flash > >>>>> node > >>>>>>>>> initiation code altogether to a separate module like how its done > >>>>>>>>> for ibft. The new module shall cycle through each existing iSCSI > >>>>>>>>> host and query the corresponding transport to fill the flash node > >>>>>>>>> sysfs entries specific to that host. Perhaps via a new transport > >>>>> callback > >>>>>> or so. > >>>>>>>> > >>>>>>>> Agree. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Since there won't be any pre-existing host created for software > >>>>>>>>> iSCSI, this needs to be handled differently. Instead, the new > >>>>>>>>> module will also need to cycle through each network interfaces > >>>>>>>>> present and query for the flash node content separately. > >>>>>>>>> > >>>>>>>>> To accomplish this, each network interface will need to be made > >>>>>>>>> aware of flash nodes and also provide a way for the new module to > >>>>>>>>> read out the flash node content. Per our conversation, this can > >>&g
Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
On 06/11/2013 12:43 PM, Eddie Wai wrote: > > On Tue, 2013-06-11 at 12:25 -0500, Mike Christie wrote: >> On 6/10/13 10:47 PM, Vikas Chaudhary wrote: >>> >>> >>> -Original Message- >>> From: Eddie Wai >>> Date: Wednesday 5 June 2013 7:00 AM >>> To: "shyam_i...@dell.com" >>> Cc: "open-iscsi@googlegroups.com" , Vikas >>> , Lalit Chandivade >>> , Ravi Anand , >>> Poornima Vonti , Manish Rangankar >>> , Adheer Chandravanshi >>> >>> Subject: RE: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt >>> support >>> >>>> >>>> On Wed, 2013-05-29 at 14:37 -0700, shyam_i...@dell.com wrote: >>>>> >>>>>> -Original Message- >>>>>> From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] >>>>>> On Behalf Of Mike Christie >>>>>> Sent: Wednesday, May 29, 2013 1:30 PM >>>>>> To: open-iscsi@googlegroups.com >>>>>> Cc: Eddie Wai; vikas.chaudh...@qlogic.com; >>>>> lalit.chandiv...@qlogic.com; >>>>>> ravi.an...@qlogic.com; poornima.vo...@qlogic.com; >>>>>> manish.rangan...@qlogic.com; Adheer Chandravanshi >>>>>> Subject: Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node >>>>> mgmt >>>>>> support >>>>>> >>>>>> On 05/29/2013 12:23 PM, Eddie Wai wrote: >>>>>>> >>>>>>> On Wed, 2013-05-29 at 10:26 -0500, Mike Christie wrote: >>>>>>>> On 05/28/2013 07:35 PM, Eddie Wai wrote: >>>>>>>>> Hello Mike, Vikas, and all, >>>>>>>>> >>>>>>>>> Thanks for the great work in creating the flash node mechanism! >>>>>>>>> >>>>>>>>> To extend the conversation we had to add support for software and >>>>>>>>> other offload solutions that requires iscsid/iscsiadm to create >>>>> the >>>>>>>>> sessions, the following needs to be further discussed: >>>>>>>>> >>>>>>>>> 1. Flash node creation. >>>>>>>>> >>>>>>>>> The current solution relies on the transport driver to initiate >>>>> the >>>>>>>>> flash node sysfs creation upon iscsi_host allocation. This >>>>> presents >>>>>>>>> a fundamental problem for software iSCSI as new iscsi_host >>>>> instance >>>>>>>>> won't get created until there's a session initiation. >>>>>>>>> >>>>>>>>> Per our conversation, I think it makes sense to move the flash >>>>> node >>>>>>>>> initiation code altogether to a separate module like how its done >>>>>>>>> for ibft. The new module shall cycle through each existing iSCSI >>>>>>>>> host and query the corresponding transport to fill the flash node >>>>>>>>> sysfs entries specific to that host. Perhaps via a new transport >>>>> callback >>>>>> or so. >>>>>>>> >>>>>>>> Agree. >>>>>>>> >>>>>>>>> >>>>>>>>> Since there won't be any pre-existing host created for software >>>>>>>>> iSCSI, this needs to be handled differently. Instead, the new >>>>>>>>> module will also need to cycle through each network interfaces >>>>>>>>> present and query for the flash node content separately. >>>>>>>>> >>>>>>>>> To accomplish this, each network interface will need to be made >>>>>>>>> aware of flash nodes and also provide a way for the new module to >>>>>>>>> read out the flash node content. Per our conversation, this can >>>>> be >>>>>>>>> done via an extension of the ethtool utility. For unsupported >>>>>>>>> network drivers, this >>>>>>>> >>>>>>>> I do not remember that discussion. Has it been discussed with the >>>>>>>> netdev people already? >>>>>>> This has only been discussed internally so far, but we believe
Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
On Tue, 2013-06-11 at 12:25 -0500, Mike Christie wrote: > On 6/10/13 10:47 PM, Vikas Chaudhary wrote: > > > > > > -Original Message- > > From: Eddie Wai > > Date: Wednesday 5 June 2013 7:00 AM > > To: "shyam_i...@dell.com" > > Cc: "open-iscsi@googlegroups.com" , Vikas > > , Lalit Chandivade > > , Ravi Anand , > > Poornima Vonti , Manish Rangankar > > , Adheer Chandravanshi > > > > Subject: RE: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt > > support > > > >> > >> On Wed, 2013-05-29 at 14:37 -0700, shyam_i...@dell.com wrote: > >>> > >>>> -Original Message- > >>>> From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] > >>>> On Behalf Of Mike Christie > >>>> Sent: Wednesday, May 29, 2013 1:30 PM > >>>> To: open-iscsi@googlegroups.com > >>>> Cc: Eddie Wai; vikas.chaudh...@qlogic.com; > >>> lalit.chandiv...@qlogic.com; > >>>> ravi.an...@qlogic.com; poornima.vo...@qlogic.com; > >>>> manish.rangan...@qlogic.com; Adheer Chandravanshi > >>>> Subject: Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node > >>> mgmt > >>>> support > >>>> > >>>> On 05/29/2013 12:23 PM, Eddie Wai wrote: > >>>>> > >>>>> On Wed, 2013-05-29 at 10:26 -0500, Mike Christie wrote: > >>>>>> On 05/28/2013 07:35 PM, Eddie Wai wrote: > >>>>>>> Hello Mike, Vikas, and all, > >>>>>>> > >>>>>>> Thanks for the great work in creating the flash node mechanism! > >>>>>>> > >>>>>>> To extend the conversation we had to add support for software and > >>>>>>> other offload solutions that requires iscsid/iscsiadm to create > >>> the > >>>>>>> sessions, the following needs to be further discussed: > >>>>>>> > >>>>>>> 1. Flash node creation. > >>>>>>> > >>>>>>> The current solution relies on the transport driver to initiate > >>> the > >>>>>>> flash node sysfs creation upon iscsi_host allocation. This > >>> presents > >>>>>>> a fundamental problem for software iSCSI as new iscsi_host > >>> instance > >>>>>>> won't get created until there's a session initiation. > >>>>>>> > >>>>>>> Per our conversation, I think it makes sense to move the flash > >>> node > >>>>>>> initiation code altogether to a separate module like how its done > >>>>>>> for ibft. The new module shall cycle through each existing iSCSI > >>>>>>> host and query the corresponding transport to fill the flash node > >>>>>>> sysfs entries specific to that host. Perhaps via a new transport > >>> callback > >>>> or so. > >>>>>> > >>>>>> Agree. > >>>>>> > >>>>>>> > >>>>>>> Since there won't be any pre-existing host created for software > >>>>>>> iSCSI, this needs to be handled differently. Instead, the new > >>>>>>> module will also need to cycle through each network interfaces > >>>>>>> present and query for the flash node content separately. > >>>>>>> > >>>>>>> To accomplish this, each network interface will need to be made > >>>>>>> aware of flash nodes and also provide a way for the new module to > >>>>>>> read out the flash node content. Per our conversation, this can > >>> be > >>>>>>> done via an extension of the ethtool utility. For unsupported > >>>>>>> network drivers, this > >>>>>> > >>>>>> I do not remember that discussion. Has it been discussed with the > >>>>>> netdev people already? > >>>>> This has only been discussed internally so far, but we believe > >>> adding > >>>>> a new ethtool extension for this flash memory access is one logical > >>>>> way that the netdev community can accept. > >>>>>> > >>>>>> Why does the new module need to cycle through e
Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
On 6/10/13 10:47 PM, Vikas Chaudhary wrote: -Original Message- From: Eddie Wai Date: Wednesday 5 June 2013 7:00 AM To: "shyam_i...@dell.com" Cc: "open-iscsi@googlegroups.com" , Vikas , Lalit Chandivade , Ravi Anand , Poornima Vonti , Manish Rangankar , Adheer Chandravanshi Subject: RE: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support On Wed, 2013-05-29 at 14:37 -0700, shyam_i...@dell.com wrote: -Original Message- From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On Behalf Of Mike Christie Sent: Wednesday, May 29, 2013 1:30 PM To: open-iscsi@googlegroups.com Cc: Eddie Wai; vikas.chaudh...@qlogic.com; lalit.chandiv...@qlogic.com; ravi.an...@qlogic.com; poornima.vo...@qlogic.com; manish.rangan...@qlogic.com; Adheer Chandravanshi Subject: Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support On 05/29/2013 12:23 PM, Eddie Wai wrote: On Wed, 2013-05-29 at 10:26 -0500, Mike Christie wrote: On 05/28/2013 07:35 PM, Eddie Wai wrote: Hello Mike, Vikas, and all, Thanks for the great work in creating the flash node mechanism! To extend the conversation we had to add support for software and other offload solutions that requires iscsid/iscsiadm to create the sessions, the following needs to be further discussed: 1. Flash node creation. The current solution relies on the transport driver to initiate the flash node sysfs creation upon iscsi_host allocation. This presents a fundamental problem for software iSCSI as new iscsi_host instance won't get created until there's a session initiation. Per our conversation, I think it makes sense to move the flash node initiation code altogether to a separate module like how its done for ibft. The new module shall cycle through each existing iSCSI host and query the corresponding transport to fill the flash node sysfs entries specific to that host. Perhaps via a new transport callback or so. Agree. Since there won't be any pre-existing host created for software iSCSI, this needs to be handled differently. Instead, the new module will also need to cycle through each network interfaces present and query for the flash node content separately. To accomplish this, each network interface will need to be made aware of flash nodes and also provide a way for the new module to read out the flash node content. Per our conversation, this can be done via an extension of the ethtool utility. For unsupported network drivers, this I do not remember that discussion. Has it been discussed with the netdev people already? This has only been discussed internally so far, but we believe adding a new ethtool extension for this flash memory access is one logical way that the netdev community can accept. Why does the new module need to cycle through each net device? Can't a net driver that knows it supports this just call into the new module to register itself when it is loaded? When it registers it can create any sysfs/netlink stuff needed so userspace can detect it and access it. That would work too, but our proposal essentially is tailored toward minimizing any storage specific code in the network drivers. Note that our proposal is to add an ethtool extension which will provide read/write access directly to the flash memory. It will not do any sysfs creation or parameter qualification. It only provides a gateway to the flash memory, that's it. It will be up to the new module to initiate, create, and manage over those sysfs parameters. Sounds ok to me. Perhaps we can add some minor initiation code in the network driver to perhaps 'register' some flag so the new module will only have to cycle through a list of supported network interfaces only. It is ok. I was just thinking along the lines of either ethtool or iscsi mod only. I cannot think of a major issue to probe with ethtool from userspace like you suggested before. The only issue might be if we have to do some sort of probing and checking if this is supported takes a while (like if we have to do some fw command that takes several to 10-15 seconds each time). For that case we do not want to have to probe every device during boot or the boot/distro people will not be happy. Second that.. One alternative is that the network driver registers to the new module. I would prefer that the new module is loaded already so it can enumerate the /sysfs entries correctly. Although we have not proposed this via the netdev ML yet, however, the current suggestion to only add ethtool extension to support this is gaining traction. As far as latency goes, a simple for_each_netdev loop to probe each netdev's ethtool_ops for these new extensions (like get/set_flash_node) shouldn't incur too much cost for unsupported nics. However, for the case when there are many supported nics in the system, we would then have to decide how to best ha
Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
-Original Message- From: Eddie Wai Date: Wednesday 5 June 2013 7:00 AM To: "shyam_i...@dell.com" Cc: "open-iscsi@googlegroups.com" , Vikas , Lalit Chandivade , Ravi Anand , Poornima Vonti , Manish Rangankar , Adheer Chandravanshi Subject: RE: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support > >On Wed, 2013-05-29 at 14:37 -0700, shyam_i...@dell.com wrote: >> >> > -Original Message- >> > From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] >> > On Behalf Of Mike Christie >> > Sent: Wednesday, May 29, 2013 1:30 PM >> > To: open-iscsi@googlegroups.com >> > Cc: Eddie Wai; vikas.chaudh...@qlogic.com; >>lalit.chandiv...@qlogic.com; >> > ravi.an...@qlogic.com; poornima.vo...@qlogic.com; >> > manish.rangan...@qlogic.com; Adheer Chandravanshi >> > Subject: Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node >>mgmt >> > support >> > >> > On 05/29/2013 12:23 PM, Eddie Wai wrote: >> > > >> > > On Wed, 2013-05-29 at 10:26 -0500, Mike Christie wrote: >> > >> On 05/28/2013 07:35 PM, Eddie Wai wrote: >> > >>> Hello Mike, Vikas, and all, >> > >>> >> > >>> Thanks for the great work in creating the flash node mechanism! >> > >>> >> > >>> To extend the conversation we had to add support for software and >> > >>> other offload solutions that requires iscsid/iscsiadm to create >>the >> > >>> sessions, the following needs to be further discussed: >> > >>> >> > >>> 1. Flash node creation. >> > >>> >> > >>> The current solution relies on the transport driver to initiate >>the >> > >>> flash node sysfs creation upon iscsi_host allocation. This >>presents >> > >>> a fundamental problem for software iSCSI as new iscsi_host >>instance >> > >>> won't get created until there's a session initiation. >> > >>> >> > >>> Per our conversation, I think it makes sense to move the flash >>node >> > >>> initiation code altogether to a separate module like how its done >> > >>> for ibft. The new module shall cycle through each existing iSCSI >> > >>> host and query the corresponding transport to fill the flash node >> > >>> sysfs entries specific to that host. Perhaps via a new transport >>callback >> > or so. >> > >> >> > >> Agree. >> > >> >> > >>> >> > >>> Since there won't be any pre-existing host created for software >> > >>> iSCSI, this needs to be handled differently. Instead, the new >> > >>> module will also need to cycle through each network interfaces >> > >>> present and query for the flash node content separately. >> > >>> >> > >>> To accomplish this, each network interface will need to be made >> > >>> aware of flash nodes and also provide a way for the new module to >> > >>> read out the flash node content. Per our conversation, this can >>be >> > >>> done via an extension of the ethtool utility. For unsupported >> > >>> network drivers, this >> > >> >> > >> I do not remember that discussion. Has it been discussed with the >> > >> netdev people already? >> > > This has only been discussed internally so far, but we believe >>adding >> > > a new ethtool extension for this flash memory access is one logical >> > > way that the netdev community can accept. >> > >> >> > >> Why does the new module need to cycle through each net device? >>Can't >> > >> a net driver that knows it supports this just call into the new >> > >> module to register itself when it is loaded? When it registers it >>can >> > >> create any sysfs/netlink stuff needed so userspace can detect it >>and >> > access it. >> > > That would work too, but our proposal essentially is tailored toward >> > > minimizing any storage specific code in the network drivers. >> > > >> > > Note that our proposal is to add an ethtool extension which will >> > > provide read/write access directly to the flash memory. It will not >> > > do any sysfs creation or parameter qualification. It only provides &
RE: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
On Wed, 2013-05-29 at 14:37 -0700, shyam_i...@dell.com wrote: > > > -Original Message- > > From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] > > On Behalf Of Mike Christie > > Sent: Wednesday, May 29, 2013 1:30 PM > > To: open-iscsi@googlegroups.com > > Cc: Eddie Wai; vikas.chaudh...@qlogic.com; lalit.chandiv...@qlogic.com; > > ravi.an...@qlogic.com; poornima.vo...@qlogic.com; > > manish.rangan...@qlogic.com; Adheer Chandravanshi > > Subject: Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt > > support > > > > On 05/29/2013 12:23 PM, Eddie Wai wrote: > > > > > > On Wed, 2013-05-29 at 10:26 -0500, Mike Christie wrote: > > >> On 05/28/2013 07:35 PM, Eddie Wai wrote: > > >>> Hello Mike, Vikas, and all, > > >>> > > >>> Thanks for the great work in creating the flash node mechanism! > > >>> > > >>> To extend the conversation we had to add support for software and > > >>> other offload solutions that requires iscsid/iscsiadm to create the > > >>> sessions, the following needs to be further discussed: > > >>> > > >>> 1. Flash node creation. > > >>> > > >>> The current solution relies on the transport driver to initiate the > > >>> flash node sysfs creation upon iscsi_host allocation. This presents > > >>> a fundamental problem for software iSCSI as new iscsi_host instance > > >>> won't get created until there's a session initiation. > > >>> > > >>> Per our conversation, I think it makes sense to move the flash node > > >>> initiation code altogether to a separate module like how its done > > >>> for ibft. The new module shall cycle through each existing iSCSI > > >>> host and query the corresponding transport to fill the flash node > > >>> sysfs entries specific to that host. Perhaps via a new transport > > >>> callback > > or so. > > >> > > >> Agree. > > >> > > >>> > > >>> Since there won't be any pre-existing host created for software > > >>> iSCSI, this needs to be handled differently. Instead, the new > > >>> module will also need to cycle through each network interfaces > > >>> present and query for the flash node content separately. > > >>> > > >>> To accomplish this, each network interface will need to be made > > >>> aware of flash nodes and also provide a way for the new module to > > >>> read out the flash node content. Per our conversation, this can be > > >>> done via an extension of the ethtool utility. For unsupported > > >>> network drivers, this > > >> > > >> I do not remember that discussion. Has it been discussed with the > > >> netdev people already? > > > This has only been discussed internally so far, but we believe adding > > > a new ethtool extension for this flash memory access is one logical > > > way that the netdev community can accept. > > >> > > >> Why does the new module need to cycle through each net device? Can't > > >> a net driver that knows it supports this just call into the new > > >> module to register itself when it is loaded? When it registers it can > > >> create any sysfs/netlink stuff needed so userspace can detect it and > > access it. > > > That would work too, but our proposal essentially is tailored toward > > > minimizing any storage specific code in the network drivers. > > > > > > Note that our proposal is to add an ethtool extension which will > > > provide read/write access directly to the flash memory. It will not > > > do any sysfs creation or parameter qualification. It only provides a > > > gateway to the flash memory, that's it. It will be up to the new > > > module to initiate, create, and manage over those sysfs parameters. > > > > Sounds ok to me. > > > > > > > > Perhaps we can add some minor initiation code in the network driver to > > > perhaps 'register' some flag so the new module will only have to cycle > > > through a list of supported network interfaces only. > > > > It is ok. I was just thinking along the lines of either ethtool or iscsi > > mod only. I > > cannot think of a major issue to probe with ethtool from userspace like you > > suggested be
RE: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
> -Original Message- > From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] > On Behalf Of Mike Christie > Sent: Wednesday, May 29, 2013 1:30 PM > To: open-iscsi@googlegroups.com > Cc: Eddie Wai; vikas.chaudh...@qlogic.com; lalit.chandiv...@qlogic.com; > ravi.an...@qlogic.com; poornima.vo...@qlogic.com; > manish.rangan...@qlogic.com; Adheer Chandravanshi > Subject: Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt > support > > On 05/29/2013 12:23 PM, Eddie Wai wrote: > > > > On Wed, 2013-05-29 at 10:26 -0500, Mike Christie wrote: > >> On 05/28/2013 07:35 PM, Eddie Wai wrote: > >>> Hello Mike, Vikas, and all, > >>> > >>> Thanks for the great work in creating the flash node mechanism! > >>> > >>> To extend the conversation we had to add support for software and > >>> other offload solutions that requires iscsid/iscsiadm to create the > >>> sessions, the following needs to be further discussed: > >>> > >>> 1. Flash node creation. > >>> > >>> The current solution relies on the transport driver to initiate the > >>> flash node sysfs creation upon iscsi_host allocation. This presents > >>> a fundamental problem for software iSCSI as new iscsi_host instance > >>> won't get created until there's a session initiation. > >>> > >>> Per our conversation, I think it makes sense to move the flash node > >>> initiation code altogether to a separate module like how its done > >>> for ibft. The new module shall cycle through each existing iSCSI > >>> host and query the corresponding transport to fill the flash node > >>> sysfs entries specific to that host. Perhaps via a new transport callback > or so. > >> > >> Agree. > >> > >>> > >>> Since there won't be any pre-existing host created for software > >>> iSCSI, this needs to be handled differently. Instead, the new > >>> module will also need to cycle through each network interfaces > >>> present and query for the flash node content separately. > >>> > >>> To accomplish this, each network interface will need to be made > >>> aware of flash nodes and also provide a way for the new module to > >>> read out the flash node content. Per our conversation, this can be > >>> done via an extension of the ethtool utility. For unsupported > >>> network drivers, this > >> > >> I do not remember that discussion. Has it been discussed with the > >> netdev people already? > > This has only been discussed internally so far, but we believe adding > > a new ethtool extension for this flash memory access is one logical > > way that the netdev community can accept. > >> > >> Why does the new module need to cycle through each net device? Can't > >> a net driver that knows it supports this just call into the new > >> module to register itself when it is loaded? When it registers it can > >> create any sysfs/netlink stuff needed so userspace can detect it and > access it. > > That would work too, but our proposal essentially is tailored toward > > minimizing any storage specific code in the network drivers. > > > > Note that our proposal is to add an ethtool extension which will > > provide read/write access directly to the flash memory. It will not > > do any sysfs creation or parameter qualification. It only provides a > > gateway to the flash memory, that's it. It will be up to the new > > module to initiate, create, and manage over those sysfs parameters. > > Sounds ok to me. > > > > > Perhaps we can add some minor initiation code in the network driver to > > perhaps 'register' some flag so the new module will only have to cycle > > through a list of supported network interfaces only. > > It is ok. I was just thinking along the lines of either ethtool or iscsi mod > only. I > cannot think of a major issue to probe with ethtool from userspace like you > suggested before. The only issue might be if we have to do some sort of > probing and checking if this is supported takes a while (like if we have to do > some fw command that takes several to 10-15 seconds each time). For that > case we do not want to have to probe every device during boot or the > boot/distro people will not be happy. > Second that.. One alternative is that the network driver registers to the new module. I would prefer that the new module is loaded already so it can enumerate
Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
On 05/29/2013 12:23 PM, Eddie Wai wrote: > > On Wed, 2013-05-29 at 10:26 -0500, Mike Christie wrote: >> On 05/28/2013 07:35 PM, Eddie Wai wrote: >>> Hello Mike, Vikas, and all, >>> >>> Thanks for the great work in creating the flash node mechanism! >>> >>> To extend the conversation we had to add support for software and other >>> offload solutions that requires iscsid/iscsiadm to create the sessions, >>> the following needs to be further discussed: >>> >>> 1. Flash node creation. >>> >>> The current solution relies on the transport driver to initiate the >>> flash node sysfs creation upon iscsi_host allocation. This presents a >>> fundamental problem for software iSCSI as new iscsi_host instance won't >>> get created until there's a session initiation. >>> >>> Per our conversation, I think it makes sense to move the flash node >>> initiation code altogether to a separate module like how its done for >>> ibft. The new module shall cycle through each existing iSCSI host and >>> query the corresponding transport to fill the flash node sysfs entries >>> specific to that host. Perhaps via a new transport callback or so. >> >> Agree. >> >>> >>> Since there won't be any pre-existing host created for software iSCSI, >>> this needs to be handled differently. Instead, the new module will also >>> need to cycle through each network interfaces present and query for the >>> flash node content separately. >>> >>> To accomplish this, each network interface will need to be made aware of >>> flash nodes and also provide a way for the new module to read out the >>> flash node content. Per our conversation, this can be done via an >>> extension of the ethtool utility. For unsupported network drivers, this >> >> I do not remember that discussion. Has it been discussed with the netdev >> people already? > This has only been discussed internally so far, but we believe adding a > new ethtool extension for this flash memory access is one logical way > that the netdev community can accept. >> >> Why does the new module need to cycle through each net device? Can't a >> net driver that knows it supports this just call into the new module to >> register itself when it is loaded? When it registers it can create any >> sysfs/netlink stuff needed so userspace can detect it and access it. > That would work too, but our proposal essentially is tailored toward > minimizing any storage specific code in the network drivers. > > Note that our proposal is to add an ethtool extension which will provide > read/write access directly to the flash memory. It will not do any > sysfs creation or parameter qualification. It only provides a gateway > to the flash memory, that's it. It will be up to the new module to > initiate, create, and manage over those sysfs parameters. Sounds ok to me. > > Perhaps we can add some minor initiation code in the network driver to > perhaps 'register' some flag so the new module will only have to cycle > through a list of supported network interfaces only. It is ok. I was just thinking along the lines of either ethtool or iscsi mod only. I cannot think of a major issue to probe with ethtool from userspace like you suggested before. The only issue might be if we have to do some sort of probing and checking if this is supported takes a while (like if we have to do some fw command that takes several to 10-15 seconds each time). For that case we do not want to have to probe every device during boot or the boot/distro people will not be happy. > > I imagine the sysfs entries created for this will look something like > this: > /sys/bus/iscsi_flashnode/devices/flashnode_sess-tcp:/ attrs> > > /sys/bus/iscsi_flashnode/devices/flashnode_conn-tcp::/ attrs> > > /sys/bus/iscsi_flashnode/devices/flashnode_initiator-tcp:/ attrs> > >> >> I am not sure I got why we need a new module and ethtool extensions. It >> seems you only need one or the other. >> >> >>> call will simply return an unsupported ethtool extension error. For >>> others, it can return a memory pointer to the flash node content. >>> >>> Additionally, the net tools must also provide a way for these net params >>> to be populated to the corresponding network interfaces. This needs >>> further discussion. >>> >>> >>> 2. Initiator iSCSI/network params. >>> >>> The current solution does not provide any means to link initiator >>> parameters to the associated flash nodes. >>> >>> In order to resolve this, new initiator entries will need to be created >>> alongside or inside these flash node sysfs entries. The content and >>> naming will somewhat follow our last conversation of creating >>> corresponding entries inside the iscsi_flashnode sysfs as follows: >>> >>> /sys/bus/iscsi_flashnode/devices/flashnode_initiator-:/< >>> initiator attrs> >>> >>> Offload solutions that doesn't need to use this can ignore these >>> initiator entries. >>> >> >> Sounds ok. >> >>> >>> 3. Connection initiation. >>> >>> The current solution provides 2 ways to init
Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
On Wed, 2013-05-29 at 10:26 -0500, Mike Christie wrote: > On 05/28/2013 07:35 PM, Eddie Wai wrote: > > Hello Mike, Vikas, and all, > > > > Thanks for the great work in creating the flash node mechanism! > > > > To extend the conversation we had to add support for software and other > > offload solutions that requires iscsid/iscsiadm to create the sessions, > > the following needs to be further discussed: > > > > 1. Flash node creation. > > > > The current solution relies on the transport driver to initiate the > > flash node sysfs creation upon iscsi_host allocation. This presents a > > fundamental problem for software iSCSI as new iscsi_host instance won't > > get created until there's a session initiation. > > > > Per our conversation, I think it makes sense to move the flash node > > initiation code altogether to a separate module like how its done for > > ibft. The new module shall cycle through each existing iSCSI host and > > query the corresponding transport to fill the flash node sysfs entries > > specific to that host. Perhaps via a new transport callback or so. > > Agree. > > > > > Since there won't be any pre-existing host created for software iSCSI, > > this needs to be handled differently. Instead, the new module will also > > need to cycle through each network interfaces present and query for the > > flash node content separately. > > > > To accomplish this, each network interface will need to be made aware of > > flash nodes and also provide a way for the new module to read out the > > flash node content. Per our conversation, this can be done via an > > extension of the ethtool utility. For unsupported network drivers, this > > I do not remember that discussion. Has it been discussed with the netdev > people already? This has only been discussed internally so far, but we believe adding a new ethtool extension for this flash memory access is one logical way that the netdev community can accept. > > Why does the new module need to cycle through each net device? Can't a > net driver that knows it supports this just call into the new module to > register itself when it is loaded? When it registers it can create any > sysfs/netlink stuff needed so userspace can detect it and access it. That would work too, but our proposal essentially is tailored toward minimizing any storage specific code in the network drivers. Note that our proposal is to add an ethtool extension which will provide read/write access directly to the flash memory. It will not do any sysfs creation or parameter qualification. It only provides a gateway to the flash memory, that's it. It will be up to the new module to initiate, create, and manage over those sysfs parameters. Perhaps we can add some minor initiation code in the network driver to perhaps 'register' some flag so the new module will only have to cycle through a list of supported network interfaces only. I imagine the sysfs entries created for this will look something like this: /sys/bus/iscsi_flashnode/devices/flashnode_sess-tcp:/ /sys/bus/iscsi_flashnode/devices/flashnode_conn-tcp::/ /sys/bus/iscsi_flashnode/devices/flashnode_initiator-tcp:/ > > I am not sure I got why we need a new module and ethtool extensions. It > seems you only need one or the other. > > > > call will simply return an unsupported ethtool extension error. For > > others, it can return a memory pointer to the flash node content. > > > > Additionally, the net tools must also provide a way for these net params > > to be populated to the corresponding network interfaces. This needs > > further discussion. > > > > > > 2. Initiator iSCSI/network params. > > > > The current solution does not provide any means to link initiator > > parameters to the associated flash nodes. > > > > In order to resolve this, new initiator entries will need to be created > > alongside or inside these flash node sysfs entries. The content and > > naming will somewhat follow our last conversation of creating > > corresponding entries inside the iscsi_flashnode sysfs as follows: > > > > /sys/bus/iscsi_flashnode/devices/flashnode_initiator-:/< > > initiator attrs> > > > > Offload solutions that doesn't need to use this can ignore these > > initiator entries. > > > > Sounds ok. > > > > > 3. Connection initiation. > > > > The current solution provides 2 ways to initiate the connection to these > > flash node targets; initiate from inside the driver, or via the iscsiadm > > flash node login command. > > > > This posts a problem for software iSCSI and other offload solutions as > > they do not conventionally initiate a connection from within the driver. > > > > One way to resolve this is to augment the iscsi tool to loop through > > these entries and create the sessions automatically upon start-up. > > > > We can simply add a transport switch here for offload solutions that > > doesn't want/need this. > > Sounds ok. > > > > > > > Comments welcome! Thanks. > > > > Eddie >
Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
On 05/28/2013 07:35 PM, Eddie Wai wrote: > Hello Mike, Vikas, and all, > > Thanks for the great work in creating the flash node mechanism! > > To extend the conversation we had to add support for software and other > offload solutions that requires iscsid/iscsiadm to create the sessions, > the following needs to be further discussed: > > 1. Flash node creation. > > The current solution relies on the transport driver to initiate the > flash node sysfs creation upon iscsi_host allocation. This presents a > fundamental problem for software iSCSI as new iscsi_host instance won't > get created until there's a session initiation. > > Per our conversation, I think it makes sense to move the flash node > initiation code altogether to a separate module like how its done for > ibft. The new module shall cycle through each existing iSCSI host and > query the corresponding transport to fill the flash node sysfs entries > specific to that host. Perhaps via a new transport callback or so. Agree. > > Since there won't be any pre-existing host created for software iSCSI, > this needs to be handled differently. Instead, the new module will also > need to cycle through each network interfaces present and query for the > flash node content separately. > > To accomplish this, each network interface will need to be made aware of > flash nodes and also provide a way for the new module to read out the > flash node content. Per our conversation, this can be done via an > extension of the ethtool utility. For unsupported network drivers, this I do not remember that discussion. Has it been discussed with the netdev people already? Why does the new module need to cycle through each net device? Can't a net driver that knows it supports this just call into the new module to register itself when it is loaded? When it registers it can create any sysfs/netlink stuff needed so userspace can detect it and access it. I am not sure I got why we need a new module and ethtool extensions. It seems you only need one or the other. > call will simply return an unsupported ethtool extension error. For > others, it can return a memory pointer to the flash node content. > > Additionally, the net tools must also provide a way for these net params > to be populated to the corresponding network interfaces. This needs > further discussion. > > > 2. Initiator iSCSI/network params. > > The current solution does not provide any means to link initiator > parameters to the associated flash nodes. > > In order to resolve this, new initiator entries will need to be created > alongside or inside these flash node sysfs entries. The content and > naming will somewhat follow our last conversation of creating > corresponding entries inside the iscsi_flashnode sysfs as follows: > > /sys/bus/iscsi_flashnode/devices/flashnode_initiator-:/< > initiator attrs> > > Offload solutions that doesn't need to use this can ignore these > initiator entries. > Sounds ok. > > 3. Connection initiation. > > The current solution provides 2 ways to initiate the connection to these > flash node targets; initiate from inside the driver, or via the iscsiadm > flash node login command. > > This posts a problem for software iSCSI and other offload solutions as > they do not conventionally initiate a connection from within the driver. > > One way to resolve this is to augment the iscsi tool to loop through > these entries and create the sessions automatically upon start-up. > > We can simply add a transport switch here for offload solutions that > doesn't want/need this. Sounds ok. > > > Comments welcome! Thanks. > > Eddie > > > On Tue, 2013-02-19 at 07:05 -0500, vikas.chaudh...@qlogic.com wrote: >> From: Adheer Chandravanshi >> >> This patch allows iscsiadm to manage iSCSI target information stored on >> adapter flash on per host basis. >> >> The sysfs entries will look as cited below: >> >> /sys/bus/iscsi_flashnode/devices/flashnode_sess-:/> attrs> >> >> /sys/bus/iscsi_flashnode/devices/flashnode_conn-::/> attrs> >> >> Signed-off-by: Adheer Chandravanshi >> Signed-off-by: Manish Rangankar >> Signed-off-by: Vikas Chaudhary >> --- >> drivers/scsi/scsi_transport_iscsi.c | 998 >> ++- >> include/scsi/iscsi_if.h | 112 >> include/scsi/scsi_transport_iscsi.h | 150 ++ >> 3 files changed, 1259 insertions(+), 1 deletions(-) >> > > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
Hello Mike, Vikas, and all, Thanks for the great work in creating the flash node mechanism! To extend the conversation we had to add support for software and other offload solutions that requires iscsid/iscsiadm to create the sessions, the following needs to be further discussed: 1. Flash node creation. The current solution relies on the transport driver to initiate the flash node sysfs creation upon iscsi_host allocation. This presents a fundamental problem for software iSCSI as new iscsi_host instance won't get created until there's a session initiation. Per our conversation, I think it makes sense to move the flash node initiation code altogether to a separate module like how its done for ibft. The new module shall cycle through each existing iSCSI host and query the corresponding transport to fill the flash node sysfs entries specific to that host. Perhaps via a new transport callback or so. Since there won't be any pre-existing host created for software iSCSI, this needs to be handled differently. Instead, the new module will also need to cycle through each network interfaces present and query for the flash node content separately. To accomplish this, each network interface will need to be made aware of flash nodes and also provide a way for the new module to read out the flash node content. Per our conversation, this can be done via an extension of the ethtool utility. For unsupported network drivers, this call will simply return an unsupported ethtool extension error. For others, it can return a memory pointer to the flash node content. Additionally, the net tools must also provide a way for these net params to be populated to the corresponding network interfaces. This needs further discussion. 2. Initiator iSCSI/network params. The current solution does not provide any means to link initiator parameters to the associated flash nodes. In order to resolve this, new initiator entries will need to be created alongside or inside these flash node sysfs entries. The content and naming will somewhat follow our last conversation of creating corresponding entries inside the iscsi_flashnode sysfs as follows: /sys/bus/iscsi_flashnode/devices/flashnode_initiator-:/< initiator attrs> Offload solutions that doesn't need to use this can ignore these initiator entries. 3. Connection initiation. The current solution provides 2 ways to initiate the connection to these flash node targets; initiate from inside the driver, or via the iscsiadm flash node login command. This posts a problem for software iSCSI and other offload solutions as they do not conventionally initiate a connection from within the driver. One way to resolve this is to augment the iscsi tool to loop through these entries and create the sessions automatically upon start-up. We can simply add a transport switch here for offload solutions that doesn't want/need this. Comments welcome! Thanks. Eddie On Tue, 2013-02-19 at 07:05 -0500, vikas.chaudh...@qlogic.com wrote: > From: Adheer Chandravanshi > > This patch allows iscsiadm to manage iSCSI target information stored on > adapter flash on per host basis. > > The sysfs entries will look as cited below: > > /sys/bus/iscsi_flashnode/devices/flashnode_sess-:/ attrs> > > /sys/bus/iscsi_flashnode/devices/flashnode_conn-::/ attrs> > > Signed-off-by: Adheer Chandravanshi > Signed-off-by: Manish Rangankar > Signed-off-by: Vikas Chaudhary > --- > drivers/scsi/scsi_transport_iscsi.c | 998 > ++- > include/scsi/iscsi_if.h | 112 > include/scsi/scsi_transport_iscsi.h | 150 ++ > 3 files changed, 1259 insertions(+), 1 deletions(-) > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
On 02/19/2013 06:05 AM, vikas.chaudh...@qlogic.com wrote:
> +/* flash node connection attrs show */
> +#define iscsi_flashnode_conn_attr_show(type, name, param)\
> +static ssize_t
> \
> +show_##type##_##name(struct device *dev, struct device_attribute *attr,
> \
> + char *buf) \
> +{\
> + struct iscsi_bus_flash_conn *fnode_conn = iscsi_dev_to_flash_conn(dev);\
> + struct iscsi_bus_flash_session *fnode_sess =\
> + iscsi_flash_conn_to_flash_session(fnode_conn);\
> + struct iscsi_transport *t = fnode_conn->transport; \
> + return t->get_flashnode_param(fnode_sess, param, buf); \
> +}\
For the params we store on the class iscsi_bus_flash_session struct we
should just have the class print the value. Just make that change and
send to the list. But, see other qla4xxx patch comment.
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
