leeman.duncan | 14 Jul 23:01 2015
Picon

[PATCH 0/2] Remove local open-isns, using system-installed version

From: Lee Duncan <lduncan@...>

This set of patches tells open-iscsi to use the system-resident
open-isns files instead of the ones in utils/open-isns.

This patch *requires* that you've installed open-isns (from
git@...:gonzoleeman/open-isns.git).

The first patch tells open-iscsi to use the system-resident
include files and library from open-isns. The second patch
removes the local copy of same.

Questions:
- Should the documentation be updated? I didn't
  find anything that referenced open-isns
- Is it perhaps time to bump the minor version
  of open-iscsi? It's been a while.

Note: it is my intention to create an open-isns package
for SUSE. I assume other platforms will have to do the
same before they could incorporate this patch.

Lee Duncan (2):
  Use system-wide open-isns, not internal version.
  Remove local copy of open-isns.

 Makefile                                           |   10 +-
 usr/Makefile                                       |    7 +-
 usr/discovery.c                                    |    6 +-
 usr/discoveryd.c                                   |    8 +-
(Continue reading)

leeman.duncan | 13 Jul 23:57 2015
Picon

[PATCH 0/3] open-isns: prepare for external use by open-iscsi

From: Lee Duncan <lduncan@...>

This group of patches is for open-isns, and the current procedure for
changes to open-isns is to share them on the open-iscsi mailing list.

The goal of these patches is to make open-isns a stand-alone package
that can be used by other (like open-iscsi). This way clients don't
have to have their own (possibly stale) copies of these files.

NOTE: there are NO FUNCTIONAL CHANGES here, just:
* moving some inclue files locally to include/libisns directory
* changing all users of include files to know new location
* Adding "install_lib" and "install_hdrs" Makefile targets

This has been tested with open-iscsn and seems to work.

Lee Duncan (3):
  Move public inlcude files to <libisns/*.h>
  Make one more include file public.
  Add test binaries as 'make clean' targets.

 Makefile.in                  |  27 +-
 attrs.c                      |   6 +-
 attrs.h                      | 262 -----------------
 authblock.c                  |   8 +-
 bitvector.c                  |   4 +-
 buffer.c                     |   4 +-
 buffer.h                     | 141 ---------
 callback.c                   |   6 +-
 client.c                     |   4 +-
(Continue reading)

leeman.duncan | 10 Jul 21:08 2015
Picon

[PATCH] Read iBFT 'origin' as an integer, not a string

From: Lee Duncan <lduncan@...>

Recent patches have added support for iBFT 'origin' when determining
the source of the iBFT boot IP Address, but this value is an
enum (integer), not a string. This patch fixes the one place
it was read as a string.

Lee Duncan (1):
  iBFT 'origin' is an enum, not a string

 utils/fwparam_ibft/fwparam_ibft_sysfs.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

-- 
2.1.4

--

-- 
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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

adheer.chandravanshi | 9 Jul 13:38 2015

[PATCH v2 0/2] open-iscsi: Ping support in iscsiuio

From: Adheer Chandravanshi <adheer.chandravanshi@...>

Mike,

This is patchset v2 to add ping support in iscsiuio.
Please review and apply following patches to open-iscsi.git tree at your earliest convenience.

Changes with respect to first patchset:
- Removed the iface apply operation for bnx2i transport
  Now, iface config will be passed to iscsiuio during ping operation itself.

- Reduced the patchset to only two necessary patches for the required support

Adheer Chandravanshi (2):
  iscsid: Changes to support ping through iscsiuio
  iscsiuio: Add ping support through iscsiuio

Thanks,
Adheer

--

-- 
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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Anish Bhatt | 7 Jul 02:40 2015

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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

lokesharo | 1 Jul 15:25 2015
Picon

iSNS Fail Over Mechanism

I would like to know about the fail over mechanisms used by iSNS for ISCSI implementation. The RFC states that "Note that it is possible to create multiple physical iSNS servers to form a single logical iSNS server cluster, and thus to distribute iSNS transaction processing among multiple physical servers. However, a more detailed discussion of the interactions between physical servers within a logical iSNS server cluster is beyond the scope of this document."

I tried searching but most of the findings are related to Windows and that too does not explain what are the fail over techniques used or the implementation details.

Any links or documents about the same would be very useful. Thanks

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Christian Iversen | 29 Jun 16:40 2015
Picon

8 patches for review

Hello Open-iSCSI

(please CC as I'm not a regular on the list)

I've been working with iSCSI lately, and thought I could help with a few
patches.

Here's a description:

--> 0001-Enable-MaxOutstandingR2T-negotiation-support-in-iscs.patch

This patch enables MaxOutstandingR2T negotiation for sessions. 
Currently, max_r2t negotiation is in a weird, half-broken state. The 
kernel seems to support max_r2t > 1 just fine (at least it connects), 
but iscsiadm is hard-coded to use "1", regardless of the setting that 
the user sets in the config file, which is very confusing.

I spent more time than I'd like to admit on tracking this one down.. :)

There's even error handling in place for max_r2t > 1, but this is never 
triggered since the value "1" is hard-coded, and the config file is 
ignored. This is the worst of both worlds.

--> 0002-Removed-a-number-of-unused-variables.patch

Quick cleanup, to fix a number of compiler warnings.

--> 0003-Removed-unused-variable-and-computation.patch

Same as 0002.

--> 0004-Added-missing-pointer-dereferencing-memset-would-onl.patch
--> 0005-Added-missing-pointer-dereferencing-memset-would-onl.patch

In the duplicate(!) md5 function MD5Final(), there is a final

memset(ctx, 0, sizeof(ctx));

to clear the context of sensitive data after MD5 calculation - which is 
fine.

Unfortunately, they both refer to sizeof(ctx), which is a pointer, 
effectively nullifying (no pun intended) the effect of memset(). This is 
changed to sizeof(*ctx).

--> 0006-Removed-unused-variable-one.patch
--> 0007-Removed-unused-variable-pdu_text.patch
--> 0008-Removed-dead-code.patch

Should be self-explanatory.

These are all more or less just compile-tested. Any comments?

-- 
De bedste hilsner / Best Regards,
Christian Iversen

System Engineer

Meebox ApS
Store Kongensgade 40H,
1264 KĂžbenhavn K
T: +45 3841 3841

--

-- 
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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
LSZhu | 26 Jun 08:31 2015
Picon

May I do some contributions for iSCSI multiqueue

Hi,
I have been working for iSCSI in SUSE for half a year, I have some basic knowledge of iSCSI. I did some debug  and performance analyze work before.I am quite interested in iSCSI-mq, I am not a expert here, but may I do some contributions for iSCSI-mq? If you need me in somewhere, please let me know.

In my view, there seems such works need to be done:

(1) open-iscsi should simulate a multi-queue block device on the initiator side, I mean, /dev/sdc, sdd which simulated by open-iscsi should be multi-queue, just like we want a multi-queue hardware device as a backstore.
(2)  I/O scheduler is needed in the block layer for multi-queue, for the simulated device mentioned above.
(3) open-iscsi should establish more than one connections to the target in a session, and a  I/O scheduler is needed here.
(4) some performance improve work like how to manage multi-queue threads on multiple CPU cores, how to reduce latency, how to create a better pipeline.

I have heard that on the target LIO side, multi-queue work is done.
If I am wrong  somewhere, please tell me, I would appreciate for that.

I know you have did a lot of work for multi-queue, so if you need me somewhere, or I can help in some work, please let me know.

Thanks
BR
Zhu Lingshan

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Brian J. Murrell | 21 Jun 15:55 2015
Picon

recovering from a ping timeout, gracefully

So, clearly I have some kind of temporary/intermittent issues with my
network, unfortunately.  :-(  Fortunately they do seem to be
infrequently intermittent and most of the time things work.  But every
now and then I well get a spate of this:

Jun 19 15:08:39 eagle-4.eagle.hpdd.intel.com kernel: connection17:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082655665, last ping 5082660665, now 5082665665
Jun 19 15:08:39 eagle-4.eagle.hpdd.intel.com kernel: connection17:0: detected conn error (1011)
Jun 19 15:08:39 eagle-4.eagle.hpdd.intel.com kernel: connection24:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082655834, last ping 5082660834, now 5082665834
Jun 19 15:08:39 eagle-4.eagle.hpdd.intel.com kernel: connection24:0: detected conn error (1011)
Jun 19 15:08:40 eagle-4 iscsid: Kernel reported iSCSI connection 17:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jun 19 15:08:40 eagle-4 iscsid: Kernel reported iSCSI connection 24:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jun 19 15:08:40 eagle-4.eagle.hpdd.intel.com kernel: connection23:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082656608, last ping 5082661608, now 5082666608
Jun 19 15:08:40 eagle-4.eagle.hpdd.intel.com kernel: connection23:0: detected conn error (1011)
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection19:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082657189, last ping 5082662189, now 5082667189
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection19:0: detected conn error (1011)
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection21:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082657235, last ping 5082662235, now 5082667235
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection21:0: detected conn error (1011)
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection18:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082657253, last ping 5082662253, now 5082667253
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection18:0: detected conn error (1011)
Jun 19 15:08:41 eagle-4 iscsid: Kernel reported iSCSI connection 23:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection22:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082657666, last ping 5082662666, now 5082667666
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection22:0: detected conn error (1011)
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection20:0: ping timeout of 5 secs expired,
recv timeout 5, last rx 5082657674, last ping 5082662674, now 5082667680
Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection20:0: detected conn error (1011)
Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 19:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 21:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 18:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 22:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 20:0 error (1011 -
ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)

and then my ISCSI target it offline.  The network will recover very
shortly thereafter though and I can ping the tgtd server, etc.

What I wonder is, what is the most graceful way to tell the above
machine that things are repaired and to consider the target back in
service?  Currently after the above happens and even after the network
recovers, accessing the target returns an EIO, despite connectivity
being restored.  I'm assuming that this error state is persisted until
an operator can tell ISCSI otherwise.  But how does the operator do
that?

Surely it doesn't require tearing down the whole ISCSI infrastructure
and bringing it back up, does it?

Cheers,
b.

--

-- 
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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Chris Leech | 17 Jun 01:07 2015
Picon

[PATCH] iSCSI: let session recovery_tmo sysfs writes persist across recovery

The iSCSI session recovery_tmo setting is writeable in sysfs, but it's
also set every time a connection is established when parameters are set
from iscsid over netlink.  That results in the timeout being reset to
the default value after every recovery.

The DM multipath tools want to use the sysfs interface to lower the
default timeout when there are multiple paths to fail over.  It has
caused confusion that we have a writeable sysfs value that seem to keep
resetting itself.

This patch adds an in-kernel flag that gets set once a sysfs write
occurs, and then ignores netlink parameter setting once it's been
modified via the sysfs interface.  My thinking here is that the sysfs
interface is much simpler for external tools to influence the session
timeout, but if we're going to allow it to be modified directly we
should ensure that setting is maintained.

Signed-off-by: Chris Leech <cleech@...>
---
 drivers/scsi/scsi_transport_iscsi.c | 11 ++++++++---
 include/scsi/scsi_transport_iscsi.h |  1 +
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c
index 67d43e3..35ef55f 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
 <at>  <at>  -2040,6 +2040,7  <at>  <at>  iscsi_alloc_session(struct Scsi_Host *shost, struct iscsi_transport *transport,
 	session->transport = transport;
 	session->creator = -1;
 	session->recovery_tmo = 120;
+	session->recovery_tmo_sysfs_override = false;
 	session->state = ISCSI_SESSION_FREE;
 	INIT_DELAYED_WORK(&session->recovery_work, session_recovery_timedout);
 	INIT_LIST_HEAD(&session->sess_list);
 <at>  <at>  -2784,7 +2785,8  <at>  <at>  iscsi_set_param(struct iscsi_transport *transport, struct iscsi_uevent *ev)
 	switch (ev->u.set_param.param) {
 	case ISCSI_PARAM_SESS_RECOVERY_TMO:
 		sscanf(data, "%d", &value);
-		session->recovery_tmo = value;
+		if (!session->recovery_tmo_sysfs_override)
+			session->recovery_tmo = value;
 		break;
 	default:
 		err = transport->set_param(conn, ev->u.set_param.param,
 <at>  <at>  -4047,13 +4049,15  <at>  <at>  store_priv_session_##field(struct device *dev,				\
 	if ((session->state == ISCSI_SESSION_FREE) ||			\
 	    (session->state == ISCSI_SESSION_FAILED))			\
 		return -EBUSY;						\
-	if (strncmp(buf, "off", 3) == 0)				\
+	if (strncmp(buf, "off", 3) == 0) {				\
 		session->field = -1;					\
-	else {								\
+		session->field##_sysfs_override = true;			\
+	} else {							\
 		val = simple_strtoul(buf, &cp, 0);			\
 		if (*cp != '\0' && *cp != '\n')				\
 			return -EINVAL;					\
 		session->field = val;					\
+		session->field##_sysfs_override = true;			\
 	}								\
 	return count;							\
 }
 <at>  <at>  -4064,6 +4068,7  <at>  <at>  store_priv_session_##field(struct device *dev,				\
 static ISCSI_CLASS_ATTR(priv_sess, field, S_IRUGO | S_IWUSR,		\
 			show_priv_session_##field,			\
 			store_priv_session_##field)
+
 iscsi_priv_session_rw_attr(recovery_tmo, "%d");

 static struct attribute *iscsi_session_attrs[] = {
diff --git a/include/scsi/scsi_transport_iscsi.h b/include/scsi/scsi_transport_iscsi.h
index 2555ee5..6183d20 100644
--- a/include/scsi/scsi_transport_iscsi.h
+++ b/include/scsi/scsi_transport_iscsi.h
 <at>  <at>  -241,6 +241,7  <at>  <at>  struct iscsi_cls_session {

 	/* recovery fields */
 	int recovery_tmo;
+	bool recovery_tmo_sysfs_override;
 	struct delayed_work recovery_work;

 	unsigned int target_id;
-- 
2.1.0

--

-- 
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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

adheer.chandravanshi | 16 Jun 14:52 2015

[PATCH] iscsiuio: Correct the handling of Multi Function mode

From: Adheer Chandravanshi <adheer.chandravanshi@...>

Handle the Multi Function mode correctly when dealing with bnx2x driver.

Signed-off-by: Adheer Chandravanshi <adheer.chandravanshi@...>
---
 iscsiuio/src/unix/libs/bnx2x.c |   23 ++++++++++++++++-------
 1 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/iscsiuio/src/unix/libs/bnx2x.c b/iscsiuio/src/unix/libs/bnx2x.c
index 1495762..a364d76 100644
--- a/iscsiuio/src/unix/libs/bnx2x.c
+++ b/iscsiuio/src/unix/libs/bnx2x.c
 <at>  <at>  -672,6 +672,9  <at>  <at>  static int bnx2x_open(nic_t *nic)
 	uint32_t bus;
 	uint32_t slot;
 	uint32_t func;
+	uint32_t mode;
+	__u32 proto_offset;
+	__u32 ovtag_offset;

 	/*  Sanity Check: validate the parameters */
 	if (nic == NULL) {
 <at>  <at>  -1002,9 +1005,11  <at>  <at>  static int bnx2x_open(nic_t *nic)
 			mf_cfg_addr = bp->shmem_base + 0x7e4;

 		/* shared_feat_cfg.config */
-		val = bnx2x_rd32(bp, bp->shmem_base + 0x354);
-		/* SI mode */
-		if ((val & 0x700) == 0x300) {
+		mode = bnx2x_rd32(bp, bp->shmem_base + 0x354);
+		mode &= 0x700;
+		LOG_DEBUG(PFX "%s: mode = 0x%x", nic->log_name, mode);
+		switch (mode) {
+		case 0x300: /* SI mode */
 			mac_offset = 0xe4 + (bp->func * 0x28) + 4;
 			val = bnx2x_rd32(bp, mf_cfg_addr + mac_offset);
 			mac[0] = (__u8) (val >> 8);
 <at>  <at>  -1027,9 +1032,13  <at>  <at>  static int bnx2x_open(nic_t *nic)
 				rc = -ENOTSUP;
 				goto open_error;
 			}
-		} else if ((val & 0x700) == 0) {
-			__u32 proto_offset = 0x24 + (bp->func * 0x18);
-			__u32 ovtag_offset = proto_offset + 0xc;
+			break;
+
+		case 0x0: /* MF SD mode */
+		case 0x500:
+		case 0x600:
+			proto_offset = 0x24 + (bp->func * 0x18);
+			ovtag_offset = proto_offset + 0xc;

 			rc = -ENOTSUP;
 			val = bnx2x_rd32(bp, mf_cfg_addr + ovtag_offset);
 <at>  <at>  -1057,7 +1066,7  <at>  <at>  static int bnx2x_open(nic_t *nic)
 			mac[4] = (__u8) (val >> 8);
 			mac[5] = (__u8) val;
 			memcpy(nic->mac_addr, mac, 6);
-
+			break;
 		}
 	}
 SF:
-- 
1.7.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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.


Gmane