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-<host_no>:<flashnode_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, vikas.chaudh...@qlogic.com wrote: >> From: Adheer Chandravanshi <adheer.chandravan...@qlogic.com> >> >> 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>:<flashnode_id>:<conn_id>/<conn >> attrs> >> >> Signed-off-by: Adheer Chandravanshi <adheer.chandravan...@qlogic.com> >> Signed-off-by: Manish Rangankar <manish.rangan...@qlogic.com> >> Signed-off-by: Vikas Chaudhary <vikas.chaudh...@qlogic.com> >> --- >> 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.
