RE: Setting firmware/offload engine parameter Large_Frames on QLogic HBAs
Not via the iscsiadm -m fw command, that mode is currently only used to fetch ibft/discovery information from fw and proceed to login if requested. -Anish -Original Message- From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On Behalf Of Frank Fegert Sent: Wednesday, August 5, 2015 1:33 PM To: open-iscsi@googlegroups.com Subject: Setting firmware/offload engine parameter Large_Frames on QLogic HBAs Hello all, the short version of my question: Is it possible to set firmware/offload engine parameters like e.g. Large_Frames on QLogic HBAs via the iscsiadm -m fw [...] command? The slightly longer version of my question ;-) I'm having some difficulties trying to configure some HBA settings - namely the IP address, subnet mask, iSCSI alias, iSCSI Large_Frames and possibly other parameters too - from within the server OS using the qaucli utility. The system parameters are: - HBAs: QME/QMD8262, Dell OEM, FW Version: 4.18.04 - QConvergeConsole CLI qaucli: Version 1.1.3 (Build 49) - OS: - Debian 7 - open-iscsi-2.0.873-3 (also tried a newer version from GIT) - Kernel 3.16.7 - Driver qla4xxx v5.04.00-k6 I try to set e.g. the Large_Frames parameter in the iSCSI offload engine of a HBA, which is already configured like shown below in the example output titled Before qaucli, with the command: /opt/QLogic_Corporation/QConvergeConsoleCLI/qaucli -iscsi -n 0 LRGFRM on After this, the Large_Frames parameter ends up being set correctly, but in the process, the IP address, subnet mask, gateway and iSCSI name become corrupted like shown below in the example output titled After qaucli. From QLogic support i got a referral towards Dell, since it's a OEM HBA. From Dell i got the answer that Debian isn't a supported OS. So no help from the vendor side of this issue :-/ I'd rather refrain from using the qaucli utility altogether, but un- fortunately i haven't been able to figure out if and how this can be achieved with the iscsiadm -m fw [...] or a similar command. Thanks best regards, Frank Fegert Before qaucli - Begin ### hostname:~# /opt/QLogic_Corporation/QConvergeConsoleCLI/qaucli -iscsi -c 0 Using config file: /opt/QLogic_Corporation/QConvergeConsoleCLI/qaucli.cfg Installation directory: /opt/QLogic_Corporation/QConvergeConsoleCLI Working dir: /root Using config file: /opt/QLogic_Corporation/QConvergeConsoleCLI/iscli.cfg Loading iSCSI Data ... Loading iSCSI Instance: 1 HBA: 1 Physical Port: 1 (QME8262 , 84-8F-69-35-FC- 70) ... Loading iSCSI Instance: 2 HBA: 1 Physical Port: 2 (QME8262 , 84-8F-69-35-FC- 71) ... *** *** Displaying Port inst=0 *** *** *** Displaying HBA (Adapter) Level Information inst=0 *** HBA_Alias : *** Displaying Port General Summary Information inst=0 *** 0. HBA: 0 Port: 0 HBA Port Instance: 0 HBA Model: QME8262 HBA Serial Number: (RFE1449L34695) FW Version: 4.18.04 Type: Fiber IP Address: 10.0.0.5 Alias: iSCSI Name: iqn.2000-04.com.qlogic:isp8214.000e1e37da2c.4 PCI Function Number: 4 User Defined IP Address. IPv4 Address : 10.0.0.5 Gateway : 0.0.0.0 Subnet Mask : 255.255.255.0 iSNS : Disabled. *** Displaying ISCSI Settings inst=0 *** Force_Negotiate_Main_iSCSI_Keys : off iSCSI_Send_Markers : off(*) iSCSI_Header_Digests: on iSCSI_Data_Digests : on iSCSI_Immediate_Data: on iSCSI_Initial_R2T : on iSCSI_Data_Seq_In_Order : on(*) iSCSI_Data_PDU_In_Order : on(*) iSCSI_CHAP_Auth : off(*) iSCSI_Bidi_CHAP_Auth: on(*) iSCSI_Snack : off iSCSI_Discovery_Logout : on iSCSI_Strict_Login : off iSCSI_Error_Recovery_Level : 0(*) iSCSI_Name : iqn.2000-04.com.qlogic:isp8214.000e1e37da2c.4 iSCSI_Alias : *** Displaying Firmware Settings inst=0 *** FW_Marker : on(*) FW_Stat_Alarm : off(*) FW_Accept_AEN : off(*) FW_Access_Control : off(*) FW_Session_Mode : on(*) FW_Initiator_Mode : on(*) FW_Target_Mode : off(*) FW_Fast_Posting : off(*) FW_Sense_Buffer_Desc: off(*) AFW_Device_Timeouts : on AFW_AutoConnect : off AFW_Serlz_Task_Mngmt: on Large_Frames: on DevType : 0(*) ExeThrottle : 0 FirstBurstLen : 32764 KeepAliveTO
RE: [lldp-devel] Using net_prio cgroups with iscsi transports
[Snipped to relevant section ] Is there a suggested way for such drivers to use /netprio_map/ ? /cgdcbxd/’s cgroup creation is working fine (using our firmware dcb state machine + dcbnl_ops, no open-lldp) and I can use I can call /task_netprioidx()/ at connection time provided I use /cgexec/ with /iscsid/ to get the correct index into /netprio_map/. Not sure if this is the best approach however, does anyone have a better suggestion ? Would it make sense for the /sk_cgrp_prioidx/ to hang off the skb or have /libiscsi/ provide this value to open-iscsi transports for a more generic implementation ? I wouldn't want to add this to the skb. We would prefer to make the skbuff smaller not larger at this point. If you can think up a more generic mechanism to add it to libiscsi without being overly intrusive that seems reasonable to me. At the moment I don't have any better suggestions. Thanks, John [Anish Bhatt] Sounds reasonable. Could be accomplished by passing the value of task_netprioidx(current) to the transports via set_host_param or during ep_connect if open-iscsi is okay with this. -Anish -- 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. For more options, visit https://groups.google.com/d/optout.
Using net_prio cgroups with iscsi transports
I was trying to use the sk_cgrp_prioidx value to find correct dcb priority for iscsi (using cgdcbxd + cgrulesengd as recommended by http://open-lldp.org/dcb_overview). The sk_cgrp_prioidx index into netprio_map hangs off of struck sock, and the particular iscsi offload driver I'm working with (cxgb4i) does not actually use struck sock at all. From a preliminary glance, other open-iscsi offload transports do not seem to use a struck sock either (don't quote me on this ) leaving them unable to actually find the priority index into netprio_map. Is there a suggested way for such drivers to use netprio_map ? cgdcbxd's cgroup creation is working fine (using our firmware dcb state machine + dcbnl_ops, no open-lldp) and I can use I can call task_netprioidx() at connection time provided I use cgexec with iscsid to get the correct index into netprio_map. Not sure if this is the best approach however, does anyone have a better suggestion ? Would it make sense for the sk_cgrp_prioidx to hang off the skb or have libiscsi provide this value to open-iscsi transports for a more generic implementation ? -Anish One socket to bind them all. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: Using net_prio cgroups with iscsi transports
Replying for visibility as open-lldp bounced the original message. On Monday, July 6, 2015 at 5:40:24 PM UTC-7, Anish Bhatt wrote: I was trying to use the *sk_cgrp_prioidx* value to find correct dcb priority for iscsi (using *cgdcbxd* + *cgrulesengd* as recommended by http://open-lldp.org/dcb_overview). The *sk_cgrp_prioidx* index into * netprio_map* hangs off of *struck sock*, and the particular iscsi offload driver I’m working with (cxgb4i) does not actually use struck sock at all. From a preliminary glance, other open-iscsi offload transports do not seem to use a *struck sock* either (don’t quote me on this ) leaving them unable to actually find the priority index into *netprio_map*. Is there a suggested way for such drivers to use *netprio_map* ? *cgdcbxd*’s cgroup creation is working fine (using our firmware dcb state machine + dcbnl_ops, no open-lldp) and I can use I can call *task_netprioidx()* at connection time provided I use *cgexec* with * iscsid* to get the correct index into *netprio_map*. Not sure if this is the best approach however, does anyone have a better suggestion ? Would it make sense for the *sk_cgrp_prioidx* to hang off the skb or have *libiscsi* provide this value to open-iscsi transports for a more generic implementation ? -Anish One socket to bind them all. -- 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. For more options, visit https://groups.google.com/d/optout.
RE: Antw: Linux kernel development reports for the 3.17 release
Pretty sure this is all scripted, and no one is being addressed individually : https://github.com/gregkh/kernel-history/blob/master/email/mass_mailer -Anish From: open-iscsi@googlegroups.com [open-iscsi@googlegroups.com] on behalf of Ulrich Windl [ulrich.wi...@rz.uni-regensburg.de] Sent: Monday, December 15, 2014 11:10 PM To: open-iscsi Subject: Antw: Linux kernel development reports for the 3.17 release Greg KH g...@kroah.com schrieb am 14.12.2014 um 21:16 in Nachricht 20141214201653.ga18...@kroah.com: [...] Your email address shows up in the changelog for the 3.16 kernel release as a contributor, but I can't seem to place it with a company. If you don't mind, could you let me know what company you work for? Or [...] Hi! Maybe I'm missing the obvious, but if you address a mailing list and want to address one or more persons specifically, I think you've got to name them instead of addressing them with you... Regards, Ulrich -- 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. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
boot support for offload transports
Hello, I was trying to figure out the current state of all the code tagged with #ifdef OFFLOAD_BOOT_SUPPORTED. The recent ibft patches don't seem to touch any of this at all, and I was wondering what the roadmap for this is ? A couple of distros seem to enable this, but the default compile for open-iscsi does not. -Anish One socket to bind them all. -- 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. For more options, visit https://groups.google.com/d/optout.
RE: boot support for offload transports
No, I was simply testing ibft wrt cxgb4i with code from tip of the open-iscsi tree. -Anish -Original Message- From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On Behalf Of Mike Christie Sent: Thursday, November 20, 2014 6:28 PM To: open-iscsi@googlegroups.com Cc: Karen Xie Subject: Re: boot support for offload transports On 11/20/2014 06:46 PM, Anish Bhatt wrote: Hello, I was trying to figure out the current state of all the code tagged with “#ifdef OFFLOAD_BOOT_SUPPORTED”. The recent ibft patches don’t seem to touch any of this at all, and I was wondering what the roadmap for this is ? A couple of distros seem to enable this, but the default compile for open-iscsi does not. Is there a bug or a distro that you need to support? -- 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. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
RE: [PATCHES] Fixup iBFT and IPv6, some cleanup
Did you by any chance take note of what cards do what? Mostly interested in bnx2i, cxgb*i, intel, and the ibm boxes with the initiator on them. [Anish Bhatt] I’d be happy with any cxgb*I support you need. I happened to be looking at all the stuff under #ifdef OFFLOAD_BOOT_SUPPORTED fairly recently myself. No, I'm afraid I'm still trying to build up a library of relevant cards, since I only have a few. If you do not know, do not worry. Just wanted to document it somewhere if we knew. -- 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.commailto:open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.commailto:open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
RE: Getting log Login authentication failed with target .. during login-redirect
0101 implies you're getting a status class of 0x1 status detail of 0x1 #define ISCSI_STATUS_CLS_REDIRECT 0x01 #define ISCSI_LOGIN_STATUS_AUTH_FAILED0x01 You are getting redirect as well as auth failed, hence. -Anish From: open-iscsi@googlegroups.com [open-iscsi@googlegroups.com] on behalf of KUMAR NITISH [csnitish...@gmail.com] Sent: Tuesday, July 29, 2014 11:19 PM To: open-iscsi@googlegroups.com Subject: Getting log Login authentication failed with target .. during login-redirect Hi all, I am using Dell EqualLogic array as target. When I make session with this target, I am getting logs as given below : login response status 0101 Login authentication failed with target iqn.2001-05.com.equallogic:0-8a0906-964f1f903-d850018d2a253d5f-nitishk521 ... .. login response status Login Success: iqn.2001-05.com.equallogic:0-8a0906-964f1f903-d850018d2a253d5f-nitishk521 if=default addr=10.115.178.29:3260 (TPGT:1 ISID:0x1) Since login response status 0101 is for iscsi login-redirect , so why Login authentication failed with target message is coming..? I think It's a bug and It should show the proper log message. Thanks, Nitish -- 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.commailto:open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.commailto:open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
RE: [PATCH trivial] iscsiadm : support using -I tcp or -I iscsi_tcp
My motivation was that the minimum required to get tcp via -I is creating an
iface file that only has iface.transport_name = tcp, which seems
unnecessary. I'll change the patch to have the changes as requested.
-Original Message-
From: Mike Christie [mailto:micha...@cs.wisc.edu]
Sent: Friday, July 25, 2014 10:48 AM
To: open-iscsi@googlegroups.com
Cc: Anish Bhatt
Subject: Re: [PATCH trivial] iscsiadm : support using -I tcp or -I iscsi_tcp
On 07/25/2014 12:26 PM, Mike Christie wrote:
On 07/24/2014 10:24 PM, Anish Bhatt wrote:
This came up as a scripting issue, iscsiadm currently does not
support specifying tcp as a default iface when nothing else is available.
Behaves exactly as if no -I option was used.
Signed-off-by: Anish Bhatt an...@chelsio.com
---
usr/iscsiadm.c | 4
1 file changed, 4 insertions(+)
diff --git a/usr/iscsiadm.c b/usr/iscsiadm.c index 389f4b8..07cf470
100644
--- a/usr/iscsiadm.c
+++ b/usr/iscsiadm.c
@@ -3351,6 +3351,10 @@ main(int argc, char **argv)
ping_interval = atoi(optarg);
break;
case 'I':
+ if (!strcmp(optarg, tcp) ||
+ !strcmp(optarg, iscsi_tcp))
+ break;
+
iface = iface_alloc(optarg, rc);
if (rc == ISCSI_ERR_INVAL) {
printf(Invalid iface name %s. Must be from
Why would you be passing in or tcp/iscsi_tcp if you did not create a
iface with that name?
If you also do the above, it then works differently from if you pass
in -I iser.
I do not think we can do this patch. If the user wanted to use ifaces then
they
should set it up properly. If in the future they were going to set some iface
setting, then I am not sure how this will work.
What I should have done was name the default iface (-I default
support) to tcp like with iser. I actually did the iser support later so that
is why
the naming is different. The default iface though was not really supposed to
be used by users. It is just a dummy iface for compat.
If you can come up with a patch to rename the default iface to tcp, and can
do it in a way where existing setups are not broken I would be happy to take
that patch.
--
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.
For more options, visit https://groups.google.com/d/optout.
RE: [PATCH v2] iscsiadm : make iface.ipaddress optional in iface configs for transports that don't have a hard requirement on it.
Yes
-Original Message-
From: Michael Christie [mailto:micha...@cs.wisc.edu]
Sent: Friday, July 25, 2014 2:10 PM
To: open-iscsi@googlegroups.com
Cc: Karen Xie; Anish Bhatt
Subject: Re: [PATCH v2] iscsiadm : make iface.ipaddress optional in iface
configs for transports that don't have a hard requirement on it.
Patch looks ok. Will merge when I get can boot up my other box.
Are you going to send a fix up patch for cxgbi_get_host_param later?
On Jul 25, 2014, at 2:42 PM, Anish Bhatt an...@chelsio.com wrote:
v2: cxgb4i changed to NOT_REQ as set ipaddress is not supported
Signed-off-by: Anish Bhatt an...@chelsio.com
---
usr/initiator_common.c | 15 ---
usr/transport.c| 8
usr/transport.h| 6 ++
3 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/usr/initiator_common.c b/usr/initiator_common.c index
50f8d41..8ff993d 100644
--- a/usr/initiator_common.c
+++ b/usr/initiator_common.c
@@ -685,9 +685,18 @@ int iscsi_host_set_net_params(struct iface_rec
*iface,
/* if we need to set the ip addr then set all the iface net settings */
if (!iface_is_bound_by_ipaddr(iface)) {
- log_warning(Please set the iface.ipaddress for iface %s,
- then retry the login command.\n, iface-name);
- return EINVAL;
+ if (t-template-set_host_ip == SET_HOST_IP_REQ) {
+ log_warning(Please set the iface.ipaddress for iface
+ %s, then retry the login command.\n,
+ iface-name);
+ return EINVAL;
+ } else if (t-template-set_host_ip == SET_HOST_IP_OPT) {
+ log_info(Optional iface.ipaddress for iface %s
+not set.\n, iface-name);
+ return 0;
+ } else {
+ return EINVAL;
+ }
}
/* these type of drivers need the netdev upd */ diff --git
a/usr/transport.c b/usr/transport.c index 2f38519..630f163 100644
--- a/usr/transport.c
+++ b/usr/transport.c
@@ -58,7 +58,7 @@ struct iscsi_transport_template iscsi_iser = {
struct iscsi_transport_template cxgb3i = {
.name = cxgb3i,
- .set_host_ip= 1,
+ .set_host_ip= SET_HOST_IP_OPT,
.ep_connect = ktransport_ep_connect,
.ep_poll= ktransport_ep_poll,
.ep_disconnect = ktransport_ep_disconnect,
@@ -67,7 +67,7 @@ struct iscsi_transport_template cxgb3i = {
struct iscsi_transport_template cxgb4i = {
.name = cxgb4i,
- .set_host_ip= 1,
+ .set_host_ip= SET_HOST_IP_NOT_REQ,
.ep_connect = ktransport_ep_connect,
.ep_poll= ktransport_ep_poll,
.ep_disconnect = ktransport_ep_disconnect,
@@ -76,7 +76,7 @@ struct iscsi_transport_template cxgb4i = {
struct iscsi_transport_template bnx2i = {
.name = bnx2i,
- .set_host_ip= 1,
+ .set_host_ip= SET_HOST_IP_REQ,
.use_boot_info = 1,
.ep_connect = ktransport_ep_connect,
.ep_poll= ktransport_ep_poll,
@@ -94,7 +94,7 @@ struct iscsi_transport_template be2iscsi = {
struct iscsi_transport_template qla4xxx = {
.name = qla4xxx,
- .set_host_ip= 0,
+ .set_host_ip= SET_HOST_IP_NOT_REQ,
.ep_connect = ktransport_ep_connect,
.ep_poll= ktransport_ep_poll,
.ep_disconnect = ktransport_ep_disconnect,
diff --git a/usr/transport.h b/usr/transport.h index 388e4b1..73041fa
100644
--- a/usr/transport.h
+++ b/usr/transport.h
@@ -20,6 +20,12 @@
#include types.h
#include config.h
+enum set_host_ip_opts {
+ SET_HOST_IP_NOT_REQ,/* iface.ipaddress is not supported
*/
+ SET_HOST_IP_REQ,/* iface.ipaddress must be specified*/
+ SET_HOST_IP_OPT,/* iface.ipaddress is not required */
+};
+
struct iscsi_transport;
struct iscsi_conn;
--
2.0.3
--
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.
For more options, visit https://groups.google.com/d/optout.
--
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.
For more options, visit https://groups.google.com/d/optout.
RE: [PATCH trivial] iscsiadm : support using -I tcp or -I iscsi_tcp
Yep. Like I mentioned it was a purely scripting thing where I was trying to fix
the mismatch with -I default implies iface.transport_name == tcp .
Going the -I iser way makes more sense, it would enable someone explicitly say
use tcp if they've changed the default to something else.
-Anish
-Original Message-
From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com]
On Behalf Of Michael Christie
Sent: Friday, July 25, 2014 2:05 PM
To: open-iscsi@googlegroups.com
Subject: Re: [PATCH trivial] iscsiadm : support using -I tcp or -I iscsi_tcp
But if you were only going to use tcp, then you do not need -I/ifaces at all.
On Jul 25, 2014, at 2:15 PM, Anish Bhatt an...@chelsio.com wrote:
My motivation was that the minimum required to get tcp via -I is creating
an iface file that only has iface.transport_name = tcp, which seems
unnecessary. I'll change the patch to have the changes as requested.
-Original Message-
From: Mike Christie [mailto:micha...@cs.wisc.edu]
Sent: Friday, July 25, 2014 10:48 AM
To: open-iscsi@googlegroups.com
Cc: Anish Bhatt
Subject: Re: [PATCH trivial] iscsiadm : support using -I tcp or -I
iscsi_tcp
On 07/25/2014 12:26 PM, Mike Christie wrote:
On 07/24/2014 10:24 PM, Anish Bhatt wrote:
This came up as a scripting issue, iscsiadm currently does not
support specifying tcp as a default iface when nothing else is
available.
Behaves exactly as if no -I option was used.
Signed-off-by: Anish Bhatt an...@chelsio.com
---
usr/iscsiadm.c | 4
1 file changed, 4 insertions(+)
diff --git a/usr/iscsiadm.c b/usr/iscsiadm.c index 389f4b8..07cf470
100644
--- a/usr/iscsiadm.c
+++ b/usr/iscsiadm.c
@@ -3351,6 +3351,10 @@ main(int argc, char **argv)
ping_interval = atoi(optarg);
break;
case 'I':
+if (!strcmp(optarg, tcp) ||
+!strcmp(optarg, iscsi_tcp))
+break;
+
iface = iface_alloc(optarg, rc);
if (rc == ISCSI_ERR_INVAL) {
printf(Invalid iface name %s. Must be from
Why would you be passing in or tcp/iscsi_tcp if you did not create a
iface with that name?
If you also do the above, it then works differently from if you pass
in -I iser.
I do not think we can do this patch. If the user wanted to use ifaces
then they should set it up properly. If in the future they were going
to set some iface setting, then I am not sure how this will work.
What I should have done was name the default iface (-I default
support) to tcp like with iser. I actually did the iser support later
so that is why the naming is different. The default iface though was
not really supposed to be used by users. It is just a dummy iface for
compat.
If you can come up with a patch to rename the default iface to tcp,
and can do it in a way where existing setups are not broken I would
be happy to take that patch.
--
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.
For more options, visit https://groups.google.com/d/optout.
--
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.
For more options, visit https://groups.google.com/d/optout.
--
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.
For more options, visit https://groups.google.com/d/optout.
[PATCH] iscsiadm : make iface.ipaddress optional in iface configs for transports that don't have a hard requirement on it.
From: Anish Bhatt an...@chelsio.com
Signed-off-by: Anish Bhatt an...@chelsio.com
---
usr/initiator_common.c | 15 ---
usr/transport.c| 8
usr/transport.h| 6 ++
3 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/usr/initiator_common.c b/usr/initiator_common.c
index 50f8d41..8ff993d 100644
--- a/usr/initiator_common.c
+++ b/usr/initiator_common.c
@@ -685,9 +685,18 @@ int iscsi_host_set_net_params(struct iface_rec *iface,
/* if we need to set the ip addr then set all the iface net settings */
if (!iface_is_bound_by_ipaddr(iface)) {
- log_warning(Please set the iface.ipaddress for iface %s,
- then retry the login command.\n, iface-name);
- return EINVAL;
+ if (t-template-set_host_ip == SET_HOST_IP_REQ) {
+ log_warning(Please set the iface.ipaddress for iface
+ %s, then retry the login command.\n,
+ iface-name);
+ return EINVAL;
+ } else if (t-template-set_host_ip == SET_HOST_IP_OPT) {
+ log_info(Optional iface.ipaddress for iface %s
+not set.\n, iface-name);
+ return 0;
+ } else {
+ return EINVAL;
+ }
}
/* these type of drivers need the netdev upd */
diff --git a/usr/transport.c b/usr/transport.c
index 2f38519..3b4199f 100644
--- a/usr/transport.c
+++ b/usr/transport.c
@@ -58,7 +58,7 @@ struct iscsi_transport_template iscsi_iser = {
struct iscsi_transport_template cxgb3i = {
.name = cxgb3i,
- .set_host_ip= 1,
+ .set_host_ip= SET_HOST_IP_OPT,
.ep_connect = ktransport_ep_connect,
.ep_poll= ktransport_ep_poll,
.ep_disconnect = ktransport_ep_disconnect,
@@ -67,7 +67,7 @@ struct iscsi_transport_template cxgb3i = {
struct iscsi_transport_template cxgb4i = {
.name = cxgb4i,
- .set_host_ip= 1,
+ .set_host_ip= SET_HOST_IP_OPT,
.ep_connect = ktransport_ep_connect,
.ep_poll= ktransport_ep_poll,
.ep_disconnect = ktransport_ep_disconnect,
@@ -76,7 +76,7 @@ struct iscsi_transport_template cxgb4i = {
struct iscsi_transport_template bnx2i = {
.name = bnx2i,
- .set_host_ip= 1,
+ .set_host_ip= SET_HOST_IP_REQ,
.use_boot_info = 1,
.ep_connect = ktransport_ep_connect,
.ep_poll= ktransport_ep_poll,
@@ -94,7 +94,7 @@ struct iscsi_transport_template be2iscsi = {
struct iscsi_transport_template qla4xxx = {
.name = qla4xxx,
- .set_host_ip= 0,
+ .set_host_ip= SET_HOST_IP_NOT_REQ,
.ep_connect = ktransport_ep_connect,
.ep_poll= ktransport_ep_poll,
.ep_disconnect = ktransport_ep_disconnect,
diff --git a/usr/transport.h b/usr/transport.h
index 388e4b1..73041fa 100644
--- a/usr/transport.h
+++ b/usr/transport.h
@@ -20,6 +20,12 @@
#include types.h
#include config.h
+enum set_host_ip_opts {
+ SET_HOST_IP_NOT_REQ,/* iface.ipaddress is not supported */
+ SET_HOST_IP_REQ,/* iface.ipaddress must be specified*/
+ SET_HOST_IP_OPT,/* iface.ipaddress is not required */
+};
+
struct iscsi_transport;
struct iscsi_conn;
--
2.0.1
--
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.
For more options, visit https://groups.google.com/d/optout.
RE: [PATCH] iscsiadm : make iface.ipaddress optional in iface configs for transports that don't have a hard requirement on it.
I had actually sent this patch out quite some time ago, but it never got applied or followed up on. -Anish -- 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. For more options, visit https://groups.google.com/d/optout.
[PATCH trivial] iscsiadm : support using -I tcp or -I iscsi_tcp
This came up as a scripting issue, iscsiadm currently does not support
specifying tcp as a default iface when nothing else is available.
Behaves exactly as if no -I option was used.
Signed-off-by: Anish Bhatt an...@chelsio.com
---
usr/iscsiadm.c | 4
1 file changed, 4 insertions(+)
diff --git a/usr/iscsiadm.c b/usr/iscsiadm.c
index 389f4b8..07cf470 100644
--- a/usr/iscsiadm.c
+++ b/usr/iscsiadm.c
@@ -3351,6 +3351,10 @@ main(int argc, char **argv)
ping_interval = atoi(optarg);
break;
case 'I':
+ if (!strcmp(optarg, tcp) ||
+ !strcmp(optarg, iscsi_tcp))
+ break;
+
iface = iface_alloc(optarg, rc);
if (rc == ISCSI_ERR_INVAL) {
printf(Invalid iface name %s. Must be from
--
2.0.1
--
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.
For more options, visit https://groups.google.com/d/optout.
RE: Does open-iscsi implement target and initiator?
Perf information by itself is probably not enough to know about any blocks on the target, but open-iscsi is an initiator-only implementation. A corresponding target implementation called IET can be found here : http://sourceforge.net/projects/iscsitarget/ There is also http://stgt.sourceforge.net/ -Anish Bhatt From: open-iscsi@googlegroups.com [open-iscsi@googlegroups.com] on behalf of fel...@usto.re [fel...@usto.re] Sent: Wednesday, June 11, 2014 10:10 AM To: open-iscsi@googlegroups.com Subject: Does open-iscsi implement target and initiator? Hi, I am reading the http://www.open-iscsi.org/docs/README and I am not sure if open-iscsi is only for initiator. Does open-iscsi implement target of iscsi on linux? and this information says I could have blocks on my target? single iSCSI session: * 450MB/s Read and 450 MB/s Write for 64KB block Thanks! Felipe -- 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.commailto:open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.commailto:open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
RE: [PATCH] iscsid: Add support for net_prio cgroups
I was looking at support for cxgb*i, since open-iscsi previously only had DCB support for the software initiator. I'm guessing with cgdcbxd the task of looking up cgroup and assigning priority to the traffic is left to the individual transports now ? -Anish One socket to bind them all. -Original Message- From: Mike Christie [mailto:micha...@cs.wisc.edu] Sent: Monday, June 11, 2012 3:40 PM To: open-iscsi@googlegroups.com Cc: Anish Bhatt Subject: Re: [PATCH] iscsid: Add support for net_prio cgroups On 06/08/2012 11:10 PM, Anish Bhatt wrote: Mike, Has there been any progress in figuring out how DCB would co-exist with net prio cgroups since you removed DCB support ? -Anish I think people were saying to do something with cgdcbxd. Are you guys using DCB with iSCSI for software iscsi or with cxgb*i? On Monday, February 27, 2012 2:15:51 PM UTC-8, Rustad, Mark D wrote: Mike, On Feb 27, 2012, at 1:24 PM, Mike Christie wrote: When it is changed, is there some event from the kernel/userspace that we can listen for or will it cause the current connection to be come disconnected and then on the reconnect we recheck and that is how we get the update? It is simpler and more direct than that. On packet egress, if the skb has no priority and came from a socket, the socket is checked to see if it is in a cgroup. If it is, and a priority has been configured for that cgroup and interface, then the priority is applied to the skb at that point. So there is no session disruption at all. A separate daemon takes DCB app priority changes as they happen and sets them up for the necessary cgroups. So there is an event from the kernel, but this new daemon does all of the processing for it. That is what drives the changes. Since if an skb already has a priority the net_prio cgroup code will not be executed, this patch simply prevents iscsid from setting a priority when the net_prio cgroup exists. Code wise patch looks ok Yeah, ultimately it would be nice to simply remove all of the DCB-related code from iscsid, since with the net_prio cgroups, it can all happen in a better way without any of it. The only reason not to do that now, is just to avoid any disruption to those using it as it is today. I knew that the current DCB implementation that I submitted last year would not stand - and I was working on a better, simpler way to do it - but I was not expecting we could get to a place where no app change was needed at all. That was a very pleasant surprise. At least the current implementation enabled some exploration and evaluation of iSCSI with DCB. I think you are in a better position than I to judge when the DCB code can simply be removed. -- Mark Rustad, LAN Access Division, Intel Corporation -- You received this message because you are subscribed to the Google Groups open-iscsi group. To view this discussion on the web visit https://groups.google.com/d/msg/open-iscsi/-/FmX53RYghW8J. 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?hl=en. -- 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?hl=en.
RE: [PATCH] iscsid: Add support for net_prio cgroups
We're doing it in firmware as well, since it already has all DCB info. I was just checking if there was any plan to make the transports interact with cgroups in a uniform way, as previously DCB was left upto individual implementations. Guess not. -Anish One socket to bind them all. -Original Message- From: Mike Christie [mailto:micha...@cs.wisc.edu] Sent: Monday, June 11, 2012 4:17 PM To: open-iscsi@googlegroups.com Cc: Anish Bhatt Subject: Re: [PATCH] iscsid: Add support for net_prio cgroups On 06/11/2012 06:08 PM, Anish Bhatt wrote: I was looking at support for cxgb*i, since open-iscsi previously only had DCB support for the software initiator. I'm guessing with cgdcbxd the task of looking up cgroup and assigning priority to the traffic is left to the individual transports now ? How does it work with cxgb*i drivers? So you can create a cgroup for a offloaded iscsi connection and it just works? It is only iscsi_tcp and cxgb*i that need this. The other offload drivers are doing everything in fw/hw. -- 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?hl=en.
Re: [PATCH] iscsid: Add support for net_prio cgroups
Mike, Has there been any progress in figuring out how DCB would co-exist with net prio cgroups since you removed DCB support ? -Anish On Monday, February 27, 2012 2:15:51 PM UTC-8, Rustad, Mark D wrote: Mike, On Feb 27, 2012, at 1:24 PM, Mike Christie wrote: When it is changed, is there some event from the kernel/userspace that we can listen for or will it cause the current connection to be come disconnected and then on the reconnect we recheck and that is how we get the update? It is simpler and more direct than that. On packet egress, if the skb has no priority and came from a socket, the socket is checked to see if it is in a cgroup. If it is, and a priority has been configured for that cgroup and interface, then the priority is applied to the skb at that point. So there is no session disruption at all. A separate daemon takes DCB app priority changes as they happen and sets them up for the necessary cgroups. So there is an event from the kernel, but this new daemon does all of the processing for it. That is what drives the changes. Since if an skb already has a priority the net_prio cgroup code will not be executed, this patch simply prevents iscsid from setting a priority when the net_prio cgroup exists. Code wise patch looks ok Yeah, ultimately it would be nice to simply remove all of the DCB-related code from iscsid, since with the net_prio cgroups, it can all happen in a better way without any of it. The only reason not to do that now, is just to avoid any disruption to those using it as it is today. I knew that the current DCB implementation that I submitted last year would not stand - and I was working on a better, simpler way to do it - but I was not expecting we could get to a place where no app change was needed at all. That was a very pleasant surprise. At least the current implementation enabled some exploration and evaluation of iSCSI with DCB. I think you are in a better position than I to judge when the DCB code can simply be removed. -- Mark Rustad, LAN Access Division, Intel Corporation -- You received this message because you are subscribed to the Google Groups open-iscsi group. To view this discussion on the web visit https://groups.google.com/d/msg/open-iscsi/-/FmX53RYghW8J. 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?hl=en.
[PATCH] make if.ipaddress optional in iface configuration files for offload iscsi
Currently, the iface.ipaddress field is required in iface files for offload iscsi. This is not generated by `iscsiadm -m iface` , requiring manual editing of the files. However, some transports (like Chelsio) can work without needing the ipaddress to be explicitly defined in the iface files. This patch lets the transport template specify that this field is optional. After patch, transport can pull ip address from the system, but this can still be overridden by specifying iface.ipaddress , thus dropping the hard requirement. -Anish Bhatt One socket to bind them all. -- 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?hl=en. oiscsi_fix_iface_generation.patch Description: oiscsi_fix_iface_generation.patch
RE: [PATCH] make if.ipaddress optional in iface configuration files for offload iscsi
-Original Message-
From: Mike Christie [mailto:micha...@cs.wisc.edu]
Sent: Tuesday, October 25, 2011 3:45 PM
To: open-iscsi@googlegroups.com
Cc: Anish Bhatt
Subject: Re: [PATCH] make if.ipaddress optional in iface configuration
files for offload iscsi
On 10/25/2011 01:58 PM, Anish Bhatt wrote:
Currently, the iface.ipaddress field is required in iface files for
offload iscsi. This is not generated by `iscsiadm -m iface` ,
requiring
manual editing of the files. However, some transports (like Chelsio)
can
work without needing the ipaddress to be explicitly defined in the
iface
files. This patch lets the transport template specify that this
field
is optional. After patch, transport can pull ip address from the
system,
but this can still be overridden by specifying iface.ipaddress ,
thus
dropping the hard requirement.
Ah, I thought we always had to set it for chelsio cards. For chelsio
cards does this work if the iscsi function does not have any address
set
at all or is it already setup by some other tools or previous iscsiadm
run?
Nope, it does not require any setting of ip address at all, as long is
link is up with an address.
If nothing is set by the iscsi tools is the ip of the netdev/ethX that
the iscsi interface is bound supposed to be used then?
Yes, the default behavior is to use the ip from the netdev/ethX which
was already upstream but never hit due to this requirement.
+ return EINVAL;
+ } else if(t-template-set_host_ip == SET_HOST_IP_OPT)
{
+ log_info(Optional iface.ipaddress for iface
%s,
+not set.\n, iface-name);
+ return 0;
diff --git a/usr/transport.c b/usr/transport.c
index 5d6bea4..fc85ce7 100644
--- a/usr/transport.c
+++ b/usr/transport.c
@@ -45,7 +45,7 @@ struct iscsi_transport_template iscsi_iser = {
struct iscsi_transport_template cxgb3i = {
.name = cxgb3i,
- .set_host_ip= 1,
+ .set_host_ip= 2,
.ep_connect = ktransport_ep_connect,
.ep_poll= ktransport_ep_poll,
.ep_disconnect = ktransport_ep_disconnect,
@@ -54,7 +54,7 @@ struct iscsi_transport_template cxgb3i = {
struct iscsi_transport_template cxgb4i = {
.name = cxgb4i,
- .set_host_ip= 1,
+ .set_host_ip= 2,
.ep_connect = ktransport_ep_connect,
.ep_poll= ktransport_ep_poll,
.ep_disconnect = ktransport_ep_disconnect,
diff --git a/usr/transport.h b/usr/transport.h
Since you made it into a enum use the enum names instead of the
numerical values. It will be easier to read.
Update patch attached. Left .set_host_ip = 0 untouched though. Added
some comments.
-Anish
--
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?hl=en.
oiscsi_fix_iface_generation_v2.patch
Description: oiscsi_fix_iface_generation_v2.patch
RE: [PATCH] make if.ipaddress optional in iface configuration files for offload iscsi
Wasn't sure why set_host_ip for qla4xx was explicitly set to default value; thought in hindsight should have removed that. v3 attached, hopefully this is the final patch :) -Anish One socket to bind them all. -Original Message- From: Mike Christie [mailto:micha...@cs.wisc.edu] Sent: Tuesday, October 25, 2011 4:38 PM To: open-iscsi@googlegroups.com Cc: Anish Bhatt Subject: Re: [PATCH] make if.ipaddress optional in iface configuration files for offload iscsi On 10/25/2011 06:20 PM, Anish Bhatt wrote: Update patch attached. Left .set_host_ip = 0 untouched though. Added some comments. Why is that? If you are going to change it you should clean it all up. -- 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?hl=en. oiscsi_fix_iface_generation_v3.patch Description: oiscsi_fix_iface_generation_v3.patch
RE: question on the DCB support
Or, The DCB patches are in the open-iscsi git tree which currently resides at http://github.com/mikechristie/open-iscsi There doesn't seem to be any documentation on this as of now, but from what I understand it was decided that none of this should be set via iscsiadm, suggesting the use of the lldp daemon instead. -Anish One socket to bind them all. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On Behalf Of Or Gerlitz Sent: Monday, October 10, 2011 7:27 AM To: open-iscsi@googlegroups.com Cc: Mike Christie Subject: question on the DCB support Hi, I haven't followed so far on the DCB support in open-iscsi and will be happy for help to get quick catch up / crash course. I saw patches to user space and now some patches to upstream. So what is the status of the kernel patches? also do we have some documentation (maybe in the git change log and/or emails or in a readme or a like) for the iscsiadm commands to set this or that feature? specifically, is it possible to set the vlan Priory Bits to be used by a session established over a given vlan (e.g the equivalent of vconfig set egress-map) Also, mike, where are the iscsi tree now? are you back to kernel.org or @ github or somewhere else, I wasn't sure. thanks, Or. -- 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?hl=en. -- 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?hl=en.
RE: Add initial DCB support
Mark, I was reading up on some previous correspondence regarding how iSCSI traffic should be sent via a separate VLAN. I'm trying to figure out the use case for said scenario. Is the idea that iscsi traffic is run over a separate VLAN interface (created using the VLAN id from the VLAN header for iSCSI configured on the switch) but with the priority group pulled from DCBX ? The set_dcb_priority() calls upstream seem to suggest this approach. Or were u suggesting that open-iscsi create some sort of internal VLAN for explicit DCB use ? -Anish One socket to bind them all. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On Behalf Of Rustad, Mark D Sent: Friday, October 07, 2011 2:35 PM To: open-iscsi@googlegroups.com; Anish Bhatt Cc: shyam_i...@dell.com Subject: Re: Add initial DCB support Anish, On Oct 7, 2011, at 1:47 PM, Anish Bhatt wrote: Bringing up an old discussion for clarification here. If I understand correctly iscsi tlvs will be exchanged with protocol id set to 3260(0xCBC) at all times, and this will get mapped to the correct iscsi traffic flow at the endpoint irrespective of actual running port number. Is that correct ? -Anish Yes. The port number used in the tlv identifies the application by its well-known port number, but the application can still be configured to use whatever port it wants. -- Mark Rustad, LAN Access Division, Intel Corporation -- 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?hl=en. -- 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?hl=en.
RE: Add initial DCB support
Bringing up an old discussion for clarification here. If I understand correctly iscsi tlvs will be exchanged with protocol id set to 3260(0xCBC) at all times, and this will get mapped to the correct iscsi traffic flow at the endpoint irrespective of actual running port number. Is that correct ? -Anish One socket to bind them all. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On Behalf Of Rustad, Mark D Sent: Thursday, February 03, 2011 9:21 AM To: open-iscsi@googlegroups.com; shyam_i...@dell.com Subject: RE: Add initial DCB support Shyam, On Thursday, February 03, 2011 7:55 AM, shyam iyer wrote: And to change the priority in the kernel via userspace are you posting a related patch to dcbtool ? Specifically adding the iSCSI subtype.. dcbtool has support for the CEE form for specifying iSCSI. The kernel was not doing much with it, but patches that are in the works are fixing that. lldptool will handle the DCBX forms and the kernel will handle them as well. You will note that the netlink interface used here specifies the protocol by well-known port number, adopting the DCBX means of specifying protocol. So please don't change the use of the well-known port in dcb_app.c to the port actually in use - the well-known port is exactly what is wanted for this purpose. -- Mark Rustad, LAN Access Division, Intel Corporation. -- 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?hl=en. -- 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?hl=en.
RE: multiple LUNs
Assuming all your LUNs are under the same target, you can check what LUNs are being served by `iscsiadm -m session -P 3` after you log in. Maybe 4 is not the correct LUN number (the first LUN being LUN 0) ? -Anish One socket to bind them all. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On Behalf Of Scott Classen Sent: Friday, September 23, 2011 2:52 PM To: open-iscsi@googlegroups.com Subject: multiple LUNs I'm going crazy here. I apologize if this is not on topic for this list and will happily take my question elsewhere if you feel it doesn't belong on this list. I have just installed CentOS6 onto an iSCSI LUN served from my NetApp. I have configured iPXE to boot from LUN #4 by adding the following lines in my dhcpd.conf file option iscsi-initiator-iqn iqn.2010-11.com.mymachine; option root-path iscsi:192.168.1.12:::4:iqn.1992- 08.com.netapp:sn.123456789; I would now like to set up four KVM virtual machines each installed on a seperate iSCSI LUN. To do this I would now like to access four additional iSCSI LUNS from the same NetApp. I can't for the life of me figure out how to get iscsiadm to find and log into these additional targets. iscsiadm indicates I have one active session for my root partaion: [root@meh]# iscsiadm -m session -P 1 Target: iqn.1992-08.com.netapp:sn.123456789 Current Portal: 192.168.1.12:3260,2000 Persistent Portal: 192.168.1.12:3260,2000 When I issue a command to discover new targets I get nothing new: [root@meh]# iscsiadm -m discoverydb -p 192.168.1.12:3260 -t st -- discover 192.168.1.12:3260,2000 iqn.1992-08.com.netapp:sn.123456789 and: [root@meh]# iscsiadm -m node -P 1 Target: iqn.1992-08.com.netapp:sn.123456789 Portal: 192.168.1.12:3260,2000 Iface Name: default How do I get iscsadm to see the other LUNs? Thanks -- 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?hl=en. -- 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?hl=en.
RE: Error inserting libiscsi2 and other modules
Anton, Your externally compiled open-iscsi modules are conflicting with the inbox modules (*iscsi2) shipped with RHEL/CentOS 5. A quick hack to get around this would be to remove all modules matching *iscsi* from the /lib/modules/kernel_ver/kernel/drivers/scsi, followed by a make install on open-iscsi. You will need to reboot the machine before you can use open-iscsi. Regards, -Anish One socket to bind them all. -Original Message- From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On Behalf Of Anton Aleksandrov Sent: Wednesday, February 23, 2011 5:35 AM To: open-iscsi Subject: Error inserting libiscsi2 and other modules Hello, I have just compiled open-iscsi on a fresh Centos5.5 (Linux localost 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux). Compilation went through without any errors. but when I am trying to start iscsi service, I get these error messages: Starting iSCSI daemon: WARNING: Error inserting scsi_transport_iscsi (/ lib/modules/2.6.18-194.32.1.el5/kernel/drivers/scsi/ scsi_transport_iscsi.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error inserting scsi_transport_iscsi1 (/lib/modules/ 2.6.18-194.32.1.el5/kernel/drivers/scsi/scsi_transport_iscsi1.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error inserting libiscsi (/lib/modules/2.6.18-194.32.1.el5/ kernel/drivers/scsi/libiscsi.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error inserting libiscsi2 (/lib/modules/2.6.18-194.32.1.el5/ kernel/drivers/scsi/libiscsi2.ko): Unknown symbol in module, or unknown parameter (see dmesg) ... ... ... FATAL: Error inserting be2iscsi (/lib/modules/2.6.18-194.32.1.el5/ kernel/drivers/scsi/be2iscsi/be2iscsi.ko): Unknown symbol in module, or unknown parameter (see dmesg) [FAILED] dmesg has these lines (several times): scsi_transport_iscsi2: Unknown symbol iscsi_if_load scsi_transport_iscsi2: Unknown symbol iscsi_if_release I could not find anyone with the same problem.. I tried reinstalling kernel-devel package several times. I would appreciate your attention and help. Regards, Anton. -- 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?hl=en. -- 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?hl=en.
case sensitivity of hardware addresses vlan configs
MAC addresses specified in iface files are currently case sensitive. This can be an issue on vlan interfaces, as isciadm -m iface does not create config files for vlan interfaces and they need to be written manually. Attached patch will convert uppercase MAC addresses to lower case after reading them (iscsiadm expects them in lower case only). There seems to be another issue with VLAN interfaces. Interface files for offloaded vlan interfaces (on chelsio cards atleast) need a hardware address to be specified to work. As of now, iscsiadm does not catch this and will simply fail. This is already noted in the readme, but would there be any interest in adding functionality to 'iscsiadm -m iface' to handle vlan interfaces, or warn about missing hwaddress keys when it comes to offloaded vlan interfaces ? -Anish -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en. patch_case_sensitive_hwadd Description: patch_case_sensitive_hwadd
RE: case sensitivity of hardware addresses vlan configs
-Original Message- From: Mike Christie [mailto:micha...@cs.wisc.edu] Sent: Wednesday, November 03, 2010 12:36 PM To: open-iscsi@googlegroups.com Cc: Anish Bhatt; Benjamin Li Subject: Re: case sensitivity of hardware addresses vlan configs ccing Ben Li from Broadcom. On 11/02/2010 06:42 PM, Anish Bhatt wrote: MAC addresses specified in iface files are currently case sensitive. This can be an issue on vlan interfaces, as isciadm -m iface does not create config files for vlan interfaces and they need to be written manually. Attached patch will convert uppercase MAC addresses to lower case after reading them (iscsiadm expects them in lower case only). There seems to be another issue with VLAN interfaces. Interface files for offloaded vlan interfaces (on chelsio cards atleast) need a hardware address to be specified to work. As of now, iscsiadm does not catch this So for software iscsi and vlans, you just need to specify the netdev vlan name (for example eth0.1 for the iface.net_ifacename). You do not need to set the hwaddress/mac in the iface. For cxgbXi with vlan interfaces, if hwaddress is not specified iscsiadm cannot resolve a hostno; and this further causes scsi_host_lookup to fail, resulting in an incorrect scsi_host being passed to libcxgbi. Not sure if this is Chelsio specific, but it differs from software iscsi behavior. iscsiadm does not catch what you need for offload because I had no idea you were doing this. For chelsio offload how are you guys specifying things when vlans are used and what does cxgb3i export? Do you have to create a vlan with the normal linux tools like vconfig first, then for the net_ifacename are you specifying the vlan name created by vconfig? cxgbi_device_find_by_netdev then matches the names with the real netdev? Why do you need to pass in the hardware address? Yep, exactly what we do. vconfig + specify interface name and ip in iface file. For reasons mentioned above, VLAN interfaces do need a hardware address to be specified. There was talk about adding a vlan id: http://groups.google.com/group/open- iscsi/browse_thread/thread/7ee3b5bb5502871b/37fe62da7d1ffa4e?lnk=gstq= Using+IFACE_SUBNET_MASK+and+IFACE_VLAN#37fe62da7d1ffa4e so we could have a more common way of specifying the vlan to be used. and will simply fail. This is already noted in the readme, but would What note in the readme are you referring to? Sorry, I meant the cxgbXi readme. Current solution right now is to tell end users to specify a hardware address with vlan interface files. I'd like to add that once in a while, I have seen 'iscsiadm -m iface' create iface files for vlan interfaces, and here the hwaddress gets written in uppercase, rather than the lower case required. This is not easily reproducible and creates issues due to case sensitivity. there be any interest in adding functionality to 'iscsiadm -m iface' to handle vlan interfaces, or warn about missing hwaddress keys when it comes to offloaded vlan interfaces ? -Anish -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
RE: case sensitivity of hardware addresses vlan configs
Eddie/Ben, Sounds like a good idea to me. Our current solution needs net_ifacename, ipaddress, hwaddress transport_name to work. This would require iface.vlan inplace of iface.net_ifacename + iface.hwaddress, right ? -Anish -Original Message- From: Benjamin Li [mailto:be...@broadcom.com] Sent: Wednesday, November 03, 2010 1:05 PM To: Mike Christie Cc: open-iscsi@googlegroups.com; Anish Bhatt; Eddie Wai Subject: Re: case sensitivity of hardware addresses vlan configs Hi Anish, For the current the Broadcom solution using VLAN's, we currently have the use the standard Linux tool, vconfig to create a VLAN interface. This doesn't give much flexability, so we are working on a solution to utlize the existing iface.subnet_mask and iface.vlan fields so that users can specify multiple VLAN's configurations via multiple ifaces files. This way the iSCSI offload solution doesn't have to have any dependency on the L2 interface. My colleague Eddie Wai, is working on this solution. This is a perfect time to discuss a common solution. Adding Eddie to the thread, Thanks again. -Ben On Wed, 2010-11-03 at 12:36 -0700, Mike Christie wrote: ccing Ben Li from Broadcom. On 11/02/2010 06:42 PM, Anish Bhatt wrote: MAC addresses specified in iface files are currently case sensitive. This can be an issue on vlan interfaces, as isciadm -m iface does not create config files for vlan interfaces and they need to be written manually. Attached patch will convert uppercase MAC addresses to lower case after reading them (iscsiadm expects them in lower case only). There seems to be another issue with VLAN interfaces. Interface files for offloaded vlan interfaces (on chelsio cards atleast) need a hardware address to be specified to work. As of now, iscsiadm does not catch this So for software iscsi and vlans, you just need to specify the netdev vlan name (for example eth0.1 for the iface.net_ifacename). You do not need to set the hwaddress/mac in the iface. iscsiadm does not catch what you need for offload because I had no idea you were doing this. For chelsio offload how are you guys specifying things when vlans are used and what does cxgb3i export? Do you have to create a vlan with the normal linux tools like vconfig first, then for the net_ifacename are you specifying the vlan name created by vconfig? cxgbi_device_find_by_netdev then matches the names with the real netdev? Why do you need to pass in the hardware address? There was talk about adding a vlan id: http://groups.google.com/group/open- iscsi/browse_thread/thread/7ee3b5bb5502871b/37fe62da7d1ffa4e?lnk=gstq= Using+IFACE_SUBNET_MASK+and+IFACE_VLAN#37fe62da7d1ffa4e so we could have a more common way of specifying the vlan to be used. and will simply fail. This is already noted in the readme, but would What note in the readme are you referring to? there be any interest in adding functionality to 'iscsiadm -m iface' to handle vlan interfaces, or warn about missing hwaddress keys when it comes to offloaded vlan interfaces ? -Anish -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@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?hl=en.
