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 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, 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>:<flashnod
> > >>>> e_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.
> > 
> 
> 


-- 
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.


Reply via email to