>-----Original Message----- >From: Mike Christie [mailto:michaelc@xxxxxxxxxxx] >Sent: Thursday, May 05, 2011 10:34 AM >To: Vikas Chaudhary >Cc: Eddie Wai; open-iscsi@xxxxxxxxxxxxxxxx; James.Bottomley@xxxxxxx; linux- >scsi@xxxxxxxxxxxxxxx; Lalit Chandivade; Ravi Anand; Harish Zunjarrao >Subject: Re: [RFC-V2 PATCH] iscsiadm: Add netconfig support in iscsiadm and >iscsid > >On 05/04/2011 07:42 AM, Vikas Chaudhary wrote: >>> -----Original Message----- >>> From: Eddie Wai [mailto:eddie.wai@xxxxxxxxxxxx] >>> Sent: Monday, May 02, 2011 5:19 AM >>> To: open-iscsi@xxxxxxxxxxxxxxxx >>> Cc: James.Bottomley@xxxxxxx; michaelc@xxxxxxxxxxx; linux- >>> scsi@xxxxxxxxxxxxxxx; Vikas Chaudhary; Lalit Chandivade; Ravi Anand; >Harish >>> Zunjarrao >>> Subject: Re: [RFC-V2 PATCH] iscsiadm: Add netconfig support in iscsiadm >and >>> iscsid >>> >>> Hello Vikas, >>> >>> The patch looks good but I have a few questions/comments in relation to >>> the general scheme of setting these iface net parameters: >>> >>> 1. As far as I understand, each iface file of the same hw must now >>> incorporate an unique iface_num which will be used to key off the >>> corresponding iface settings in the transport. Iscsiadm will send a >>> UEVENT along with the net contents to the transport only when it is >>> explicitly asked to apply the update via the command line. Perhaps it >>> would be beneficial to have the initiator apply the changes implicitly >>> like how it is currently making the call to the >>> iscsi_host_set_net_params just prior to all the ep_connect calls. This >>> will allow the current iface parameters to be set for the corresponding >>> ep_connect call. >> >> Yes, it makes sense. We can add flag similar to "t->template- >>set_host_ip" >> and allow implicit network configuration for each ep_connect. >> >> Mike C, do you see any issues? > >No. > >And for the iface_num, I was also think working on just making the iface >number more of a string or something. Userspace could then just pass >down any value it wanted, so drivers like bnx2i/cxgbi/be2iscsi would not >have to worry about the value. It could just be the userpace iface name >since that is unique, and it would allow us to match the iface to the >kernel object. Still working on it though. I have not completely >convince myself. Do you guys have any issues with it or any comments? I don't see issue if we make iface number as string, we are ok as long as we are getting correct iface number in qla4xxx. This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
