>-----Original Message-----
>From: Mike Christie [mailto:[email protected]]
>Sent: Sunday, March 13, 2011 6:05 PM
>To: [email protected]
>Cc: Vikas Chaudhary; Lalit Chandivade; Harish Zunjarrao; Manish Rangankar;
>Ravi Anand
>Subject: Re: [PATCH] [RFC] Add netconfig support in iscsiadm and iscsid
>
>I think overall this is ok. Thank you for working on this.
>
>
>Some comments below.
>
>On 02/25/2011 04:56 AM, Vikas Chaudhary wrote:
>> struct iscsi_net_param {
>> uint32_t param_type; /* enum iscsi_net_param */
>> uint32_t iface_type; /* IPv4 or IPv6 */
>> uint32_t iface_num; /* iface number, 0 - n */
>> uint32_t length; /* Actual length of the param */
>> uint32_t offset; /* For param with length> 256 */
>
>I did not understand the offset value.
If length of param is greater than 256, then param will be split into two
params with same type but different offset.
The value is split into two param structs. First param will have offset value
zero and second param will have offset value as 256.
>
>> uint8_t value[256]; /* max is 223 iscsi name */ }
>__attribute__((packed));
>
>I think you can just dynamically allocate the value.
>
>We did not do this for other events/params, because they are needed for
>the reconnection. For the case where we could not allocate memory and
>are trying to reconnect a sessions that the vm is trying to write pages
>out to, then having the set value size made it simple to preallocate
>param/event structs.
>
>For setup there is not need to preallocate.
>
We use pre-allocated memory as we need to send all network parameters to the
driver as single data blob.
We can modify code to use dynamically allocated memory as suggested but it will
add complexity in the code.
If we use dynamic memory allocation, we need to keep track of the location
where each parameter and its corresponding data starts.
The number of network parameters to be send can change each time based on how
user configures iface. Therefore it becomes complex to identify
how much memory needs to be allocated each time.
For example:
Suppose we have following two iface files:
IFACE A:
# BEGIN RECORD 2.0-872
iface.iscsi_ifacename = qla4xxx.00:0e:1e:04:93:92
iface.ipaddress = 192.168.1.71
iface.subnet_mask = 255.255.255.0
iface.gateway = 192.168.1.1
iface.hwaddress = 00:0e:1e:04:93:92
iface.transport_name = qla4xxx
iface.state = enable
# END RECORD
IFACE B:
# BEGIN RECORD 2.0-872
iface.iscsi_ifacename = qla4xxx.00:0e:1e:04:93:92
iface.ipaddress = 1234::5678
iface.hwaddress = 00:0e:1e:04:93:92
iface.transport_name = qla4xxx
iface.state = enable
# END RECORD
In IFACE A, we require 4 bytes for ipv4 address whereas in IFACE B, we require
16 bytes for ipv16 address value.
As the number of parameters go on increasing, we need to find out memory
requirement for them as well.
As we need to send complete netconfig data as a single blob, first we need to
find out number of valid parameters
in the iface which are required to be sent to the driver. Depending on the
parameter, we need to find out memory requirement of each parameter.
This requires iface files to be parsed twice, one to find out memory
requirement and other to fill up the data in the allocated memory.
This additional processing is required for dynamic memory allocation.
Currently we assume a fixed amount of memory which can accommodate max params
defined as 20 per interface * 5 interface per host.
This allows traversing the iface record once and fill up to the max supported
params per interface.
Please let us know your thoughts about should we continue using pre-allocated
memory or dynamically allocated memory.
>
>> } __attribute__((packed));
>>
>> 2.1.3 New parameters in iface
>> Added following params:-
>>
>> typedef struct iface_rec {
>> struct list_head list;
>> /* iscsi iface record name */
>> char name[ISCSI_MAX_IFACE_LEN];
>> + char iface_num[ISCSI_MAX_STR_LEN];
>
>
>What is the iface_num? Is that a unique id? If so what is
>allocating/managing that iface number id space or what is it based on
>then? Is the id/num also global or does each host have its own id space?
>
The adapter port can have multiple interfaces. For example qla4xxx adapter
supports 1 IPv4 and 2 IPv6 addresses. The iface_num will indicate which iface
to use.
By default if user does not specify the iface_num then its value is 0
indicating the first interface. For IPv6 if user wants to configure both IPv6
addresses then user must specify the iface_num = 0 (first IPv6 interface) and
iface_num = 1 (second IPv6 interface) while configuring the ifaces. Similarly
if an adapter supports multiple IPv4 address then user must specify iface_num =
0 for first IPv4 interface and iface_num = 1 for next and so on. The iface_num
space is separate for IPv4 and IPv6.
Based on the iface_num driver also decides for which interface these parameter
values are.
>If it is just a integer then why the string definition?
>
It should be integer. Will change it to type integer.
>> /* network layer iface name (eth0) */
>> char netdev[IFNAMSIZ];
>> char ipaddress[NI_MAXHOST];
>> + char subnet_mask[NI_MAXHOST];
>> + char gateway[NI_MAXHOST];
>> + char bootproto[ISCSI_MAX_STR_LEN];
>> + char ipv6_linklocal[NI_MAXHOST];
>> + char ipv6_router[NI_MAXHOST];
>> + char autocfg[NI_MAXHOST];
>> + char vlan[ISCSI_MAX_STR_LEN];
>> + char state[ISCSI_MAX_STR_LEN]; /* 0 = disable,
>> + * 1 = enable
>*/
>
>Is this really just meant to be 0 or 1 or was it going to be a string
>and have more values?
Its string, user can specify "enable" / "disable" , we will change the comment.
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.
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
