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


Reply via email to