> -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Mike Christie > Sent: Wednesday, May 29, 2013 1:30 PM > To: [email protected] > Cc: Eddie Wai; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; 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. > > > > > I imagine the sysfs entries created for this will look something like > > this: > > /sys/bus/iscsi_flashnode/devices/flashnode_sess- > tcp:<flashnode_id>/<session attrs> > > /sys/bus/iscsi_flashnode/devices/flashnode_conn- > tcp:<flashnode_id>:<conn_id>/<conn attrs> > > > > /sys/bus/iscsi_flashnode/devices/flashnode_initiator-tcp:<flashnode_id > > >/<initiator 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-<host_no>:<flas > >>> hnode_id>/< > >>> 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, [email protected] wrote: > >>>> From: Adheer Chandravanshi <[email protected]> > >>>> > >>>> 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- > <host_no>:<flashnode_id>/<session attrs> > >>>> > >>>> /sys/bus/iscsi_flashnode/devices/flashnode_conn- > <host_no>:<flashnod > >>>> e_id>:<conn_id>/<conn attrs> > >>>> > >>>> Signed-off-by: Adheer Chandravanshi > >>>> <[email protected]> > >>>> Signed-off-by: Manish Rangankar <[email protected]> > >>>> Signed-off-by: Vikas Chaudhary <[email protected]> > >>>> --- > >>>> 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/open-iscsi?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
