Re: EqualLogic load-balancing logout/re-login behavior (asynchrounous event logout)
Konrad Rzeszutek wrote:
In the 2.0-865 version when we received a ISCSI_ASYNC_MSG_REQUEST_LOGOUT we
would
logout, and then retry logging back in:
- 28Jul 28 20:15:40 iscsid: Target requests logout within 3 seconds for
connection^M
- 28Jul 28 20:15:45 iscsid: connection5:0 is operational after recovery (2
attempts)^M
And we would have a short hiccup (5 seconds) of the connection being gone.
This as my understanding was a mechanism for the EqualLogic box to move
(re-establishing
allegiance) a session to a different port, hence allowing a load-balancing
mechanism.
In 2.0-869, the git commit 052d014485d2ce5bb7fa8dd0df875dafd1db77df changed
this
behavior so that we now actually logout and delete the session. No more
retries.
Do you mean the session is destoryed as in the kernel parts are
cleaned/freed up and the iscsid parts are freed? There was a bug in 869
where the session would get destoryed on some errors it did not in 868,
but for 870.2 this is fixed (well we just almost never destroy the session).
2.0-865:
static int iscsi_xmit_mtask(struct iscsi_conn *conn)
{
struct iscsi_hdr *hdr = conn-mtask-hdr;
int rc, was_logout = 0;
spin_unlock_bh(conn-session-lock);
if ((hdr-opcode ISCSI_OPCODE_MASK) == ISCSI_OP_LOGOUT) {
conn-session-state = ISCSI_STATE_IN_RECOVERY;
iscsi_block_session(session_to_cls(conn-session));
...
2.0-869:
static int iscsi_xmit_mtask(struct iscsi_conn *conn)
{
struct iscsi_hdr *hdr = conn-mtask-hdr;
int rc;
if ((hdr-opcode ISCSI_OPCODE_MASK) == ISCSI_OP_LOGOUT)
conn-session-state = ISCSI_STATE_LOGGING_OUT;
spin_unlock_bh(conn-session-lock);
.. and..
if (conn-session-state == ISCSI_STATE_LOGGING_OUT) {
iscsi_free_mgmt_task(conn, conn-mtask);
conn-mtask = NULL;
continue;
}
This comes down to 2.0-869 terminating the session without trying to re-login.
What version of 869 are you using? We fixed a problem like this in the
868 test releases for RHEL and it is in upstream (I do not remember the
commit).
I do not think the code you quoted was the problem though, so maybe it
is a different issues (I tried the current code and it worked for me in
870.2). The logout would get sent, then when we clean up the session by
calling stop conn, we should set the session-state to start accepting
commands again:
iscsi_start_session_recovery():
if (flag == STOP_CONN_TERM)
session-state = ISCSI_STATE_TERMINATE;
else if (conn-stop_stage != STOP_CONN_RECOVER)
session-state = ISCSI_STATE_IN_RECOVERY;
So when we go to transmit the login mtask the session-state should not
be logging out anymore.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: EqualLogic load-balancing logout/re-login behavior (asynchrounous event logout)
Mike Christie wrote: Konrad Rzeszutek wrote: In the 2.0-865 version when we received a ISCSI_ASYNC_MSG_REQUEST_LOGOUT we would logout, and then retry logging back in: - 28Jul 28 20:15:40 iscsid: Target requests logout within 3 seconds for connection^M - 28Jul 28 20:15:45 iscsid: connection5:0 is operational after recovery (2 attempts)^M And we would have a short hiccup (5 seconds) of the connection being gone. This as my understanding was a mechanism for the EqualLogic box to move (re-establishing allegiance) a session to a different port, hence allowing a load-balancing mechanism. In 2.0-869, the git commit 052d014485d2ce5bb7fa8dd0df875dafd1db77df changed this behavior so that we now actually logout and delete the session. No more retries. Do you mean the session is destoryed as in the kernel parts are cleaned/freed up and the iscsid parts are freed? There was a bug in 869 where the session would get destoryed on some errors it did not in 868, I meant 865. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[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,
+ ISCSI_NET_CFG_MTU
Re: [PATCH 2.6.29 1/1] cxgb3i - more transmit work-request checks
Karen Xie wrote: [PATCH 2.6.29 1/1] cxgb3i - more transmit work-request checks From: Karen Xie k...@chelsio.com - added more checkings for transmit work-request. - reserve one work-request for credit return. - stop queueing up the outgoing pdus if transmit window is full. - split the skb cb into tx and rx portion What kernel was this made against? I think the patch might include some changes that already went upstream. You might want to rebase the patch against scsi-rc-fixes. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RE: [PATCH 2.6.29 1/1] cxgb3i - more transmit work-request checks
Thanks, Mike, I will re-submit the patch against scsi-rc-fixes. This one was based on scsi-misc-2.6/linux-2.6-iscsi. Karen -Original Message- From: Mike Christie [mailto:micha...@cs.wisc.edu] Sent: Thursday, February 05, 2009 1:43 PM To: Karen Xie Cc: open-iscsi@googlegroups.com; linux-s...@vger.kernel.org; james.bottom...@hansenpartnership.com Subject: Re: [PATCH 2.6.29 1/1] cxgb3i - more transmit work-request checks Karen Xie wrote: [PATCH 2.6.29 1/1] cxgb3i - more transmit work-request checks From: Karen Xie k...@chelsio.com - added more checkings for transmit work-request. - reserve one work-request for credit return. - stop queueing up the outgoing pdus if transmit window is full. - split the skb cb into tx and rx portion What kernel was this made against? I think the patch might include some changes that already went upstream. You might want to rebase the patch against scsi-rc-fixes. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
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
RE: [RFC] : network configuration for iscsi hba
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
RE: [RFC] : network configuration for iscsi hba
On Thu, 2009-02-05 at 16:00 -0800, Karen Xie wrote:
Thanks,
What are the possible values of ISCSI_NET_CFG_BOOTPROTO?
static and dhcp
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 {
@@
RE: [RFC] : network configuration for iscsi hba
If it is dhcp, does the dhcp server settings need to be provided? Or it
is going to be handled outside of iscsi?
Also a question about the set_net_config, suppose a list of parameters
are send down, if one or more values are not supported, does the
operation marked as fail and the user has re-do the iface file (to edit
out the unsupported values)?
Thanks,
Karen
-Original Message-
From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com]
On Behalf Of Anil Veerabhadrappa
Sent: Thursday, February 05, 2009 4:21 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 16:00 -0800, Karen Xie wrote:
Thanks,
What are the possible values of ISCSI_NET_CFG_BOOTPROTO?
static and dhcp
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 {
Where is the open-iscsi wiki site?
To open-iscsi@googlegroups.com, the wiki site http://www.open-iscsi.org/cgi-bin/wiki.pl/Roadmap stated in http://www.open-iscsi.org/docs/README seems not work, it reported an error, Could not create /home/admin/mainwebsite_cgi/open-iscsi: No such file or directory Other wiki pages not work, too, http://www.open-iscsi.org/cgi-bin/wiki.pl/Performance-setup So where is the real open-iscsi wiki site? Thanks, -- Cheng Renquan, Shenzhen, China Johnny Carson - I was so naive as a kid I used to sneak behind the barn and do nothing. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RE: [RFC] : network configuration for iscsi hba
For dhcp, I am just thinking of the cases where one physical NIC have multiple IP addresses, maybe one is for iscsi only, one for RDMA, or another for admin/control traffic. They can operate in different subnet and managed by different DHCP servers. Maybe this is not typical setup? For the set_config, say a NIC does not support IPv6 but received a request to set it. So how should the driver treat any setting it does not support? Ignore or return an error? -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Anil Veerabhadrappa Sent: Thursday, February 05, 2009 5:01 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 16:36 -0800, Karen Xie wrote: If it is dhcp, does the dhcp server settings need to be provided? Or it is going to be handled outside of iscsi? dhcp setting should be zero-conf right? It works based on initial broadcast request, DHCPDISCOVER and subsequent unicast exchange between dhcp client and the server. Are you referring to choosing the preferred dhcp server if more than one is present in the network? Also a question about the set_net_config, suppose a list of parameters are send down, if one or more values are not supported, does the operation marked as fail and the user has re-do the iface file (to edit out the unsupported values)? Please provide specific examples for discussion. Any device specific limitation will be handled by the corresponding driver, our objective here is to define a generic interface that works for cxgb3i/qla4xxx/bnx2i/... Thanks, Karen -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Anil Veerabhadrappa Sent: Thursday, February 05, 2009 4:21 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 16:00 -0800, Karen Xie wrote: Thanks, What are the possible values of ISCSI_NET_CFG_BOOTPROTO? static and dhcp 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
RE: [RFC] : network configuration for iscsi hba
On Thu, 2009-02-05 at 17:34 -0800, Karen Xie wrote: For dhcp, I am just thinking of the cases where one physical NIC have multiple IP addresses, maybe one is for iscsi only, one for RDMA, or another for admin/control traffic. They can operate in different subnet RDMA shares ip/mac address with host stack, right? Even in the example provided above the device should support 3 at least separate MAC addresses, so by specifying multiple iface definitions user should be able to get this configuration working. and managed by different DHCP servers. Maybe this is not typical setup? For the set_config, say a NIC does not support IPv6 but received a request to set it. So how should the driver treat any setting it does not support? Ignore or return an error? This should be considered as user error. Users are expected to create iface definitions based on guidelines (supported parameter list) outlined in driver's README file. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Anil Veerabhadrappa Sent: Thursday, February 05, 2009 5:01 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 16:36 -0800, Karen Xie wrote: If it is dhcp, does the dhcp server settings need to be provided? Or it is going to be handled outside of iscsi? dhcp setting should be zero-conf right? It works based on initial broadcast request, DHCPDISCOVER and subsequent unicast exchange between dhcp client and the server. Are you referring to choosing the preferred dhcp server if more than one is present in the network? Also a question about the set_net_config, suppose a list of parameters are send down, if one or more values are not supported, does the operation marked as fail and the user has re-do the iface file (to edit out the unsupported values)? Please provide specific examples for discussion. Any device specific limitation will be handled by the corresponding driver, our objective here is to define a generic interface that works for cxgb3i/qla4xxx/bnx2i/... Thanks, Karen -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Anil Veerabhadrappa Sent: Thursday, February 05, 2009 4:21 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 16:00 -0800, Karen Xie wrote: Thanks, What are the possible values of ISCSI_NET_CFG_BOOTPROTO? static and dhcp 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
RE: [RFC] : network configuration for iscsi hba
Okay, I think cxgb3i driver can work with the proposed mechanism. Thanks, Karen -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Anil Veerabhadrappa Sent: Thursday, February 05, 2009 6:29 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 17:34 -0800, Karen Xie wrote: For dhcp, I am just thinking of the cases where one physical NIC have multiple IP addresses, maybe one is for iscsi only, one for RDMA, or another for admin/control traffic. They can operate in different subnet RDMA shares ip/mac address with host stack, right? Even in the example provided above the device should support 3 at least separate MAC addresses, so by specifying multiple iface definitions user should be able to get this configuration working. and managed by different DHCP servers. Maybe this is not typical setup? For the set_config, say a NIC does not support IPv6 but received a request to set it. So how should the driver treat any setting it does not support? Ignore or return an error? This should be considered as user error. Users are expected to create iface definitions based on guidelines (supported parameter list) outlined in driver's README file. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Anil Veerabhadrappa Sent: Thursday, February 05, 2009 5:01 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 16:36 -0800, Karen Xie wrote: If it is dhcp, does the dhcp server settings need to be provided? Or it is going to be handled outside of iscsi? dhcp setting should be zero-conf right? It works based on initial broadcast request, DHCPDISCOVER and subsequent unicast exchange between dhcp client and the server. Are you referring to choosing the preferred dhcp server if more than one is present in the network? Also a question about the set_net_config, suppose a list of parameters are send down, if one or more values are not supported, does the operation marked as fail and the user has re-do the iface file (to edit out the unsupported values)? Please provide specific examples for discussion. Any device specific limitation will be handled by the corresponding driver, our objective here is to define a generic interface that works for cxgb3i/qla4xxx/bnx2i/... Thanks, Karen -Original Message- From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] On Behalf Of Anil Veerabhadrappa Sent: Thursday, February 05, 2009 4:21 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 16:00 -0800, Karen Xie wrote: Thanks, What are the possible values of ISCSI_NET_CFG_BOOTPROTO? static and dhcp 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
Re: Mapping Target Name with Device
On 5 Feb 2009 at 16:00, Praveen P wrote: Hello all, Before I had posted one trouble related to open-iscsi which was sorted with the help of Ross and Lars. I could complete my perl project related to ietadm and open-iscsi . All the information regarding the targets obtained are displayed in a web page. Now my client need to display the size of each targets obtained also. Using the command fdisk -l i can see all the devices available and i have the all the available target names also. How can i map the each target name with the corresponding device ? Hi, I just discovered lsscsi --transport on my SLES10 SP1 system: The /usr/bin/lsscsi comes from package scsi. It will display things like this: # lsscsi --transport [0:0:0:0]disksas:0x5000c5920c31 - [0:0:1:0]disksas:0x50e01240f9e2 - _tport: no sas_address, wd=/sys/class/sas_device/host0 [0:1:2:0]disk/dev/sda [1:0:0:0]cd/dvd /dev/sr0 [2:0:0:0]disk/dev/sdb [135:0:0:111]diskiqn.1986- 03.com.hp:fcgw.mpx100:rkdvmis2.0.50001fe1500c1f20.50001fe1500c1f2c,t,0x0 /dev/sdd Reminds me of: When will the system run out of SCSI host adapters? when playing with iSCSI, those numbers increase quickly, and I'm afraid that Linux doesn't recycle them; does it? Regards, Ulrich --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
