-----Original Message----- From: Eddie Wai <w...@broadcom.com> Date: Wednesday 5 June 2013 7:00 AM To: "shyam_i...@dell.com" <shyam_i...@dell.com> Cc: "open-iscsi@googlegroups.com" <open-iscsi@googlegroups.com>, Vikas <vikas.chaudh...@qlogic.com>, Lalit Chandivade <lalit.chandiv...@qlogic.com>, Ravi Anand <ravi.an...@qlogic.com>, Poornima Vonti <poornima.vo...@qlogic.com>, Manish Rangankar <manish.rangan...@qlogic.com>, Adheer Chandravanshi <adheer.chandravan...@qlogic.com> 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 handle the delay. We might have to rely on >defer tactics or impose a hard limit on the number of flash targets to >support on a system. This should be easy to govern via the bios. > >How about for HBAs? We probably want to employ the same top-down >approach and have the new module cycle through each created host and >pull for the flash node targets. The alternative is to call into the >new module to create those flash node sysfs entries upon iscsi_host >allocation. What would be the best way to do this? I think iSCSI HBA Driver call into the new module to create flash node sysfs entries upon iscsi_host allocation is better way to do it. -- 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.
