Thanks, What are the possible values of "ISCSI_NET_CFG_BOOTPROTO"?
Karen -----Original Message----- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Anil Veerabhadrappa Sent: Thursday, February 05, 2009 3:23 PM To: open-iscsi@googlegroups.com Cc: micha...@cs.wisc.edu; mchri...@redhat.com; Michael Chan; Benjamin Li Subject: RE: [RFC] : network configuration for iscsi hba On Thu, 2009-02-05 at 14:33 -0800, Karen Xie wrote: > -----Original Message----- > From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] > On Behalf Of Anil Veerabhadrappa > Sent: Thursday, February 05, 2009 11:23 AM > To: open-iscsi@googlegroups.com; micha...@cs.wisc.edu > Cc: mchri...@redhat.com; mc...@broadcom.com; be...@broadcom.com; > ani...@broadcom.com > Subject: [RFC] : network configuration for iscsi hba > > > Hi, > > We'd like to propose a general scheme for configuring network > parameters (IP address/mask/DHCP, etc) for iSCSI NICs that use a private > IP address. The current scheme of using sysfs is not very good because > bootproto, IP address, netmask, VLAN ID, etc all need to be set > together. Having separate sysfs entries and updating them separately and > independently will not work. Putting everything in a netlink message > seems to be a better solution. After weighing different solutions, we > feel expanding existing netlink family, NETLINK_ISCSI between iscsid and > scsi_transport_iscsi is a flexible solution which allows information > flow to be initiated from either side. Also this solution is flexible > and elegantly handles network devices with multiple IP addresses. > > The objective of this proposal is to make this interface common for > all iscsi offload solutions supported by open-iscsi. We would like to > hear comments and suggestions from other iscsi offload vendors in > defining this interface. > > Regards, > Anil Veerabhadrappa > > > Proposal to add netlink message type: > ------------------------------------- > 3 new netlink message types are required to support network config > message exchange between user and kernel components, > 1. ISCSI_UEVENT_SET_NET_CONFIG - push iface info to driver to > configure > an iscsi network interface > 2. ISCSI_UEVENT_GET_NET_CONFIG - get MAC address list, etc' > 3. ISCSI_KEVENT_NET_CONFIG - propagate attribute changes > from > adapter to iscsid (e.g. advertise newly obtained dhcp address) > > iscsid will use this netlink messages to pass network configuration > between user mode application and the driver. Once this message is > received by scsi_transport_iscsi module it will call driver's newly > added callback handlers in the iscsi_transport structure(net_config & > get_net_config) and also broadcast netlink message back to any hardware > vendor's user level daemons > > > ISCSI_XEVENT_NET_CONFIG message payload format: > ----------------------------------------------- > Payload consists of one or more config parameters defined in TLV > (Type - Length - Value) format. > > struct net_cfg_tlv { > uint32_t type; > uint32_t length; > uint8_t value[0]; > }; > > > Message types: > -------------- > This interface is envisioned to support standard network parameters > such as netdev name, MAC address, IPv4/IPv6 address, VLAN, boot protocol > (static or dhcp), etc'. Please refer to 'net_cfg_e' in proposed header > file changes below. > > > Advantages: > ----------- > This approach is much cleaner and delinks network configuration > parameters currently bound to host attributes. Old scheme actually > breaks the layering scheme as seen below, > > SCSI (net config parametes currently resides here) > | > iSCSI > | > TCP/IP > > This new approach is a deviation from current host attributes > approach and places emphasis in iface components of iscsid and the LLD. > > > Changes to iscsi transport headers: > ----------------------------------- > > diff --git a/include/iscsi_if.h b/include/iscsi_if.h > index afa86e8..76eea8c 100644 > --- a/include/iscsi_if.h > +++ b/include/iscsi_if.h > @@ -51,6 +51,8 @@ enum iscsi_uevent_e { > ISCSI_UEVENT_SET_HOST_PARAM = UEVENT_BASE + 16, > ISCSI_UEVENT_UNBIND_SESSION = UEVENT_BASE + 17, > ISCSI_UEVENT_CREATE_BOUND_SESSION = UEVENT_BASE + 18, > + ISCSI_UEVENT_SET_NET_CONFIG = UEVENT_BASE + 19, > + ISCSI_UEVENT_GET_NET_CONFIG = UEVENT_BASE + 20, > > /* up events */ > ISCSI_KEVENT_RECV_PDU = KEVENT_BASE + 1, > @@ -59,6 +61,7 @@ enum iscsi_uevent_e { > ISCSI_KEVENT_DESTROY_SESSION = KEVENT_BASE + 4, > ISCSI_KEVENT_UNBIND_SESSION = KEVENT_BASE + 5, > ISCSI_KEVENT_CREATE_SESSION = KEVENT_BASE + 6, > + ISCSI_KEVENT_NET_CONFIG = KEVENT_BASE + 7, > }; > > enum iscsi_tgt_dscvr { > @@ -317,6 +320,42 @@ enum iscsi_host_param { > #define ISCSI_HOST_NETDEV_NAME (1ULL << > ISCSI_HOST_PARAM_NETDEV_NAME) > #define ISCSI_HOST_IPADDRESS (1ULL << > ISCSI_HOST_PARAM_IPADDRESS) > > +/* iscsi network stack parameters */ > +enum iscsi_net_cfg_e { > + ISCSI_NET_CFG_UNKNOWN 0x00, > + > + ISCSI_NET_CFG_NETDEV_NAME ISCSI_NET_CFG_UNKNOWN + > 1, > + ISCSI_NET_CFG_MAC_ADDR ISCSI_NET_CFG_UNKNOWN + > 2, > + ISCSI_NET_CFG_IPV4_ADDR ISCSI_NET_CFG_UNKNOWN + > 3, > + ISCSI_NET_CFG_IPV6_ADDR ISCSI_NET_CFG_UNKNOWN + > 4, > + ISCSI_NET_CFG_IPV4_NETMASK ISCSI_NET_CFG_UNKNOWN + > 5, > + ISCSI_NET_CFG_IPV6_NETMASK ISCSI_NET_CFG_UNKNOWN + > 6, > + ISCSI_NET_CFG_IPV4_GATEWAY ISCSI_NET_CFG_UNKNOWN + > 7, > + ISCSI_NET_CFG_IPV6_GATEWAY ISCSI_NET_CFG_UNKNOWN + > 8, > + ISCSI_NET_CFG_BOOTPROTO ISCSI_NET_CFG_UNKNOWN + > 9, > + ISCSI_NET_CFG_IPV6_AUTO_CFG ISCSI_NET_CFG_UNKNOWN + > 10, > > [Karen] What does ISCSI_NET_CFG_IPV6_AUTO_CFG mean? > configure IPv6 stateless and stateful address autoconfiguration > + ISCSI_NET_CFG_MTU ISCSI_NET_CFG_UNKNOWN + > 11, > + ISCSI_NET_CFG_VLAN ISCSI_NET_CFG_UNKNOWN + > 12, > +}; > + > > [Karen] how about adding DHCP server settings too? > You are welcome to add necessary parameters as required by any solution. Can you provide more details on parameters you have in mind? > +enum net_cfg_param { > + /* MAC address list for all devices managed by the transports, > + * bnx2i/cxgb3, qla4xxx */ > + ISCSI_NET_MAC_ADDR_LIST, > + /* Given a MAC address driver will return device attributes such > + * as scsi_host no, netdev name, etc' */ > + ISCSI_NET_DEV_INFO, > + /* give a MAC address, return IP address info for network > interfaces > + * configured */ > + ISCSI_NET_MACS_IP_INFO, > + /* return IP address info of all network interfaces configured > for > + * the given netdev name */ > + ISCSI_NET_NETDEV_IP_INFO, > + /* return IP address info of all network interfaces configured > for > + * the given scsi host number */ > + ISCSI_NET_HOSTNO_IP_INFO, > > [Karen] I assume ISCSI_NET_XXX_IP_INFOs are for the iSCSI IP addresses > only? > correct, it deals with iscsi interface only and has nothing to do with host interface. > +}; > + > > #define iscsi_ptr(_handle) ((void*)(unsigned long)_handle) > #define iscsi_handle(_ptr) ((uint64_t)(unsigned long)_ptr) > > diff --git a/kernel/scsi_transport_iscsi.h > b/kernel/scsi_transport_iscsi.h > index b65c96a..37ca2ac 100644 > --- a/kernel/scsi_transport_iscsi.h > +++ b/kernel/scsi_transport_iscsi.h > @@ -124,6 +124,8 @@ struct iscsi_transport { > void (*ep_disconnect) (struct iscsi_endpoint *ep); > int (*tgt_dscvr) (struct Scsi_Host *shost, enum iscsi_tgt_dscvr > type, > uint32_t enable, struct sockaddr *dst_addr); > + int (*set_net_config)(void *buf, int buflen); > + int (*get_net_config)(enum net_if_param param, void *buf); > }; > > /* > > [Karen]So how the user going to manage all these > information/configuration, I assume via open-iscsi's ifaces/ files? > That's correct. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
