[ewg] [PATCH] IB/ipoib: send creation parameters with send-only join requests
When IPoiB joins to a MC group as send only it doesn't send creation parameters
to the SM and if the group does not exis it won't be created. This is typical
when a gateway sperates ETH receivers from IPoIB senders.
This patch fixes bug #1153 in bugzilla.
Signed-off-by: Yossi Etigin yos...@voltaire.com
Reviewd-by:Moni Shoua mo...@mellanox.com
--
Index: b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
===
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c2008-11-26
18:28:04.0 +0200
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c2008-11-26
18:30:41.0 +0200
@@ -325,6 +325,7 @@ static int ipoib_mcast_sendonly_join(str
.join_state = 1
#endif
};
+ ib_sa_comp_mask comp_mask;
int ret = 0;
if (!test_bit(IPOIB_FLAG_OPER_UP, priv-flags)) {
@@ -341,12 +342,38 @@ static int ipoib_mcast_sendonly_join(str
rec.port_gid = priv-local_gid;
rec.pkey = cpu_to_be16(priv-pkey);
+ comp_mask =
+ IB_SA_MCMEMBER_REC_MGID |
+ IB_SA_MCMEMBER_REC_PORT_GID |
+ IB_SA_MCMEMBER_REC_PKEY |
+ IB_SA_MCMEMBER_REC_JOIN_STATE;
+
+ if (priv-broadcast) {
+ comp_mask |=
+ IB_SA_MCMEMBER_REC_QKEY |
+ IB_SA_MCMEMBER_REC_MTU_SELECTOR |
+ IB_SA_MCMEMBER_REC_MTU |
+ IB_SA_MCMEMBER_REC_TRAFFIC_CLASS|
+ IB_SA_MCMEMBER_REC_RATE_SELECTOR|
+ IB_SA_MCMEMBER_REC_RATE |
+ IB_SA_MCMEMBER_REC_SL |
+ IB_SA_MCMEMBER_REC_FLOW_LABEL |
+ IB_SA_MCMEMBER_REC_HOP_LIMIT;
+
+ rec.qkey = priv-broadcast-mcmember.qkey;
+ rec.mtu_selector = IB_SA_EQ;
+ rec.mtu = priv-broadcast-mcmember.mtu;
+ rec.traffic_class = priv-broadcast-mcmember.traffic_class;
+ rec.rate_selector = IB_SA_EQ;
+ rec.rate = priv-broadcast-mcmember.rate;
+ rec.sl= priv-broadcast-mcmember.sl;
+ rec.flow_label= priv-broadcast-mcmember.flow_label;
+ rec.hop_limit = priv-broadcast-mcmember.hop_limit;
+ }
+
mcast-mc = ib_sa_join_multicast(ipoib_sa_client, priv-ca,
priv-port, rec,
-IB_SA_MCMEMBER_REC_MGID|
-IB_SA_MCMEMBER_REC_PORT_GID|
-IB_SA_MCMEMBER_REC_PKEY|
-IB_SA_MCMEMBER_REC_JOIN_STATE,
+comp_mask,
GFP_ATOMIC,
ipoib_mcast_sendonly_join_complete,
mcast);
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] IB/ipoib: Leave stale send-only multicast groups
This patch was sent to linux-rdma a while ago but had not been accepted yet.
However, no objection was raised so far.
Note: the patch below is not to driver/infiniband/ulp/ipoib but it generates
a patch under kernel_patches/fixes.
--
Index: ofa_kernel-1.5.3/kernel_patches/fixes/zzz_0041_add_mcast_gc.diff
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ ofa_kernel-1.5.3/kernel_patches/fixes/zzz_0041_add_mcast_gc.diff
2011-02-02 16:29:00.0 +0200
@@ -0,0 +1,206 @@
+The kernel never leaves send only multicast groups. In addition, IPoIB doesn't
+implement real send only join but it sends the SM a send/receive join request.
+In order to avoid MC group explosion on the switch, a mechanism of garbage
+collection to unused multicast groups is required.
+
+Signed-off-by: Yossi Etigin yos...@voltaire.com
+Signed-off-by: Moni Shoua mo...@voltaire.com
+--
+
+diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h
b/drivers/infiniband/ulp/ipoib/ipoib.h
+index ab97f92..fb1714f 100644
+--- a/drivers/infiniband/ulp/ipoib/ipoib.h
b/drivers/infiniband/ulp/ipoib/ipoib.h
+@@ -92,6 +92,7 @@ enum {
+ IPOIB_FLAG_ADMIN_CM = 9,
+ IPOIB_FLAG_UMCAST = 10,
+ IPOIB_FLAG_CSUM = 11,
++ IPOIB_MCAST_RUN_GC= 12,
+
+ IPOIB_MAX_BACKOFF_SECONDS = 16,
+
+@@ -132,6 +133,7 @@ struct ipoib_mcast {
+ struct list_head list;
+
+ unsigned long created;
++ unsigned long used;
+ unsigned long backoff;
+
+ unsigned long flags;
+@@ -283,7 +285,8 @@ struct ipoib_dev_priv {
+ struct rb_root multicast_tree;
+
+ struct delayed_work pkey_poll_task;
+- struct delayed_work mcast_task;
++ struct delayed_work mcast_join_task;
++ struct delayed_work mcast_leave_task;
+ struct work_struct carrier_on_task;
+ struct work_struct flush_light;
+ struct work_struct flush_normal;
+@@ -411,6 +414,8 @@ void ipoib_neigh_free(struct net_device *dev, struct
ipoib_neigh *neigh);
+
+ extern struct workqueue_struct *ipoib_workqueue;
+
++extern int ipoib_mc_sendonly_timeout;
++
+ /* functions */
+
+ int ipoib_poll(struct napi_struct *napi, int budget);
+@@ -453,6 +458,7 @@ int ipoib_dev_init(struct net_device *dev, struct
ib_device *ca, int port);
+ void ipoib_dev_cleanup(struct net_device *dev);
+
+ void ipoib_mcast_join_task(struct work_struct *work);
++void ipoib_mcast_leave_task(struct work_struct *work);
+ void ipoib_mcast_carrier_on_task(struct work_struct *work);
+ void ipoib_mcast_send(struct net_device *dev, void *mgid, struct sk_buff
*skb);
+
+diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
+index 7a07a72..563370e 100644
+--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
+@@ -67,6 +67,11 @@ module_param_named(debug_level, ipoib_debug_level, int,
0644);
+ MODULE_PARM_DESC(debug_level, Enable debug tracing if 0);
+ #endif
+
++int ipoib_mc_sendonly_timeout;
++
++module_param_named(mc_sendonly_timeout, ipoib_mc_sendonly_timeout, int, 0644);
++MODULE_PARM_DESC(mc_sendonly_timeout, Enable debug tracing if 0);
++
+ struct ipoib_path_iter {
+ struct net_device *dev;
+ struct ipoib_path path;
+@@ -1020,7 +1025,8 @@ static void ipoib_setup(struct net_device *dev)
+ INIT_LIST_HEAD(priv-multicast_list);
+
+ INIT_DELAYED_WORK(priv-pkey_poll_task, ipoib_pkey_poll);
+- INIT_DELAYED_WORK(priv-mcast_task, ipoib_mcast_join_task);
++ INIT_DELAYED_WORK(priv-mcast_join_task, ipoib_mcast_join_task);
++ INIT_DELAYED_WORK(priv-mcast_leave_task, ipoib_mcast_leave_task);
+ INIT_WORK(priv-carrier_on_task, ipoib_mcast_carrier_on_task);
+ INIT_WORK(priv-flush_light, ipoib_ib_dev_flush_light);
+ INIT_WORK(priv-flush_normal, ipoib_ib_dev_flush_normal);
+diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+index 3871ac6..87928c1 100644
+--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+@@ -117,6 +117,7 @@ static struct ipoib_mcast *ipoib_mcast_alloc(struct
net_device *dev,
+
+ mcast-dev = dev;
+ mcast-created = jiffies;
++ mcast-used = jiffies;
+ mcast-backoff = 1;
+
+ INIT_LIST_HEAD(mcast-list);
+@@ -403,7 +404,7 @@ static int ipoib_mcast_join_complete(int status,
+ mutex_lock(mcast_mutex);
+ if (test_bit(IPOIB_MCAST_RUN, priv-flags))
+ queue_delayed_work(ipoib_workqueue,
+- priv-mcast_task, 0);
++ priv-mcast_join_task, 0);
+ mutex_unlock(mcast_mutex);
+
+ /*
+@@ -436,7 +437,7 @@ static int ipoib_mcast_join_complete(int status,
+ mutex_lock(mcast_mutex);
+ spin_lock_irq(priv-lock
[ewg] [PATCH] IB/core: Control number of retries for SA to leave an MCG
This patch helps when SM is busy and so an MC group is left joined
while the host bellies that it is was left.
Note: the patch below is not to driver/infiniband/core but it generates
a patch under kernel_patches/fixes.
Index:
ofa_kernel-1.5.3/kernel_patches/fixes/core_0290_sysfs_mcast_leave_retries.patch
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++
ofa_kernel-1.5.3/kernel_patches/fixes/core_0290_sysfs_mcast_leave_retries.patch
2011-02-02 16:52:02.0 +0200
@@ -0,0 +1,46 @@
+Add a multicast leave maximum retry setting in
sys/module/ib_sa/parameters/mcast_leave_retries.
+Add a debug print when the maximum retry count is reached.
+
+Signed-off-by: Nir Muchtar n...@voltaire.com
+Reviewed-by: Moni Shoua mo...@voltaire.com
+--
+
+Index: ofa_kernel-1.5.2/drivers/infiniband/core/multicast.c
+===
+--- ofa_kernel-1.5.2.orig/drivers/infiniband/core/multicast.c 2010-08-17
12:56:06.0 +0300
ofa_kernel-1.5.2/drivers/infiniband/core/multicast.c 2010-08-17
13:15:38.0 +0300
+@@ -40,6 +40,12 @@
+ #include rdma/ib_cache.h
+ #include sa.h
+
++static int mcast_leave_retries = 3;
++
++module_param_call(mcast_leave_retries, param_set_int, param_get_int,
++mcast_leave_retries, 0644);
++MODULE_PARM_DESC(mcast_leave_retries, Number of retries for multicast leave
requests before giving up);
++
+ static void mcast_add_one(struct ib_device *device);
+ static void mcast_remove_one(struct ib_device *device);
+
+@@ -520,8 +526,11 @@
+ if (status (group-retries 0)
+ !send_leave(group, group-leave_state))
+ group-retries--;
+- else
++ else {
++ if (status group-retries = 0)
++ printk(reached max retry count. status=%d .Giving
up\n, status);
+ mcast_work_handler(group-work);
++ }
+ }
+
+ static struct mcast_group *acquire_group(struct mcast_port *port,
+@@ -544,7 +553,7 @@
+ if (!group)
+ return NULL;
+
+- group-retries = 3;
++ group-retries = mcast_leave_retries;
+ group-port = port;
+ group-rec.mgid = *mgid;
+ group-pkey_index = MCAST_INVALID_PKEY_INDEX;
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] IB/libibverbs: Add huge page support to madvise_range
A different patch for the same purpose was already sent tolinux-rdma but had
not been accepted yet. This version of the patch however, was tested heavily
by QA in Voltaire and in the field. When new libibverbs that fixes this issue
comes out we can throw this one away but until then, let's use it.
ibv_reg_mr() fails to register a memory region allocated on huge page and not
the default page size. This happens because ibv_madvise_range() aligns memory
region to the default system page size before calling to madvise() which fails
with EINVAL error. madvise() fails because it expects that the start and end
pointer of the memory range be huge page aligned.
Patch handles the issue by:
1. ibv_fork_init() gets kernel's default huge page size in addition
to the default page size.
2. ibv_madvise_range() first tries aligning users memory range to default
page size and if madvise() fails with EINVAL error then it tries to align
users memory range by huge page size and tries madvise() again.
Signed-off-by: Alex Vaynman al...@voltaire.com
Reviewed-by: Moni Shoua mo...@voltaire.com
---
src/memory.c | 69 +-
1 files changed, 68 insertions(+), 1 deletions(-)
diff --git a/src/memory.c b/src/memory.c
index 550015a..73db083 100644
--- a/src/memory.c
+++ b/src/memory.c
@@ -40,6 +40,9 @@
#include unistd.h
#include stdlib.h
#include stdint.h
+#include ctype.h
+#include fcntl.h
+#include string.h
#include ibverbs.h
@@ -54,6 +57,8 @@
#define MADV_DOFORK11
#endif
+#define MEMINFO_SIZE 2048
+
struct ibv_mem_node {
enum {
IBV_RED,
@@ -68,8 +73,51 @@ struct ibv_mem_node {
static struct ibv_mem_node *mm_root;
static pthread_mutex_t mm_mutex = PTHREAD_MUTEX_INITIALIZER;
static int page_size;
+static int huge_page_size;
static int too_late;
+/*
+ * Get the kernel default huge page size.
+ */
+static int get_huge_page_size()
+{
+ int fd;
+ char buf[MEMINFO_SIZE];
+ int mem_file_len;
+ char *p_hpage_val = NULL;
+ char *end_pointer = NULL;
+ char file_name[] = /proc/meminfo;
+ const char label[] = Hugepagesize:;
+ int ret_val = 0;
+
+ fd = open(file_name, O_RDONLY);
+ if (fd 0)
+ return fd;
+
+ mem_file_len = read(fd, buf, sizeof(buf) - 1);
+
+ close(fd);
+ if (mem_file_len 0)
+ return mem_file_len;
+
+ buf[mem_file_len] = '\0';
+
+ p_hpage_val = strstr(buf, label);
+ if (!p_hpage_val) {
+ errno = EINVAL;
+ return -1;
+ }
+ p_hpage_val += strlen(label);
+
+ errno = 0;
+ ret_val = strtol(p_hpage_val, end_pointer, 0);
+
+ if (errno != 0)
+ return -1;
+
+ return ret_val * 1024;
+}
+
int ibv_fork_init(void)
{
void *tmp;
@@ -85,6 +133,8 @@ int ibv_fork_init(void)
if (page_size 0)
return errno;
+ huge_page_size = get_huge_page_size();
+
if (posix_memalign(tmp, page_size, page_size))
return ENOMEM;
@@ -554,7 +604,8 @@ static struct ibv_mem_node *prepare_to_roll_back(struct
ibv_mem_node *node,
return node;
}
-static int ibv_madvise_range(void *base, size_t size, int advice)
+static int ibv_madvise_range_helper(void *base, size_t size, int advice,
+ int page_size)
{
uintptr_t start, end;
struct ibv_mem_node *node, *tmp;
@@ -646,6 +697,22 @@ out:
return ret;
}
+static int ibv_madvise_range(void *base, size_t size, int advice)
+{
+ int ret_val = 0;
+
+ ret_val = ibv_madvise_range_helper(base, size, advice, page_size);
+
+ /*
+* if memory is backed by huge pages we need to align it
+* to huge page boundary in order madvise() will succeed.
+*/
+ if (ret_val == -1 errno == EINVAL huge_page_size 0)
+ ret_val = ibv_madvise_range_helper(base, size, advice,
huge_page_size);
+
+ return ret_val;
+}
+
int ibv_dontfork_range(void *base, size_t size)
{
if (mm_root)
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] IB/libibvervs: Expose the request for checksum in send flags
Signed-off-by: Aleksey Senin aleks...@voltaire.com
Reviewed-by: Moni Shoua mo...@voltaire.com
--
Index: libibverbs-1.1.3/include/infiniband/verbs.h
===
--- libibverbs-1.1.3.orig/include/infiniband/verbs.h2010-05-27
11:18:31.0 +0300
+++ libibverbs-1.1.3/include/infiniband/verbs.h 2010-06-02 08:59:24.0
+0300
@@ -515,7 +515,8 @@
IBV_SEND_FENCE = 1 0,
IBV_SEND_SIGNALED = 1 1,
IBV_SEND_SOLICITED = 1 2,
- IBV_SEND_INLINE = 1 3
+ IBV_SEND_INLINE = 1 3,
+ IBV_SEND_IP_CSUM= 1 4
};
struct ibv_sge {
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] IB/libmlx4: Add RAW_ETH QP support
Add support for RAW_ETH QP. Also, consider the flag IBV_SEND_IP_CSUM in send
operation.
Signed-off-by: Aleksey Senin aleks...@voltaire.com
Reviewed-by: Moni Shoua mo...@voltaire.com
--
diff --git a/src/qp.c b/src/qp.c
index 4322513..d850b1c 100644
--- a/src/qp.c
+++ b/src/qp.c
@@ -229,6 +229,8 @@ int mlx4_post_send(struct ibv_qp *ibqp, struct ibv_send_wr
*wr,
htonl(MLX4_WQE_CTRL_CQ_UPDATE) : 0) |
(wr-send_flags IBV_SEND_SOLICITED ?
htonl(MLX4_WQE_CTRL_SOLICIT) : 0) |
+ (wr-send_flags IBV_SEND_IP_CSUM ?
+htonl(MLX4_WQE_CTRL_IP_CSUM) : 0) |
qp-sq_signal_bits;
if (wr-opcode == IBV_WR_SEND_WITH_IMM ||
@@ -284,6 +286,10 @@ int mlx4_post_send(struct ibv_qp *ibqp, struct ibv_send_wr
*wr,
size += sizeof (struct mlx4_wqe_datagram_seg) / 16;
break;
+ case IBV_QPT_RAW_ETH:
+ /* For raw eth, the MLX4_WQE_CTRL_SOLICIT flag is used
+* to indicate that no icrc should be calculated */
+ ctrl-xrcrb_flags |= htonl(MLX4_WQE_CTRL_SOLICIT);
default:
break;
}
diff --git a/src/wqe.h b/src/wqe.h
index fa2f8ac..edd3da1 100644
--- a/src/wqe.h
+++ b/src/wqe.h
@@ -41,6 +41,7 @@ enum {
MLX4_WQE_CTRL_FENCE = 1 6,
MLX4_WQE_CTRL_CQ_UPDATE = 3 2,
MLX4_WQE_CTRL_SOLICIT = 1 1,
+ MLX4_WQE_CTRL_IP_CSUM = 3 4,
};
enum {
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] IB/libmlx4: Copy VLAN tag if present to the completion
Identify that VLAN is present in a completion and copy it along with the VLAN
ID to the user completion.
Signed-off-by: Aleksey Senin aleks...@voltaire.com
Reviewed-by: Moni Shoua mo...@voltaire.com
--
--- a/src/cq.c 2010-02-08 17:33:45.0 +0200
+++ b/src/cq.c 2010-02-10 15:12:01.0 +0200
@@ -61,6 +61,10 @@
#define MLX4_CQ_DB_REQ_NOT (2 24)
enum {
+ MLX4_CQE_VLAN_PRESENT_MASK = 1 29,
+};
+
+enum {
MLX4_CQE_OWNER_MASK = 0x80,
MLX4_CQE_IS_SEND_MASK = 0x40,
MLX4_CQE_OPCODE_MASK= 0x1f
@@ -86,8 +90,7 @@
uint32_tmy_qpn;
uint32_timmed_rss_invalid;
uint32_tg_mlpath_rqpn;
- uint8_t sl;
- uint8_t reserved1;
+ uint16_tsl_vid;
uint16_trlid;
uint32_treserved2;
uint32_tbyte_cnt;
@@ -328,12 +331,19 @@
}
wc-slid = ntohs(cqe-rlid);
- wc-sl = cqe-sl 4;
+ wc-sl = ntohs(cqe-sl_vid) 12;
g_mlpath_rqpn = ntohl(cqe-g_mlpath_rqpn);
wc-src_qp = g_mlpath_rqpn 0xff;
wc-dlid_path_bits = (g_mlpath_rqpn 24) 0x7f;
wc-wc_flags |= g_mlpath_rqpn 0x8000 ? IBV_WC_GRH :
0;
- wc-pkey_index = ntohl(cqe-immed_rss_invalid) 0x7f;
+
+ if (qpn MLX4_CQE_VLAN_PRESENT_MASK) {
+ wc-sl = wc-sl 0x0f;
+ wc-pkey_index = ntohs(cqe-sl_vid) 0x0fff;
+ wc-wc_flags |= IBV_WC_WITH_VLAN;
+ }
+ else
+ wc-pkey_index = ntohl(cqe-immed_rss_invalid) 0x7f;
}
return CQ_OK;
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] IB/core: Control number of retries for SA to leave an MCG
Mike Heinz wrote:
Wouldn't the BUSY patch I proposed last year deal with this situation?
Can you please send a link to this patch?
-Original Message-
From: ewg-boun...@lists.openfabrics.org
[mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Moni Shoua
Sent: Wednesday, February 02, 2011 10:10 AM
To: Vlad
Cc: n...@voltaire.com; ewg
Subject: [ewg] [PATCH] IB/core: Control number of retries for SA to leave an
MCG
This patch helps when SM is busy and so an MC group is left joined
while the host bellies that it is was left.
Note: the patch below is not to driver/infiniband/core but it generates
a patch under kernel_patches/fixes.
Index:
ofa_kernel-1.5.3/kernel_patches/fixes/core_0290_sysfs_mcast_leave_retries.patch
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++
ofa_kernel-1.5.3/kernel_patches/fixes/core_0290_sysfs_mcast_leave_retries.patch
2011-02-02 16:52:02.0 +0200
@@ -0,0 +1,46 @@
+Add a multicast leave maximum retry setting in
sys/module/ib_sa/parameters/mcast_leave_retries.
+Add a debug print when the maximum retry count is reached.
+
+Signed-off-by: Nir Muchtar n...@voltaire.com
+Reviewed-by: Moni Shoua mo...@voltaire.com
+--
+
+Index: ofa_kernel-1.5.2/drivers/infiniband/core/multicast.c
+===
+--- ofa_kernel-1.5.2.orig/drivers/infiniband/core/multicast.c 2010-08-17
12:56:06.0 +0300
ofa_kernel-1.5.2/drivers/infiniband/core/multicast.c 2010-08-17
13:15:38.0 +0300
+@@ -40,6 +40,12 @@
+ #include rdma/ib_cache.h
+ #include sa.h
+
++static int mcast_leave_retries = 3;
++
++module_param_call(mcast_leave_retries, param_set_int, param_get_int,
++mcast_leave_retries, 0644);
++MODULE_PARM_DESC(mcast_leave_retries, Number of retries for multicast
leave requests before giving up);
++
+ static void mcast_add_one(struct ib_device *device);
+ static void mcast_remove_one(struct ib_device *device);
+
+@@ -520,8 +526,11 @@
+ if (status (group-retries 0)
+ !send_leave(group, group-leave_state))
+ group-retries--;
+- else
++ else {
++ if (status group-retries = 0)
++ printk(reached max retry count. status=%d .Giving
up\n, status);
+ mcast_work_handler(group-work);
++ }
+ }
+
+ static struct mcast_group *acquire_group(struct mcast_port *port,
+@@ -544,7 +553,7 @@
+ if (!group)
+ return NULL;
+
+- group-retries = 3;
++ group-retries = mcast_leave_retries;
+ group-port = port;
+ group-rec.mgid = *mgid;
+ group-pkey_index = MCAST_INVALID_PKEY_INDEX;
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
This message and any attached documents contain information from QLogic
Corporation or its wholly-owned subsidiaries that may be confidential. If you
are not the intended recipient, you may not read, copy, distribute, or use
this information. If you have received this transmission in error, please
notify the sender immediately by reply e-mail and then delete this message.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] IB/libibverbs: Add vlan present flag to completion flags
Add a new flag that can come with a completion to state a presence of a VLAN
Signed-off-by: Aleksey Senin aleks...@voltaire.com
Reviewed-by: Moni Shoua mo...@voltaire.com
--
--- a/include/infiniband/verbs.h2010-01-19 16:12:06.0 +0200
+++ b/include/infiniband/verbs.h2010-02-10 15:29:17.0 +0200
@@ -272,7 +272,8 @@
enum ibv_wc_flags {
IBV_WC_GRH = 1 0,
- IBV_WC_WITH_IMM = 1 1
+ IBV_WC_WITH_IMM = 1 1,
+ IBV_WC_WITH_VLAN= 1 3
};
struct ibv_wc {
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] IB/core: Control number of retries for SA to leave an MCG
Mike Heinz wrote: It was discussed in the Linux-RDMA list for many months. You can find a list of the archived messages here: http://www.mail-archive.com/search?q=SA+Busyl=linux-r...@vger.kernel.org The most recent version of the patch is here: http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg06644.html Basically, the spec permits an SM to reply busy instead of simply tossing packets on the floor, but OFED does not handle this case right now. I took a look and I'm not sure that your patch solves the issue I was trying to handle. Nothing will prevent from number of retries to reach zero and no one will report the upper layer (e.g IPoIB) that leaving the multicast group had failed. The worst thing is that there is no indication to the user about this state (a host is joined without no one to ever try and make it leave) The patch I sent also puts a message in the kernel log so users can read and react. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] install: do not install open-iscsi with OFED
Overriding the distro open-iscsi RPM is no longer required.
Signed-off-by: Moni Shoua mo...@voltaire.com
---
install.pl | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
--- install.pl.orig 2010-07-08 12:44:27.0 +0300
+++ install.pl 2010-07-08 15:07:23.0 +0300
@@ -452,7 +452,7 @@
included_in_rpm = 0, requires = [core, ipoib], },
'iser' =
{ name = iser, available = 0, selected = 0,
-included_in_rpm = 0, requires = [core, ipoib], ofa_req_inst
= [open-iscsi-generic] },
+included_in_rpm = 0, requires = [core, ipoib], ofa_req_inst
= [] },
'qlgc_vnic' =
{ name = qlgc_vnic, available = 0, selected = 0,
included_in_rpm = 0, requires = [core], },
@@ -1729,9 +1729,6 @@
# if ($kernel =~
m/2.6.9-67|2.6.9-78|2.6.16.[0-9.]*-[0-9.]*-[A-Za-z0-9.]*|el5/) {
if ($kernel =~ m/2.6.3[0-2]|2.6.18-164/) {
$kernel_modules_info{'iser'}{'available'} = 1;
-if ($kernel !~ /el6/) {
-$packages_info{'open-iscsi-generic'}{'available'} = 1;
-}
}
# tgt
@@ -2461,14 +2458,6 @@
}
}
-# Check open-iscsi package if iser module selected for installation
-my $tmp = @selected_modules_by_user;
-$tmp =~ s/ /|/g;
-chomp $tmp;
-if (iser =~ m/$tmp/) {
-check_open_iscsi();
-push (@selected_by_user, open-iscsi-generic);
-}
flock CONFIG, $UNLOCK;
}
close(CONFIG);
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] install: do not install open-iscsi with OFED
Moni, May open-iscsi be removed from OFED now? This is the general idea. However, Or Gerlitz needs some more time to make a final decision. Can we postpone the answer to this until next OFED? Moni ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
Thanks. I accept this remark. We will try to address all the bothering issues regarding the patch set of RAW QP support and resubmit them linux-rdma. Since it won't work with Mellanox the patches will be only for Intel (nes) driver. When time comes and Mellanox cards can be tested for RAQ QO feature they will benefit from the common part. --- Moni Shoua| +972-54-5567934 -Original Message- From: Roland Dreier [mailto:rdre...@cisco.com] Sent: Wednesday, June 23, 2010 8:32 PM To: Moni Shoua Cc: Aleksey Senin; Eli Cohen; e...@openfabrics.org; linux-r...@vger.kernel.org; Tziporet Koren; Yiftah Shahar Subject: Re: [ewg] [PATCH v4] IB Core: RAW ETH support There is no qp type IBV_QPT_RAW_ETY in user space (at least not in the definitions coming with libibverbs). In fact, libibverbs that comes with OFED defines (in verbs.h) a qp type called IBV_QPT_RAW_ETT which equals to 7. The patch that is under discussion here adds a new qp type IB_QPT_RAW_ETH and equals it to 7 to match the definition in user space. This indeed changes the value of IB_QPT_RAW_ETY to 8 but I don't see who can be affected since 1. No user space program that uses IB_QPT_RAW_ETY exists 2. kernel is compiled as one piece of code. Why renumber the _ETY enum? Maybe it doesn't break anything serious but why risk it? -- Roland Dreier rola...@cisco.com || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] New name for IBV_QPT_RAW_ETH
Hi, In yesterday's EWG meeting we agreed that a better name is required instead of IBV_QPT_RAW_ETH. The qp type IBV_QPT_RAW_ETH was introduced lately and it represents a QP that doesn't add headers to the data in post_send operation. Today, this QP is used in applications that want to send Ethernet frames to the wire. However, it is not limited to the Ethernet protocol and one can write an application that sends any type of packet (am I wrong here?) Therefore I can think of the following names IBV_QPT_FRAME IBV_QPT_PACKET IBV_QPT_NOHDR Also, the prefix IBV may be misleading (it's not an IB QP) so this it can be replaced in the above suggestions to RAW. I don't tend to agree to this because I think that all QP types should start with the same prefix. You are all welcome to state your opinion so please do so. thanks Moni S. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
It doesn't even look like this patch and the mlx4 patch were ever posted to linux-rdma. Only to the EWG list. Not 100% correct. See thread from April 30. Patches to core, libibverbs and NES driver were presented there. Granted our dev process may not be documented, but I always assumed the general idea was to get changes accepted upstream, then pull into ofed. OFED is just a mechanism to make top-of-tree linux work on distro kernels. There are some exceptions, but this stuff shouldn't be an exception. We should all follow this upstream first process IMO. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
The patches can't be applies to upstream kernel. An attempt to do this failed about a week or 2 ago. I guess that some of RoCEE patches are still missing in kernel upstream. -Original Message- From: Or Gerlitz Sent: Monday, June 14, 2010 12:15 PM To: Aleksey Senin Cc: Vladimir Sokolovsky; v...@dev.mellanox.co.il; e...@openfabrics.org; e...@mellanox.co.il; Moni Shoua Subject: Re: [ewg] [PATCH v4] IB Core: RAW ETH support Alekseys Senin wrote: This patch adds support to RAW ETH QP in ib core. are these patches applicable to the mainstream kernel code or would only apply/function over ofed? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] RAW_ETH support [PATCH 1/2]
Hi Vlad
Please apply this patch.
Now, when RAW patches that you accepted today are applied, RAW ETH QP support
is broken for NE driver unless this patch is applied.
thanks
Aleksey Senin wrote:
This patch will fix existing NES code to support RAW_ETH instead of RAW_ETY
type.
Signed-off-by: Aleksey Senin aleks...@voltaire.com
---
kernel_patches/fixes/nes_0033_ima.patch | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel_patches/fixes/nes_0033_ima.patch
b/kernel_patches/fixes/nes_0033_ima.patch
index ed21edd..304fe73 100755
--- a/kernel_patches/fixes/nes_0033_ima.patch
+++ b/kernel_patches/fixes/nes_0033_ima.patch
@@ -1,8 +1,8 @@
RDMA/nes: add support of iWARP multicast acceleration over
- IB_QPT_RAW_ETY QP type
+ IB_QPT_RAW_ETH QP type
This patch implements iWarp multicast acceleration (IMA)
-over IB_QPT_RAW_ETY QP type in nes driver.
+over IB_QPT_RAW_ETH QP type in nes driver.
Application creates a raw eth QP (IBV_QPT_RAW_ETH in user-space) and
manages the multicast via ibv_attach_mcast and ibv_detach_mcast calls.
@@ -2301,7 +2301,7 @@ index 098b56f..1801a54 100644
-nes_debug(NES_DBG_QP, Invalid QP type: %d\n,
init_attr-qp_type);
-return ERR_PTR(-EINVAL);
+
-+case IB_QPT_RAW_ETY:
++case IB_QPT_RAW_ETH:
+if (!ibpd-uobject)
+return ERR_PTR(-EINVAL);
+
@@ -2428,7 +2428,7 @@ index 098b56f..1801a54 100644
atomic_inc(sw_qps_destroyed);
nesqp-destroyed = 1;
-+if (nesqp-ibqp.qp_type == IB_QPT_RAW_ETY) {
++if (nesqp-ibqp.qp_type == IB_QPT_RAW_ETH) {
+/* check the QP refernece count */
+if (atomic_read(nesqp-refcount) == 0)
+BUG();
@@ -2558,7 +2558,7 @@ index 098b56f..1801a54 100644
nesqp-hwqp.qp_id, attr-qp_state, nesqp-ibqp_state,
nesqp-iwarp_state, atomic_read(nesqp-refcount));
-+if (ibqp-qp_type == IB_QPT_RAW_ETY)
++if (ibqp-qp_type == IB_QPT_RAW_ETH)
+return 0;
+
spin_lock_irqsave(nesqp-lock, qplockflags);
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] RAW_ETH support [PATCH 1/1]
I think that Eli was referring to the MLX4 specific patches but we'll
send the common and specific patches together once again
-Original Message-
From: Vladimir Sokolovsky [mailto:v...@dev.mellanox.co.il]
Sent: Sunday, June 13, 2010 5:28 PM
To: Aleksey Senin
Cc: Moni Shoua; ewg@lists.openfabrics.org; Eli Cohen; Walukiewicz,
Miroslaw
Subject: Re: [ewg] RAW_ETH support [PATCH 1/1]
Alekseys Senin wrote:
Vlad,
apply this patch. It will add new RAW_ETH enum and used by NES/Intel
driver in their code.
This patch add RAW_ETH QP type to verbs layer.
Signed-off-by: Aleksey Senin aleks...@voltaire.com
---
Hi Aleksey,
I understand from Eli that there are issues with this patch.
So, please send the fixed version.
Regards,
Vladimir
kernel_patches/fixes/core_0560_raw_eth.patch | 63
++
1 files changed, 63 insertions(+), 0 deletions(-) create mode 100644
kernel_patches/fixes/core_0560_raw_eth.patch
diff --git a/kernel_patches/fixes/core_0560_raw_eth.patch
b/kernel_patches/fixes/core_0560_raw_eth.patch
new file mode 100644
index 000..2a8b30f
--- /dev/null
+++ b/kernel_patches/fixes/core_0560_raw_eth.patch
@@ -0,0 +1,63 @@
+ Add new RAW_ETY QP type in order to build RAW Ethernet packets over
+ iWARP and RDMAOE protocols.
+
+
+Signed-off-by: Aleksey Senin aleks...@voltaire.com
+---
+ drivers/infiniband/core/verbs.c | 13 +++--
+ include/rdma/ib_verbs.h |1 +
+ 2 files changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/infiniband/core/verbs.c
+b/drivers/infiniband/core/verbs.c index 881850e..bb4dcd5 100644
+--- a/drivers/infiniband/core/verbs.c
b/drivers/infiniband/core/verbs.c
+@@ -382,6 +382,7 @@ static const struct {
+ [IB_QPT_UD] = (IB_QP_PKEY_INDEX
|
+ IB_QP_PORT
|
+ IB_QP_QKEY),
++[IB_QPT_RAW_ETH] = IB_QP_PORT,
+ [IB_QPT_UC] = (IB_QP_PKEY_INDEX
|
+ IB_QP_PORT
|
+ IB_QP_ACCESS_FLAGS),
+@@ -1004,7 +1005,11 @@ int ib_attach_mcast(struct ib_qp *qp, union
+ib_gid *gid, u16 lid)
+
+ switch (rdma_node_get_transport(qp-device-node_type)) {
+ case RDMA_TRANSPORT_IB:
+-if (gid-raw[0] != 0xff || qp-qp_type != IB_QPT_UD)
++if (qp-qp_type == IB_QPT_RAW_ETH) {
++/* In raw Etherent mgids the 63 msb's should be
0 */
++if (gid-global.subnet_prefix
cpu_to_be64(~1ULL))
++return -EINVAL;
++} else if (gid-raw[0] != 0xff || qp-qp_type !=
IB_QPT_UD)
+ return -EINVAL;
+ break;
+ case RDMA_TRANSPORT_IWARP:
+@@ -1023,7 +1028,11 @@ int ib_detach_mcast(struct ib_qp *qp, union
+ib_gid *gid, u16 lid)
+
+ switch (rdma_node_get_transport(qp-device-node_type)) {
+ case RDMA_TRANSPORT_IB:
+-if (gid-raw[0] != 0xff || qp-qp_type != IB_QPT_UD)
++if (qp-qp_type == IB_QPT_RAW_ETH) {
++/* In raw Etherent mgids the 63 msb's should be
0 */
++if (gid-global.subnet_prefix
cpu_to_be64(~1ULL))
++return -EINVAL;
++} else if (gid-raw[0] != 0xff || qp-qp_type !=
IB_QPT_UD)
+ return -EINVAL;
+ break;
+ case RDMA_TRANSPORT_IWARP:
+diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h index
+3a5a40f..2162253 100644
+--- a/include/rdma/ib_verbs.h
b/include/rdma/ib_verbs.h
+@@ -571,6 +571,7 @@ enum ib_qp_type {
+ IB_QPT_UD,
+ IB_QPT_XRC,
+ IB_QPT_RAW_IPV6,
++IB_QPT_RAW_ETH,
+ IB_QPT_RAW_ETY
+ };
+
+--
+1.6.5.2
+
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] RAW_ETH support [PATCH 0/2]
Aleksey Senin wrote: Those patches add new RAW_ETH QP type to the kernel in order to support creation of RAW Ethernet packets for iWARP and RDMAOE protocols. The reason for new type is that RAW_ETY QP already used by Mellanox drivers for another purpose. Another reason, that there is RAW_ETH QP type already present in userspace, but it mapped to RAW_ETY type in the kernel and cause to confusion when dealing with code. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg Vlad, With Mirek's approval, we I think that nothing prevents from accepting these changes. thanks ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] A request for Sonoma 2010 presentations
Hi, Is there an intension to put them on the web for download? thanks MoniS ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] A request for Sonoma 2010 presentations
That's it Thanks :) -Original Message- From: Rupert Dance [mailto:rsda...@lampreynetworks.com] Sent: Wednesday, March 31, 2010 17:44 To: Moni Shoua; 'Jeffrey Scott' Cc: 'Bill Boas'; 'ewg' Subject: RE: [ewg] A request for Sonoma 2010 presentations Hi Moni, I believe these are the presentations you are after: http://www.openfabrics.org/archives/sonoma2010.htm Rupert -Original Message- From: ewg-boun...@lists.openfabrics.org [mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Moni Shoua Sent: Wednesday, March 31, 2010 10:39 AM To: Jeffrey Scott Cc: Bill Boas; ewg Subject: [ewg] A request for Sonoma 2010 presentations Hi, Is there an intension to put them on the web for download? thanks MoniS ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] rdma_cm: Address change event is not sent underRHEL4.7/8
No, I don't plan any other commits before 1.5.1 GA -Original Message- From: Vladimir Sokolovsky [mailto:v...@dev.mellanox.co.il] Sent: Monday, March 22, 2010 18:48 To: Moni Shoua Cc: ewg Subject: Re: [ewg] [PATCH] rdma_cm: Address change event is not sent underRHEL4.7/8 Moni Shoua wrote: Fix the bug where rdma_cm doesn't send the event RDMA_CM_EVENT_ADDR_CHANG under RHEL4.7 and RHEL4.8. This only needed to copy the backport of RHEL4.6 to the backport directory of RHEL4.7 and RHEL4.8. This commit closes https://bugs.openfabrics.org/show_bug.cgi?id=1998 Signed-off-by: Moni Shoua mo...@voltaire.com --- Applied, Moni, Do you plan to provide more fixes for OFED-1.5.1? I am going to build the final release tomorrow. Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] rdma_cm: Address change event is not sent under RHEL4.7/8
Fix the bug where rdma_cm doesn't send the event RDMA_CM_EVENT_ADDR_CHANG under RHEL4.7 and RHEL4.8. This only needed to copy the backport of RHEL4.6 to the backport directory of RHEL4.7 and RHEL4.8. This commit closes https://bugs.openfabrics.org/show_bug.cgi?id=1998 Signed-off-by: Moni Shoua mo...@voltaire.com --- diff --git a/kernel_patches/backport/2.6.9_U7/cma_to_2_6_23.patch b/kernel_patches/backport/2.6.9_U7/cma_to_2_6_23.patch index 9892b78..82f24b3 100644 --- a/kernel_patches/backport/2.6.9_U7/cma_to_2_6_23.patch +++ b/kernel_patches/backport/2.6.9_U7/cma_to_2_6_23.patch @@ -1,12 +1,12 @@ --- - drivers/infiniband/core/cma.c |3 --- - 1 file changed, 3 deletions(-) + drivers/infiniband/core/cma.c |5 + + 1 file changed, 1 insertion(+), 4 deletions(-) Index: ofed_kernel/drivers/infiniband/core/cma.c === --- ofed_kernel.orig/drivers/infiniband/core/cma.c +++ ofed_kernel/drivers/infiniband/core/cma.c -@@ -2835,9 +2835,6 @@ static int cma_netdev_callback(struct no +@@ -2835,13 +2835,10 @@ static int cma_netdev_callback(struct no struct rdma_id_private *id_priv; int ret = NOTIFY_DONE; @@ -16,3 +16,8 @@ Index: ofed_kernel/drivers/infiniband/core/cma.c if (event != NETDEV_BONDING_FAILOVER) return NOTIFY_DONE; +- if (!(ndev-flags IFF_MASTER) || !(ndev-priv_flags IFF_BONDING)) ++ if (!(ndev-flags IFF_MASTER)) + return NOTIFY_DONE; + + mutex_lock(lock); diff --git a/kernel_patches/backport/2.6.9_U8/cma_to_2_6_23.patch b/kernel_patches/backport/2.6.9_U8/cma_to_2_6_23.patch index 9892b78..82f24b3 100644 --- a/kernel_patches/backport/2.6.9_U8/cma_to_2_6_23.patch +++ b/kernel_patches/backport/2.6.9_U8/cma_to_2_6_23.patch @@ -1,12 +1,12 @@ --- - drivers/infiniband/core/cma.c |3 --- - 1 file changed, 3 deletions(-) + drivers/infiniband/core/cma.c |5 + + 1 file changed, 1 insertion(+), 4 deletions(-) Index: ofed_kernel/drivers/infiniband/core/cma.c === --- ofed_kernel.orig/drivers/infiniband/core/cma.c +++ ofed_kernel/drivers/infiniband/core/cma.c -@@ -2835,9 +2835,6 @@ static int cma_netdev_callback(struct no +@@ -2835,13 +2835,10 @@ static int cma_netdev_callback(struct no struct rdma_id_private *id_priv; int ret = NOTIFY_DONE; @@ -16,3 +16,8 @@ Index: ofed_kernel/drivers/infiniband/core/cma.c if (event != NETDEV_BONDING_FAILOVER) return NOTIFY_DONE; +- if (!(ndev-flags IFF_MASTER) || !(ndev-priv_flags IFF_BONDING)) ++ if (!(ndev-flags IFF_MASTER)) + return NOTIFY_DONE; + + mutex_lock(lock); ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Producing OFED binaries for end users
Hi, The issue of ditributing OFED as a container of bimary packages was raised in the EWG conf. call yesterday. We have some experiecne with it in Voltaire that we would like to share. Today, OFED is distributed as a container of source packages (SRPMS) along with an install script. Container of binary packages looks pretty much the same but instead of SRPMS that require compilation, binary RPMS are packed along with ation, the installation script is much lighter than the one in the source package. Although we wished that the installation script would be as simple as rpm -Uvh *.rpm it is not enough. So what else I we think is required from the installation script to do? 1. Package selection - compile and pack everything and let the user choose which packages should be actually installed. Selection can be to for a group of packages and not single packages to make the script frienlier. 2. Verification - binary RPMS are specific to the OS/ARCH where they were compiled. The installtion script should verify that the target platform is identical to the build platform. For kernel-ib this is essential. 3. Dependencies - not all dependencies are RPM dependencies (i.e. appear in rpm -q --requires). An example for that is open-iscsi that is required for iser. 3. Cleanup - remove (or at least check and warn for) previously installed OFED packages or other conflicting packages (e.g ofed-kmp in SuSE) 4. Dry run - after verification and selection allow user to check if installation would succeed (rpm --test). This is not an essential feature but it sometimes helps. 5. Force install - sometimes, from several reasons, installation succeeds only if the rpm command is run with the flag --force. Allow that. 6. Vendor scrips - Vendor scrips are extensions to the source package installation script. Their purpose is to allow different vendors to customize the installation process as they wish (BTW, is someone else except from Voltaire use this mechanism?). Binary installation should take care of these as well. 7. Configuration - ifcfg-*, modprobe.conf, etc'... This looks like it to me. Comments are welcomed. Regards MoniS ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PARCH 1/3] Allow iser to be compiled under RHEL5.4
Add kernel of RHEL5.4 to the list of supported kernels (nackport patches
were already submitted by Or Gerlitz) and break the dependency between iSER and
iSCSI. However, the script code that builds iSCSI modules and upgrades
open-iscsi userspace RPM is still there in case we need it in the future.
Patches are to the install script and build scripts and were split into three
parts.
Signed-off-by: Moni Shoua mo...@voltaire.com
---
--- install.pl.orig 2010-02-21 11:17:26.0 +0200
+++ install.pl 2010-02-21 13:00:36.0 +0200
@@ -1679,7 +1679,7 @@
# Iser
# if ($kernel =~
m/2.6.9-67|2.6.9-78|2.6.16.[0-9.]*-[0-9.]*-[A-Za-z0-9.]*|el5/) {
-if ($kernel =~ m/2.6.3[0-2]/) {
+if ($kernel =~ m/2.6.3[0-2]|2.6.18-164/) {
$kernel_modules_info{'iser'}{'available'} = 1;
$packages_info{'open-iscsi-generic'}{'available'} = 1;
}
@@ -2769,17 +2769,6 @@
if ( $ans eq 'Y' or $ans eq 'y' ) {
$upgrade_open_iscsi = 1;
}
-else {
-print RED Please uninstall $oiscsi_name before installing
$PACKAGE with iSER support., RESET \n;
-exit 1;
-}
-}
-else {
-if (not $upgrade_open_iscsi) {
-print RED Please uninstall $oiscsi_name before installing
$PACKAGE with iSER support., RESET \n;
-print RED Or put \upgrade_open_iscsi=yes\ in the
$config:, RESET \n;
-exit 1;
-}
}
}
}
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PARCH 3/3] Allow iser to be compiled under RHEL5.4
build and install iser without iscsi modules.
Signed-off-by: Moni Shoua mo...@voltaire.com
---
--- ofa_kernel.spec.orig2010-02-21 14:52:55.0 +0200
+++ ofa_kernel.spec 2010-02-21 14:54:47.0 +0200
@@ -51,6 +51,7 @@
%define build_srp %(if ( echo %{configure_options} | grep with-srp-mod
/dev/null ); then echo -n '1'; else echo -n '0'; fi)
%define build_srpt %(if ( echo %{configure_options} | grep
with-srp-target-mod /dev/null ); then echo -n '1'; else echo -n '0'; fi)
%define build_iser %(if ( echo %{configure_options} | grep with-iser-mod
/dev/null ); then echo -n '1'; else echo -n '0'; fi)
+%define build_oiscsi %(if ( echo %{configure_options} | grep with-iscsi-mod
/dev/null ); then echo -n '1'; else echo -n '0'; fi)
%define build_rds %(if ( echo %{configure_options} | grep with-rds-mod
/dev/null ); then echo -n '1'; else echo -n '0'; fi)
%define build_cxgb3 %(if ( echo %{configure_options} | grep with-cxgb3-mod
/dev/null ); then echo -n '1'; else echo -n '0'; fi)
%define build_nes %(if ( echo %{configure_options} | grep with-nes-mod
/dev/null ); then echo -n '1'; else echo -n '0'; fi)
@@ -485,7 +486,7 @@
if [ -f /etc/SuSE-release ]; then
local_fs='$local_fs'
openiscsi=''
-%if %{build_iser}
+%if %{build_oiscsi}
openiscsi='open-iscsi'
%endif
perl -i -ne if (m...@^#!/bin/bash@) {
@@ -512,7 +513,7 @@
if [ -f /etc/debian_version ]; then
local_fs='$local_fs'
openiscsi=''
-%if %{build_iser}
+%if %{build_oiscsi}
openiscsi='open-iscsi'
%endif
perl -i -ne if (m...@^#!/bin/bash@) {
@@ -751,6 +752,8 @@
%endif
%if %{build_iser}
%{LIB_MOD_DIR_INF}/ulp/iser
+%endif
+%if %{build_oiscsi}
%{LIB_MOD_DIR_SCSI}/iscsi_tcp.ko
%{LIB_MOD_DIR_SCSI}/libiscsi.ko
%{LIB_MOD_DIR_SCSI}/scsi_transport_iscsi.ko
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH install] Parse new option in ofed.conf
Add parsing of option bonding_force_all_os and passing
it to rpmbuild when building ib-bonding. The meaning of this new
option is: build ib-bonding for any OS and override the judgment
in the spec file.
Signed-off-by: Moni Shoua mo...@voltaire.com
---
--- install.pl.orig 2010-02-16 18:41:59.0 +0200
+++ install.pl 2010-02-17 14:46:50.0 +0200
@@ -63,6 +63,7 @@
my $clear_string = `clear`;
my $upgrade_open_iscsi = 0;
+my $bonding_force_all_os = 0;
my $vendor_pre_install = ;
my $vendor_post_install = ;
@@ -2207,6 +2208,13 @@
next;
}
+if ($package eq bonding_force_all_os) {
+if ($selected =~ m/[Yy]|[Yy][Ee][Ss]/) {
+$bonding_force_all_os = 1;
+}
+next;
+}
+
if (substr($package,0,length(vendor_config)) eq
vendor_config) {
next;
}
@@ -2835,6 +2843,7 @@
elsif ($name eq 'ib-bonding') {
$cmd .= --define 'KVERSION $kernel';
$cmd .= --define '_release $kernel_rel';
+$cmd .= --define 'force_all_os $bonding_force_all_os';
}
$cmd .= --define '_prefix $prefix';
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [ANNOUNCE] ib-bonding release 42 is available
Hi, I've put the SRPM in the public folder in my account and it should be available in the next OFED build The only change in this version is a fix for bugzilla 1915 (https://bugs.openfabrics.org/show_bug.cgi?id=1915) To avoid an unneeded compilation under RHEL5.4 I added an option in ofed.conf to force building for that OS. However, if the bug doesn't concern you, prefer to use the native bonding module that comes with the OS. A patch to ofed-docs will be sent to cover the above. thanks ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] EWG/OFED meeting agenda for today (Jan 11, 2010)
Brian J. Murrell wrote: On Mon, 2010-01-11 at 18:26 +0200, Tziporet Koren wrote: This is the agenda for the meeting today: 1. OFED 1.5.1 status: ... Other changes that should be done: ... - Other - let discuss in the meeting today How about the ISER/iSCSI on kernels 2.6.30 situation? We'll probably release a backport for RHEL5.4 and SLES11 in OFED-1.5.1 If RHEL5.5 is out by than, it will be probably supported. I'll send patches soon I'm not sure I can make the call, but regardless, it would be nice to have it discussed and a status included in the meeting minutes. b. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [ANNOUNCE] OFED 1.5 rc4 release is available
Limitations: - SLES10 SP3 on IA64 is not supported yet In what way is it unsupported? Our QA say that OFED-1.5 can be compiled on this platform. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [Annonce] OFED-RDMAoE-1.5-rc4 is available
Notes: RDMAoE and mlx4_en capabilities are supported only for x86 and x86_64 architectures. Since Voltaire is testing and distributing the RDMAoE release and we wish to take care of a single package, I'd like to better understand this. If OFED-RDMAoE is compiled on non x86_64 and used without loading mlx4_en do you see any problem with that? thanks ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] ofed_scripts: Do not remove slaves before stopping stack
There is no need to unenslave IPoIB interfaces before stopping the stack. This can cause a kernel crash as described in https://bugs.openfabrics.org/show_bug.cgi?id=1821 Signed-off-by: Moni Shoua mo...@voltaire.com --- diff --git a/ofed_scripts/openibd b/ofed_scripts/openibd index 8b0c3e6..2e5efee 100755 --- a/ofed_scripts/openibd +++ b/ofed_scripts/openibd @@ -1272,11 +1272,6 @@ stop() fi fi -# Down all bond interfaces - if ( which ib-bond /dev/null ) ; then - ib-bond --stop-all - fi - # Stop SRP HA daemon if running if [ -f $srp_daemon_pidfile ]; then local line p ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] docs: Update to the comment of ib-bonding OS scope.
Give a better explanation to the ib-bonding OS scope Signed-off-by: Moni Shoua mo...@voltaire.com --- diff --git a/ipoib_release_notes.txt b/ipoib_release_notes.txt index f60ca7c..2d1217a 100644 --- a/ipoib_release_notes.txt +++ b/ipoib_release_notes.txt @@ -272,10 +272,13 @@ Notes: no longer supported * On RHEL4_U7, cannot set a slave interface as primary. * ib-bonding will not be compiled and installed with OFED on OS with kernel - that is = 2.6.27. The bonding driver that comes with those kernels already - supports enslaving of IPoIB interfaces. However, there still might be a issue - of OS configuration tools (like sysconfig or initscripts) that needs a fix - but such issues were not observed yet. + that is = 2.6.27 (e.g. SLES11). The bonding driver that comes with those kernels + already supports enslaving of IPoIB interfaces. In addition, an OS can come + with an older kernel but with a patched bonding driver that also doesn't + require modification (e.g. RHEL5.4). OFEED will not replace the bonding + module in such cases also. + However, there still might be a issue of OS configuration tools (like sysconfig or + initscripts) that needs a fix but such issues were not observed yet. === ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] EWG/OFED agenda for today (Nov 09, 2009)
Is there going to be a meeting tomorrow? ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Agenda for EWG/OFED meeting on next Monday
Voltaire intends to test with OFED-RDMAoE release. The following setup are used in our QA while each setup consists of 2 machines. Arch|OS / Kernel | HCA|SM +-+--+--- x86_64 | RH4 up6 *| ConnectX QDR | OpenSM x86_64 | RH4 up7 | ConnectX DDR | VoltaireSM x86_64 | RH4 up8 | ConnectX QDR | OpenSM x86_64 | RH5 up2 | ConnectX DDR | VoltaireSM x86_64 | RH5 up3 | ConnectX QDR | OpenSM x86_64 | RH5 up4 | ConnectX DDR gen2| VoltaireSM x86_64 | SLES10 sp2 | Arbel mem free | VoltaireSM x86_64 | SLES10 sp3 | ConnectX QDR | OpenSM x86_64 | SLES11 | ConnectX DDR | VoltaireSM x86_64 | Centos5.3| ConnectX QDR | OpenSM ppc | SLES10 sp3 | ConnectX DDR | VoltaireSM ppc | RH5 up4 | ConnectX DDR | VoltaireSM i386| SLES11 | ConnectX DDR | VoltaireSM i386| RH5 up4 | ConnectX DDR | VoltaireSM ia64| SLES10 sp3 | ConnectX DDR | VoltaireSM ia64| RH4 up8 | ConnectX DDR | VoltaireSM * With kernel 2.6.30 We will perform all our tests with the latest available HCA firmware. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] kernel_fixes: import from upstream to fix bugzilla 1726
Import commit 5ee95120841fd623c48d7d971182cf58e3b0c8de from Roland's tree to
fix bugzilla 1726
Signed-off-by: Moni Shoua mo...@voltaire.com
---
kernel_patches/fixes/ipoib_0570_check_state_before_carrier.patch | 43
++
1 file changed, 43 insertions(+)
diff --git a/kernel_patches/fixes/ipoib_0570_check_state_before_carrier.patch
b/kernel_patches/fixes/ipoib_0570_check_state_before_carrier.patch
new file mode 100644
index 000..5c82c02
--- /dev/null
+++ b/kernel_patches/fixes/ipoib_0570_check_state_before_carrier.patch
@@ -0,0 +1,43 @@
+IPoIB: Don't turn on carrier for a non-active port
+
+Multicast joins can succeed even if the IB port is down. This happens
+when the SM runs on the same port with the requesting port. However,
+IPoIB calls netif_carrier_on() when the join of the broadcast group
+succeeds, without caring about the state of the IB port. The result
+is an IPoIB interface in RUNNING state but without an active IB port
+to support it.
+
+If a bonding interface uses this IPoIB interface as a slave it might
+not detect that this slave is almost useless and failover
+functionality will be damaged. The fix checks the state of the IB
+port in the carrier_task before calling netif_carrier_on().
+
+Adresses: https://bugs.openfabrics.org/show_bug.cgi?id=1726
+Signed-off-by: Moni Shoua mo...@voltaire.com
+Signed-off-by: Roland Dreier rola...@cisco.com
+---
+
+diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+index 25874fc..8763c1e 100644
+--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+@@ -362,12 +362,19 @@ void ipoib_mcast_carrier_on_task(struct work_struct
*work)
+ {
+ struct ipoib_dev_priv *priv = container_of(work, struct ipoib_dev_priv,
+ carrier_on_task);
++ struct ib_port_attr attr;
+
+ /*
+* Take rtnl_lock to avoid racing with ipoib_stop() and
+* turning the carrier back on while a device is being
+* removed.
+*/
++ if (ib_query_port(priv-ca, priv-port, attr) ||
++ attr.state != IB_PORT_ACTIVE) {
++ ipoib_dbg(priv, Keeping carrier off until IB port is
active\n);
++ return;
++ }
++
+ rtnl_lock();
+ netif_carrier_on(priv-dev);
+ rtnl_unlock();
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] ofed_scripts/openibd: Don't check for gcc version unless it is installed
If gcc is not installed then don't check for gcc version. This prevents error messages to be printed on the screen. Signed-off-by: Moni Shoua mo...@voltaire.com --- openibd |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ofed_scripts/openibd b/ofed_scripts/openibd index 1b88163..8b0c3e6 100755 --- a/ofed_scripts/openibd +++ b/ofed_scripts/openibd @@ -410,7 +410,7 @@ get_debug_info() test -e /etc/issue echo OS: `cat /etc/issue` $DEBUG_INFO echo Current kernel: `uname -r` $DEBUG_INFO echo Architecture: `uname -m` $DEBUG_INFO -echo GCC version: `gcc --version` $DEBUG_INFO +which gcc /dev/null echo GCC version: `gcc --version` $DEBUG_INFO echo CPU: `cat /proc/cpuinfo | /bin/grep -E \model name|arch\ | head -1` $DEBUG_INFO echo `cat /proc/meminfo | /bin/grep \MemTotal\` $DEBUG_INFO echo Chipset: `/sbin/lspci 2 /dev/null | head -1 | cut -d ':' -f 2-` $DEBUG_INFO ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] ofed-docs: A cooment about ib-bonding and newer kernels
Add comment for ib-bonding and distros that use new kernels (i.e. SLES11) Signed-off-by: Moni Shoua mo...@voltaire.com --- ipoib_release_notes.txt |5 + 1 file changed, 5 insertions(+) diff --git a/ipoib_release_notes.txt b/ipoib_release_notes.txt index adf1304..3c3d70f 100644 --- a/ipoib_release_notes.txt +++ b/ipoib_release_notes.txt @@ -271,6 +271,11 @@ Notes: * Using /etc/infiniband/openib.conf to create a persistent configuration is no longer supported * On RHEL4_U7, cannot set a slave interface as primary. +* ib-bonding will not be compiled and installed with OFED on OS with kernel + that is = 2.6.27. The bonding driver that comes with those kernels already + supports enslaving of IPoIB interfaces. However, there still might be a issue + of OS configuration tools (like sysconfig or initscripts) that needs a fix but + such issues were not observed yet. === ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] kernel_fixes: import a patch to fix bugzilla 1664
Add commit 5e47596bee12597824a3b5b21e20f80b61e58a35 to kernel fixes.
This will fix https://bugs.openfabrics.org/show_bug.cgi?id=1664.
Signed-off-by: Moni Shoua mo...@voltaire.com
---
kernel_patches/fixes/ipoib_0550_check_multicast_address_format.patch | 51
++
1 file changed, 51 insertions(+)
diff --git
a/kernel_patches/fixes/ipoib_0550_check_multicast_address_format.patch
b/kernel_patches/fixes/ipoib_0550_check_multicast_address_format.patch
new file mode 100644
index 000..a98e591
--- /dev/null
+++ b/kernel_patches/fixes/ipoib_0550_check_multicast_address_format.patch
@@ -0,0 +1,51 @@
+commit 5e47596bee12597824a3b5b21e20f80b61e58a35
+Author: Jason Gunthorpe jguntho...@obsidianresearch.com
+Date: Sat Sep 5 20:23:40 2009 -0700
+
+IPoIB: Check multicast address format
+
+Check that the format of multicast link addresses is correct before
+taking them from dev-mc_list to priv-multicast_list. This way we
+never try to send a bogus address to the SA, which prevents badness
+from erronous 'ip maddr addr add', broken bonding drivers, etc.
+
+Signed-off-by: Jason Gunthorpe jguntho...@obsidianresearch.com
+Signed-off-by: Roland Dreier rola...@cisco.com
+
+diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+index a0825fe..25874fc 100644
+--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+@@ -760,6 +760,20 @@ void ipoib_mcast_dev_flush(struct net_device *dev)
+ }
+ }
+
++static int ipoib_mcast_addr_is_valid(const u8 *addr, unsigned int addrlen,
++ const u8 *broadcast)
++{
++ if (addrlen != INFINIBAND_ALEN)
++ return 0;
++ /* reserved QPN, prefix, scope */
++ if (memcmp(addr, broadcast, 6))
++ return 0;
++ /* signature lower, pkey */
++ if (memcmp(addr + 7, broadcast + 7, 3))
++ return 0;
++ return 1;
++}
++
+ void ipoib_mcast_restart_task(struct work_struct *work)
+ {
+ struct ipoib_dev_priv *priv =
+@@ -793,6 +807,11 @@ void ipoib_mcast_restart_task(struct work_struct *work)
+ for (mclist = dev-mc_list; mclist; mclist = mclist-next) {
+ union ib_gid mgid;
+
++ if (!ipoib_mcast_addr_is_valid(mclist-dmi_addr,
++ mclist-dmi_addrlen,
++ dev-broadcast))
++ continue;
++
+ memcpy(mgid.raw, mclist-dmi_addr + 4, sizeof mgid);
+
+ mcast = __ipoib_mcast_find(dev, mgid);
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: Please update RN for OFED 1.4.1
Hi Tziporet, This is a patch for bonding doc thanks diff --git a/ib-bonding.txt b/ib-bonding.txt index c797cde..c6266f4 100644 --- a/ib-bonding.txt +++ b/ib-bonding.txt @@ -15,6 +15,8 @@ IB Bonding --- ib-bonding is a High Availability solution for IPoIB interfaces. It is based on the Linux Ethernet Bonding Driver and was adopted to work with IPoIB. +However, the support for for IPoIB interfaces is only for the active-backup +mode, other modes should not be used. ib-bonding package contains a bonding driver and a utility called ib-bond to manage and control the driver operation. @@ -70,6 +72,7 @@ Update 6 or Update 7) and for Redhat-EL5 and above. - * In the master (bond) interface script add the line: TYPE=Bonding +MTU=according to the slave's MTU Exmaple: for bond0 (master) the file is named /etc/sysconfig/network-scripts/ifcfg-bond0 with the following text in the file: @@ -83,11 +86,19 @@ ONBOOT=yes BOOTPROTO=none USERCTL=no TYPE=Bonding +MTU=65520 + +Note: 65520 is a valid mtu value only if all IPoIB slaves operate in connected +mode and are configured with the same value. For IPoIB slaves that work in +datagram modee, use MTU=2044. If you don't set correct mtu or don't set mtu at +all (and letting it to be set to the default value), performance of the +interface might decrease. * In the slave (ib) interface script put the following lines: SLAVE=yes MASTER=bond name TYPE=InfiniBand +PRIMARY=yes|no Example: the script for ib0 (slave) would be named /etc/sysconfig/network-scripts/ifcfg-ib0 with the following text in the file: @@ -99,6 +110,10 @@ MASTER=bond0 SLAVE=yes BOOTPROTO=none TYPE=InfiniBand +PRIMARY=yes + +Note: If the slave interface is not primary then the line PRIMARY= is not +required and can be omitted. After the configuration is saved, restart the network service by running: /etc/init.d/network restart @@ -108,6 +123,9 @@ After the configuration is saved, restart the network service by running: Follow the instructions in 3.1.1 (Writing network scripts under Redhat-AS4) with the following changes: * In the bondX (master) script - the line TYPE=Bonding is not needed. +* In the bondX (master) script - you may add to the configuration more options +with the following line +BONDING_OPTS= primary=ib0 updelay=0 downdelay=0 * in the ibX (slave) script - the line TYPE=InfiniBand necessary when using bonding over devices configured with partitions ( p_key) Example: @@ -137,6 +155,7 @@ BONDING_MASTER=yes BONDING_MODULE_OPTS=mode=active-backup miimon=value BONDING_SLAVE0=slave0 BONDING_SLAVE1=slave1 +MTU=according to the slave's MTU Exmaple: for bond0 (master) the file is named /etc/sysconfig/network/ifcfg-bond0 with the following text in the file: @@ -149,9 +168,20 @@ NETWORK=10.0.2.0 REMOTE_IPADDR= STARTMODE=onboot BONDING_MASTER=yes -BONDING_MODULE_OPTS=mode=active-backup miimon=100 +BONDING_MODULE_OPTS=mode=active-backup miimon=100 primary=ib0 updelay=0 downdelay=0 BONDING_SLAVE0=ib0 BONDING_SLAVE1=ib1 +MTU=65520 + +Note: 65520 is a valid mtu value only if all IPoIB slaves operate in connected +mode and are configured with the same value. For IPoIB slaves that work in +datagram modee, use MTU=2044. If you don't set correct mtu or don't set mtu at +all (and letting it to be set to the default value), performance of the +interface might decrease. + +Note: primary, downdelay and updelay is an optional bonding interface +configuration. You may choose to use them, change them or delete them from the +configuration script (by editing the line that starts with BONDING_OPTS) * The slave (ib) interace script should look like this: @@ -167,18 +197,36 @@ After the configuration is saved, restart the network service by running: It is not possible to have a mix of Ethernt slaves and IPoIB slaves under the same bonding master. It is possible however that a bonding master of Ethernet slaves and a bonding master of IPoIB slaves will co-exist in one machne. -To configure Ethernet slaves under a bonding master use the same instructions -as for IPoIB slaves (according to the OS) with one exception. When working -under Redhat-AS4 do the following when configuring a bonding master with -Ethernet slaves +To configure Ethernet slaves under a bonding master use the following +instructios (depending on the OS) + +* Under Redhat-AS4 + +Use the same instructions as for IPoIB slaves with the following exceptions - In the master configuration file add the line SLAVEDEV=1 - In the slave configuration file leave the line TYPE=InfiniBand +- For Ethernet, it is possible to set parameters of the bonding module in /etc/modprobe.conf +with the following line for example +options bonding miimon=100 mode=1 primary=eth0 +Note that alias names for the bonding module (such as bond0) may not work. + +* Under Redhat-AS5 +
[ewg] Dependency of openmpi in mpi-selector. Is it necessary?
Hi, In spec file of openmpi there is a boolean option called ofed. When it is true, among other things, it makes openmpi to depend on mpi-selector. Why not leave it to the user to decide whether to use (and install) mpi-selector or not. This can also create a conflict between mpi-selector that comes with ofed and the one that is already installed. What do you think? MoniS ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ofa-general] Re: [ewg] Re: [PATCH] IB/ipoib: set neigh-dgid upon ipoib_neigh creation
Eli Cohen wrote:
On Wed, Mar 25, 2009 at 09:20:19PM +0200, Yossi Etigin wrote:
Wouldn't this patch break the fast bond+SM failover recovery?
Up till now, in such case neigh-dgid was the old gid until path record
query was successful, and that caused to retry the path query until it's
successful. With that patch, a new path query will not be issued until
the next arp refresh because neigh-dgid will be set to a valid value
right after the first packet.
Looks to me like
How about keeping the memcpy in path_rec-completion, and also adding it
to ib_mcast_send (where ipoib neigh is created)?
I did not like the idea that a unicast ipoib_neigh can be created and
destroyed till the path is resolved so I preferred to initialize at
creation time. How about the following patch to solve the problem of
failure to resolve a path:
From 4e6e3dd0186803f7547f5e4c233d7525dfcdaec6 Mon Sep 17 00:00:00 2001
From: Eli Cohen e...@mellanox.co.il
Date: Wed, 25 Mar 2009 16:22:28 +0200
Subject: [PATCH] IB/ipoib: set neigh-dgid upon ipoib_neigh creation
If we fail to do that, there can be superfluous calls to
ipoib_neigh_free()/ipoib_neigh_alloc() due to the following if statement in
ipoib_start_xmit():
if (unlikely((memcmp(neigh-dgid.raw,
skb-dst-neighbour-ha + 4,
sizeof(union ib_gid))) ||
In the case of a unicast GID, it can happen until the path is resolved and is
not so severe. In the case of a multicast address, neigh-dgid is never even
updated, so the corresponding ipoib_neigh will be destroyed and created on
every multicast packet sent.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/ulp/ipoib/ipoib_main.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 0bd2a4f..b680483 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -460,8 +460,6 @@ static void path_rec_completion(int status,
}
kref_get(path-ah-ref);
neigh-ah = path-ah;
- memcpy(neigh-dgid.raw, path-pathrec.dgid.raw,
-sizeof(union ib_gid));
if (ipoib_cm_enabled(dev, neigh-neighbour)) {
if (!ipoib_cm_get(neigh))
@@ -481,7 +479,9 @@ static void path_rec_completion(int status,
__skb_queue_tail(skqueue, skb);
}
path-valid = 1;
- }
+ } else
+ list_for_each_entry_safe(neigh, tn, path-neigh_list, list)
+ memset(neigh-dgid, 0, sizeof neigh-dgid);
path-query = NULL;
complete(path-done);
@@ -878,6 +878,7 @@ struct ipoib_neigh *ipoib_neigh_alloc(struct neighbour
*neighbour,
neigh-neighbour = neighbour;
neigh-dev = dev;
*to_ipoib_neigh(neighbour) = neigh;
+ memcpy(neigh-dgid.raw, neighbour-ha + 4, 16);
skb_queue_head_init(neigh-queue);
ipoib_cm_set(neigh, NULL);
This might work but still, I don't understand what this patch fixes. What was
the initial problem?
I agree with Yossi's early comments that the patch breaks the fast fail over
we've worked on in the past.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] OFED-1.4.1 daily: build error in ib-bonding
Alexander Schmidt wrote: Hi all, with the latest daily build (OFED-1.4.1-20090305-0600), I run into a build problem with ib-bonding, running on SLES10 SP2 on powerpc. The last daily build I tested (OFED-1.4-20090208-0600) worked fine, it contained ib-bonding-0.9.0-36 (new version is ib-bonding-0.9.0-38). Is anyone else seeing this? Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.4571 + umask 022 + cd /var/tmp/OFED_topdir/BUILD + /bin/rm -rf /var/tmp/ib-bonding-0.9.0-root ++ dirname /var/tmp/ib-bonding-0.9.0-root + /bin/mkdir -p /var/tmp + /bin/mkdir /var/tmp/ib-bonding-0.9.0-root + cd ib-bonding-0.9.0 + cd linux/drivers/net/bonding/ ++ pwd + make -C /lib/modules/2.6.16.60-0.14-ppc64/build modules M=/var/tmp/OFED_topdir/BUILD/ib-bonding-0.9.0/linux/drivers/net/bonding make: Entering directory `/usr/src/linux-2.6.16.60-0.14' WARNING: Symbol version dump /usr/src/linux-2.6.16.60-0.14/Module.symvers is missing; modules will have no dependencies and modversions. It seems to me that you are running a beta (rcN) of SLES10 SP2. Your kernel is 2.6.16.60-0.14-ppc64 while it should be 2.6.16.60-0.21-ppc64 You can see this in file /etc/issue ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] rdma_cm: Fix bugzilla 726 - rdma_bind_addr() fails on ib aliases (eg ib0:0) under Redhat 4
This fix is not to rdma_cm but to its backport.
The approach I took to solve the problem is as in suggestion #1 in the bug
report - use the same xxx_ip_dev_find() as the one used in 1.1
Besides RHEL4, I applied the fix to SLES10 as well.
There is no need to fix for RHEL5.
Other backports were not checked.
Reported-by: Philippe Bernadat philippe.berna...@hp.com
Debugged-by: Philippe Bernadat philippe.berna...@hp.com
Signed-off-by: Moni Shoua mo...@voltaire.com
---
kernel_addons/backport/2.6.16_sles10/include/linux/inetdevice.h | 22
++
kernel_addons/backport/2.6.16_sles10_sp1/include/linux/inetdevice.h | 22
++
kernel_addons/backport/2.6.16_sles10_sp2/include/linux/inetdevice.h | 22
++
kernel_addons/backport/2.6.9_U4/include/linux/inetdevice.h | 22
++
kernel_addons/backport/2.6.9_U5/include/linux/inetdevice.h | 22
++
kernel_addons/backport/2.6.9_U6/include/linux/inetdevice.h | 22
++
kernel_addons/backport/2.6.9_U7/include/linux/inetdevice.h | 22
++
7 files changed, 105 insertions(+), 49 deletions(-)
diff --git a/kernel_addons/backport/2.6.16_sles10/include/linux/inetdevice.h
b/kernel_addons/backport/2.6.16_sles10/include/linux/inetdevice.h
index 4ef1826..c2fefbc 100644
--- a/kernel_addons/backport/2.6.16_sles10/include/linux/inetdevice.h
+++ b/kernel_addons/backport/2.6.16_sles10/include/linux/inetdevice.h
@@ -7,16 +7,24 @@
static inline struct net_device *xxx_ip_dev_find(u32 addr)
{
struct net_device *dev;
- u32 ip;
+ struct in_ifaddr **ifap;
+ struct in_ifaddr *ifa;
+ struct in_device *in_dev;
read_lock(dev_base_lock);
- for (dev = dev_base; dev; dev = dev-next) {
- ip = inet_select_addr(dev, 0, RT_SCOPE_HOST);
- if (ip == addr) {
- dev_hold(dev);
- break;
+ for (dev = dev_base; dev; dev = dev-next)
+ if ((in_dev = in_dev_get(dev))) {
+ for (ifap = in_dev-ifa_list; (ifa = *ifap);
+ifap = ifa-ifa_next) {
+ if (addr == ifa-ifa_address) {
+ dev_hold(dev);
+ in_dev_put(in_dev);
+ goto found;
+ }
+ }
+ in_dev_put(in_dev);
}
- }
+found:
read_unlock(dev_base_lock);
return dev;
diff --git
a/kernel_addons/backport/2.6.16_sles10_sp1/include/linux/inetdevice.h
b/kernel_addons/backport/2.6.16_sles10_sp1/include/linux/inetdevice.h
index 4ef1826..c2fefbc 100644
--- a/kernel_addons/backport/2.6.16_sles10_sp1/include/linux/inetdevice.h
+++ b/kernel_addons/backport/2.6.16_sles10_sp1/include/linux/inetdevice.h
@@ -7,16 +7,24 @@
static inline struct net_device *xxx_ip_dev_find(u32 addr)
{
struct net_device *dev;
- u32 ip;
+ struct in_ifaddr **ifap;
+ struct in_ifaddr *ifa;
+ struct in_device *in_dev;
read_lock(dev_base_lock);
- for (dev = dev_base; dev; dev = dev-next) {
- ip = inet_select_addr(dev, 0, RT_SCOPE_HOST);
- if (ip == addr) {
- dev_hold(dev);
- break;
+ for (dev = dev_base; dev; dev = dev-next)
+ if ((in_dev = in_dev_get(dev))) {
+ for (ifap = in_dev-ifa_list; (ifa = *ifap);
+ifap = ifa-ifa_next) {
+ if (addr == ifa-ifa_address) {
+ dev_hold(dev);
+ in_dev_put(in_dev);
+ goto found;
+ }
+ }
+ in_dev_put(in_dev);
}
- }
+found:
read_unlock(dev_base_lock);
return dev;
diff --git
a/kernel_addons/backport/2.6.16_sles10_sp2/include/linux/inetdevice.h
b/kernel_addons/backport/2.6.16_sles10_sp2/include/linux/inetdevice.h
index 4ef1826..c2fefbc 100644
--- a/kernel_addons/backport/2.6.16_sles10_sp2/include/linux/inetdevice.h
+++ b/kernel_addons/backport/2.6.16_sles10_sp2/include/linux/inetdevice.h
@@ -7,16 +7,24 @@
static inline struct net_device *xxx_ip_dev_find(u32 addr)
{
struct net_device *dev;
- u32 ip;
+ struct in_ifaddr **ifap;
+ struct in_ifaddr *ifa;
+ struct in_device *in_dev;
read_lock(dev_base_lock);
- for (dev = dev_base; dev; dev = dev-next) {
- ip = inet_select_addr(dev, 0, RT_SCOPE_HOST);
- if (ip == addr) {
- dev_hold(dev);
- break;
+ for (dev = dev_base; dev; dev = dev-next)
+ if ((in_dev = in_dev_get(dev))) {
+ for (ifap = in_dev
[ewg] [Fwd: Re: [ofa-general] [PATCH] ipoib: Fix loss of connectivity after bonding failover on both sides]
Hi
The patch below in it's previous version appears in OFED-1.4_3 and since.
( kernel_patches/fixes/ipoib_0480_fix_loss_of_connectivity_after_failover.patch
)
Could you please take care to replace it with the new one in next OFED?
thanks
Original Message
Subject: Re: [ofa-general] [PATCH] ipoib: Fix loss of connectivity after
bonding failover on both sides
Date: Tue, 18 Nov 2008 13:34:45 +0200
From: Moni Shoua [EMAIL PROTECTED]
To: Yossi Etigin [EMAIL PROTECTED], Roland Dreier [EMAIL PROTECTED]
CC: Olga Shern [EMAIL PROTECTED], general list [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
The patch assumes that the path query succeeds and therefore copies the HA from
the kernel neighbor structure to ipoib_neigh after path query is sent. If path
query fails (e.g.
request timeout) the next won't be triggered by finding that HA was updated in
ipoib_strart_xmit().
This leads to a longer time that the destination node remains unaccessible.
The patch below is identical to Yossi's patch but without the copy of HA in
neigh_add_path.
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index fddded7..ec433bf 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -709,26 +709,26 @@ static int ipoib_start_xmit(struct sk_buff *skb, struct
net_device *dev)
neigh = *to_ipoib_neigh(skb-dst-neighbour);
- if (neigh-ah)
- if (unlikely((memcmp(neigh-dgid.raw,
- skb-dst-neighbour-ha + 4,
- sizeof(union ib_gid))) ||
-(neigh-dev != dev))) {
- spin_lock_irqsave(priv-lock, flags);
- /*
-* It's safe to call ipoib_put_ah() inside
-* priv-lock here, because we know that
-* path-ah will always hold one more reference,
-* so ipoib_put_ah() will never do more than
-* decrement the ref count.
-*/
+ if (unlikely((memcmp(neigh-dgid.raw,
+ skb-dst-neighbour-ha + 4,
+ sizeof(union ib_gid))) ||
+ (neigh-dev != dev))) {
+ spin_lock_irqsave(priv-lock, flags);
+ /*
+* It's safe to call ipoib_put_ah() inside
+* priv-lock here, because we know that
+* path-ah will always hold one more reference,
+* so ipoib_put_ah() will never do more than
+* decrement the ref count.
+*/
+ if (neigh-ah)
ipoib_put_ah(neigh-ah);
- list_del(neigh-list);
- ipoib_neigh_free(dev, neigh);
- spin_unlock_irqrestore(priv-lock, flags);
- ipoib_path_lookup(skb, dev);
- return NETDEV_TX_OK;
- }
+ list_del(neigh-list);
+ ipoib_neigh_free(dev, neigh);
+ spin_unlock_irqrestore(priv-lock, flags);
+ ipoib_path_lookup(skb, dev);
+ return NETDEV_TX_OK;
+ }
if (ipoib_cm_get(neigh)) {
if (ipoib_cm_up(neigh)) {
___
general mailing list
[EMAIL PROTECTED]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [Fwd: Re: [ofa-general] [PATCH] ipoib: Fix loss of connectivity after bonding failover on both sides]
Hi Moni, Let's give people some time for review. Sure. Did you checked that replacing the patch in OFED will not require backport patches update? Yes. The change doesn't require any change in backports If not, please check and update backports if required. Regards, Vladimir Thanks ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [ANNOUNCE] ib-bonding release 32
Hi, I released a new version today. The only change is setting the default number of grar. ARP to send after failover to three. This change is an outcome of bug 1335 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Release 31 of ib-bonding
This one is already in my directory and should be in next OFED. Change Log == Fix bug 1250 Fix bug 1230 thanks MoniS ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ofa-general] ***SPAM*** Re: [ewg] Re: Continue of defer skb_orphan() until irqs enabled
Vladimir Sokolovsky wrote: Olga Shern (Voltaire) wrote: Hi Eli, We also want to run regression tests with this patch. Please let me know when OFED daily build will include it. Thanks Olga Hi Olga, OFED-1.4-20080928-0756.tgz includes this patch. Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg Which commit is it in OFED tree? ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ofa-general] ***SPAM*** Re: [ewg] Re: Continue of defer skb_orphan() until irqs enabled
Vladimir Sokolovsky wrote: On Sun, 2008-09-28 at 18:09 +0300, Moni Shoua wrote: Vladimir Sokolovsky wrote: Olga Shern (Voltaire) wrote: Hi Eli, We also want to run regression tests with this patch. Please let me know when OFED daily build will include it. Thanks Olga Hi Olga, OFED-1.4-20080928-0756.tgz includes this patch. Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg Which commit is it in OFED tree? commit 47595f49915ac51116916c640f3c0d98df521789 Author: Roland Dreier [EMAIL PROTECTED] Date: Sun Sep 28 14:58:30 2008 +0300 IPoIB: Continue of defer skb_orphan() until irqs enabled Instead of trying to rely on some complicated and fragile reasoning about when some race might occur, let's just do what we want to do anyway and get rid of LLTX. We change from priv-tx_lock (taken with IRQ disabling) to netif_tx_lock (taken on with BH-disabling). And then we can keep the skb_orphan in the place it is, since our xmit routine runs with IRQs enabled. Most of this patch is just compensating for the fact that the tx_lock regions are now IRQ-enabled, and so we have to convert places that take priv-lock to disable IRQs too. If we could change ipoib_cm_rx_event_handler to not need priv-lock, then we could change priv-lock to a BH-disabling lock too and simplify things a bit further. I've tested this patch some in both datagram and connected mode with a kernel with lockdep and other debugging enabled, so it is at least somewhat sane. However more stress testing would definitely be helpful if we want to put this in 2.6.28. Also it would be interesting to see if there are any performance effects. Signed-off-by: Roland Dreier [EMAIL PROTECTED] ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg Thanks. Did you check that this patch doesn't invalidate backport patch? Did you have to change any backport patch? ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ofa-general] ***SPAM*** Re: [ewg] Re: Continue of defer skb_orphan() until irqs enabled
Vladimir Sokolovsky wrote: Thanks. Did you check that this patch doesn't invalidate backport patch? Did you have to change any backport patch? Yes, See commit 7891514239b97fe3396e92d2fcf24f7ab18e60e9. Moni, don't you have OFED's git tree to check? Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg Sorry. I missed that. I see it in my git now. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Continue of defer skb_orphan() until irqs enabled
Hi,
On Sep 9 Arthur started a thread with a patch that fixes an issue with a call
to skb_orphan() when irqs are disabled.
Please look at
http://lists.openfabrics.org/pipermail/general/2008-September/054053.html
Although there is an agreement that the fix isn't yet complete I think that it
is important enough to include it in
OFED **until** we have a full fix for it in upstream kernel because it is still
a big improvement.
I want to suggest a small addition to Arthur's original patch that allows to
disable call to skb_orphan() totally.
I hope it's OK with you Arthur.
Please comment.
-
If a socket's sk_write_space() method expects to run with interrupts
enabled, syslog can get very noisy with messages like:
Badness in local_bh_enable at kernel/softirq.c:140
Call Trace:
[a00100014ce0] show_stack+0x40/0xa0
[a00100014d70] dump_stack+0x30/0x60
[a001000a1730] local_bh_enable+0x90/0x140
[a00100557d30] _spin_unlock_bh+0x30/0x60
[a002097787f0] svc_sock_enqueue+0x750/0x780 [sunrpc]
[a0020977a420] svc_write_space+0xc0/0x1c0 [sunrpc]
[a00100451ad0] sock_wfree+0xd0/0x140
[a002087959e0] ipoib_send+0x1120/0x14a0 [ib_ipoib]
[a0020878dfa0] ipoib_start_xmit+0x380/0x1140 [ib_ipoib]
[a00100461ab0] dev_hard_start_xmit+0x4b0/0x680
[a0010048d2f0] __qdisc_run+0x2d0/0x680
A simple fix is to defer calling skb_orphan() until interrupts have
been reenabled.
Also, since there is still a race that could end up with a call to skb_orphan()
for an
already freed skb, a module parameter allows to disable it totally.
Signed-off-by: Arthur Kepner [EMAIL PROTECTED]
Signed-off-by: Moni Shoua [EMAIL PROTECTED]
---
Index: ofa_kernel-1.4/drivers/infiniband/ulp/ipoib/ipoib.h
===
--- ofa_kernel-1.4.orig/drivers/infiniband/ulp/ipoib/ipoib.h2008-09-24
18:01:28.0 -0400
+++ ofa_kernel-1.4/drivers/infiniband/ulp/ipoib/ipoib.h 2008-09-24
18:12:47.0 -0400
@@ -442,7 +442,7 @@
int ipoib_add_pkey_attr(struct net_device *dev);
int ipoib_add_umcast_attr(struct net_device *dev);
-void ipoib_send(struct net_device *dev, struct sk_buff *skb,
+int ipoib_send(struct net_device *dev, struct sk_buff *skb,
struct ipoib_ah *address, u32 qpn);
void ipoib_reap_ah(struct work_struct *work);
Index: ofa_kernel-1.4/drivers/infiniband/ulp/ipoib/ipoib_ib.c
===
--- ofa_kernel-1.4.orig/drivers/infiniband/ulp/ipoib/ipoib_ib.c 2008-09-24
18:01:28.0 -0400
+++ ofa_kernel-1.4/drivers/infiniband/ulp/ipoib/ipoib_ib.c 2008-09-24
18:12:47.0 -0400
@@ -525,13 +525,14 @@
return ib_post_send(priv-qp, priv-tx_wr, bad_wr);
}
-void ipoib_send(struct net_device *dev, struct sk_buff *skb,
+int ipoib_send(struct net_device *dev, struct sk_buff *skb,
struct ipoib_ah *address, u32 qpn)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_tx_buf *tx_req;
int hlen;
void *phead;
+ int ret = 1; /* assume the worst */
if (skb_is_gso(skb)) {
hlen = skb_transport_offset(skb) + tcp_hdrlen(skb);
@@ -541,7 +542,7 @@
++dev-stats.tx_dropped;
++dev-stats.tx_errors;
dev_kfree_skb_any(skb);
- return;
+ return 1;
}
} else {
if (unlikely(skb-len priv-mcast_mtu + IPOIB_ENCAP_LEN)) {
@@ -550,7 +551,7 @@
++dev-stats.tx_dropped;
++dev-stats.tx_errors;
ipoib_cm_skb_too_long(dev, skb, priv-mcast_mtu);
- return;
+ return 1;
}
phead = NULL;
hlen = 0;
@@ -571,7 +572,7 @@
if (unlikely(ipoib_dma_map_tx(priv-ca, tx_req))) {
++dev-stats.tx_errors;
dev_kfree_skb_any(skb);
- return;
+ return 1;
}
if (skb-ip_summed == CHECKSUM_PARTIAL)
@@ -593,6 +594,7 @@
--priv-tx_outstanding;
ipoib_dma_unmap_tx(priv-ca, tx_req);
dev_kfree_skb_any(skb);
+ ret = 1;
if (netif_queue_stopped(dev))
netif_wake_queue(dev);
} else {
@@ -600,13 +602,14 @@
address-last_send = priv-tx_head;
++priv-tx_head;
- skb_orphan(skb);
-
+ ret = 0;
}
if (unlikely(priv-tx_outstanding MAX_SEND_CQE))
while (poll_tx(priv))
; /* nothing */
+
+ return ret;
}
static void __ipoib_reap_ah(struct net_device *dev)
Index: ofa_kernel-1.4/drivers/infiniband/ulp/ipoib
Re: [ewg] [PATCH] IB/ipoib: avoid WARN_ON on NULL path-ah
Eli Cohen wrote: Commit ee1e2c82c245a5fb2864e9dbcdaab3390fde3fcc introduced an optimization on path flushing. This caused a new possible scenario in which unicast_arp_send triggers path query which could fail, causing path-ah to become NULL. A successive successfull path query will then trigger WARN_ON() in path_rec_completion(). This fix requires old_ah to differ from NULL as a prerequsite to trigger the WARN_ON(). Moreover, that commit also allowed path resolution to be triggered for an invalid path; if that path resolution failed, old_ah would be freed outside priv-lock violating the assumption that dropping references inside the lock are guaranteed not to reach zero reference. Eli Roland, I understand that this patch is going to be in OFED. What about upstream kernel? I'd like to add improvements to commit ee1e2c82c245a5fb2864e9dbcdaab3390fde3fcc (the one you referred to) and it will probably be on top of your fix. I'm sorry if I missed Roland's answer. thanks ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] IB/ipoib: avoid WARN_ON on NULL path-ah
Eli Cohen wrote: On Tue, Sep 23, 2008 at 02:01:00PM +0300, Moni Shoua wrote: Eli Cohen wrote: Commit ee1e2c82c245a5fb2864e9dbcdaab3390fde3fcc introduced an optimization on path flushing. This caused a new possible scenario in which unicast_arp_send triggers path query which could fail, causing path-ah to become NULL. A successive successfull path query will then trigger WARN_ON() in path_rec_completion(). This fix requires old_ah to differ from NULL as a prerequsite to trigger the WARN_ON(). Moreover, that commit also allowed path resolution to be triggered for an invalid path; if that path resolution failed, old_ah would be freed outside priv-lock violating the assumption that dropping references inside the lock are guaranteed not to reach zero reference. Eli Roland, I understand that this patch is going to be in OFED. What about upstream kernel? I'd like to add improvements to commit ee1e2c82c245a5fb2864e9dbcdaab3390fde3fcc (the one you referred to) and it will probably be on top of your fix. I'm sorry if I missed Roland's answer. I don't think Roland responded to this patch yet. Still, I think it is important that this patch is reviewed since we have a regression relative to 2.6.26. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg I agree I gave a thought here. It's possible, when path_rec_completion() is called with nonzero status, to do nothing with ah. Only when path query finishes with success do the replacement. This is good for cases when old_ah is still good (no remote LID change happened). Besides that I think that the patch is correct. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] IB/ipoib: avoid WARN_ON on NULL path-ah
Eli Cohen wrote: On Tue, Sep 23, 2008 at 02:15:47PM +0300, Moni Shoua wrote: I agree I gave a thought here. It's possible, when path_rec_completion() is called with nonzero status, to do nothing with ah. Only when path query finishes with success do the replacement. This is good for cases when old_ah is still good (no remote LID change happened). But what you're saying is that even though no SM responded to a path query, you still want to use the old ah which is an even stronger request than what the original path did (which waited until the new path resolution to complete before updating the ah). Can you think of scenario that can cause this? ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg I agree that this is a stronger request now. Suppose a host that has an ah to another host gets a SM_CHANGE event. I would like that the first host will send path queries to the existing path because there is a chance that the other host changed its LID. However, the new SM might not be ready immediately so the first host might need to retry the path refresh. In this case I would like to keep the old ah since the chances that it is a good ah are very high. BTW, the description of the scenario above is in a code that I intend to send soon. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [ANNOUNCE] ib-bonding 0.9.0 release 30 is available
Hi, This release fixes the problem of loud output when bringing up a bond interface on Redhat 5 It also changes a bit the way to configure bond interfaces with standard OS tools. Please read the doc file for details. Thanks MoniS ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] cma backports: remove check for IFF_BONDING when handling an event
Moni Shoua wrote: Vlad, Please hold on with this patch. I might have a little change for it. thanks MoniS ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg Vlad, You can apply the patch as is. Nothing has changed. Thanks ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] cma backports: remove check for IFF_BONDING when handling an event
flag IFF_BONDING isn't recognized in kernels of rhel4u5 and below. cma code from in upstream kernel uses this value for event filtering but there is no backport that removes it for old kernels. Instead, there is a kernel addon that defines it. This is not enough since ib-bonding (which compiles outside ofaed modules suite) doesn't set this flag and as a result event are filtered in a wrong way. Getting rid of this filter is safe. In rare cases it may save a little time but even than, in the slow path. Signed-off-by: Moni Shoua [EMAIL PROTECTED] --- kernel_patches/backport/2.6.16/cma_to_2_6_23.patch| 13 ++ kernel_patches/backport/2.6.16_sles10/cma_to_2_6_23.patch | 13 ++ kernel_patches/backport/2.6.16_sles10_sp1/cma_to_2_6_23.patch | 13 ++ kernel_patches/backport/2.6.16_sles10_sp2/cma_to_2_6_23.patch | 13 ++ kernel_patches/backport/2.6.17/cma_to_2_6_23.patch| 13 ++ kernel_patches/backport/2.6.18-EL5.1/cma_to_2_6_23.patch | 13 ++ kernel_patches/backport/2.6.18-EL5.2/cma_to_2_6_23.patch | 13 ++ kernel_patches/backport/2.6.18/cma_to_2_6_23.patch| 13 ++ kernel_patches/backport/2.6.18_FC6/cma_to_2_6_23.patch| 13 ++ kernel_patches/backport/2.6.18_suse10_2/cma_to_2_6_23.patch | 13 ++ kernel_patches/backport/2.6.19/cma_to_2_6_23.patch| 13 ++ kernel_patches/backport/2.6.20/cma_to_2_6_23.patch| 13 ++ kernel_patches/backport/2.6.21/cma_to_2_6_23.patch| 13 ++ kernel_patches/backport/2.6.22/cma_to_2_6_23.patch| 13 ++ kernel_patches/backport/2.6.22_suse10_3/cma_to_2_6_23.patch | 13 ++ kernel_patches/backport/2.6.23/cma_to_2_6_23.patch| 13 ++ kernel_patches/backport/2.6.9_U4/cma_to_2_6_23.patch | 13 ++ kernel_patches/backport/2.6.9_U5/cma_to_2_6_23.patch | 13 ++ kernel_patches/backport/2.6.9_U6/cma_to_2_6_23.patch | 13 ++ 19 files changed, 171 insertions(+), 76 deletions(-) diff --git a/kernel_patches/backport/2.6.16/cma_to_2_6_23.patch b/kernel_patches/backport/2.6.16/cma_to_2_6_23.patch index 9ad7660..330feae 100644 --- a/kernel_patches/backport/2.6.16/cma_to_2_6_23.patch +++ b/kernel_patches/backport/2.6.16/cma_to_2_6_23.patch @@ -1,8 +1,8 @@ -Index: ofed_kernel/drivers/infiniband/core/cma.c +Index: ofa_kernel-1.4/drivers/infiniband/core/cma.c === ofed_kernel.orig/drivers/infiniband/core/cma.c -+++ ofed_kernel/drivers/infiniband/core/cma.c -@@ -2804,9 +2804,6 @@ static int cma_netdev_callback(struct no +--- ofa_kernel-1.4.orig/drivers/infiniband/core/cma.c 2008-09-03 16:13:44.0 -0400 ofa_kernel-1.4/drivers/infiniband/core/cma.c 2008-09-03 16:24:06.0 -0400 +@@ -2835,13 +2835,10 @@ struct rdma_id_private *id_priv; int ret = NOTIFY_DONE; @@ -12,3 +12,8 @@ Index: ofed_kernel/drivers/infiniband/core/cma.c if (event != NETDEV_BONDING_FAILOVER) return NOTIFY_DONE; +- if (!(ndev-flags IFF_MASTER) || !(ndev-priv_flags IFF_BONDING)) ++ if (!(ndev-flags IFF_MASTER)) + return NOTIFY_DONE; + + mutex_lock(lock); diff --git a/kernel_patches/backport/2.6.16_sles10/cma_to_2_6_23.patch b/kernel_patches/backport/2.6.16_sles10/cma_to_2_6_23.patch index 9ad7660..330feae 100644 --- a/kernel_patches/backport/2.6.16_sles10/cma_to_2_6_23.patch +++ b/kernel_patches/backport/2.6.16_sles10/cma_to_2_6_23.patch @@ -1,8 +1,8 @@ -Index: ofed_kernel/drivers/infiniband/core/cma.c +Index: ofa_kernel-1.4/drivers/infiniband/core/cma.c === ofed_kernel.orig/drivers/infiniband/core/cma.c -+++ ofed_kernel/drivers/infiniband/core/cma.c -@@ -2804,9 +2804,6 @@ static int cma_netdev_callback(struct no +--- ofa_kernel-1.4.orig/drivers/infiniband/core/cma.c 2008-09-03 16:13:44.0 -0400 ofa_kernel-1.4/drivers/infiniband/core/cma.c 2008-09-03 16:24:06.0 -0400 +@@ -2835,13 +2835,10 @@ struct rdma_id_private *id_priv; int ret = NOTIFY_DONE; @@ -12,3 +12,8 @@ Index: ofed_kernel/drivers/infiniband/core/cma.c if (event != NETDEV_BONDING_FAILOVER) return NOTIFY_DONE; +- if (!(ndev-flags IFF_MASTER) || !(ndev-priv_flags IFF_BONDING)) ++ if (!(ndev-flags IFF_MASTER)) + return NOTIFY_DONE; + + mutex_lock(lock); diff --git a/kernel_patches/backport/2.6.16_sles10_sp1/cma_to_2_6_23.patch b/kernel_patches/backport/2.6.16_sles10_sp1/cma_to_2_6_23.patch index 9ad7660..330feae 100644 --- a/kernel_patches/backport/2.6.16_sles10_sp1/cma_to_2_6_23.patch +++ b/kernel_patches/backport/2.6.16_sles10_sp1/cma_to_2_6_23.patch @@ -1,8 +1,8 @@ -Index: ofed_kernel/drivers
Re: [ewg] [PATCH] cma backports: remove check for IFF_BONDING when handling an event
Vlad, Please hold on with this patch. I might have a little change for it. thanks MoniS ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [ANNOUNCE] ib-bonding release 29 is out
Hi, SRPM is in the usual place for OFED-1.4 (the file latest.txt was updaated) Change Log -- 1. Fix bug 1141 2. Add support for Redhat 4 Up 7 3. Add support for Redhat 5 Up 2 thanks Vlad We still need to add support in install.pl. Do you want me to do that? ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] ib-bonding release 28 is available
Hi, SRPM is in OFA server and should be taken during the build of OFED tarball. Vlad, Please note that I've put it under ~monis/public_html/ofed_1_4 as well as under ~monis/public_html/ofed_1_3 Changes since last release * Take some fixes that were added from linux-2.6.24 to linux-2.6.26 (kind of rebase) - send a NETDEV_ event whenever bonding changes active slaves. This is for applications that care who is the active slave. - add modparam that counts the number of grat. ARP to send in case of failover. - bug fixes * Fix initscripts support in Redhat 5.1 * Fix a bug in backport for Redhat 4.x that prevented use in module params * Fix a bug in backport for Redhat 4.x that prevented use in ethtool thanks ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] openibd service dependency
Hi, This is a question regarding preconditions for openibd script before it starts. The question assumes that OS is SuSE but the only difference from other OS is just in the mechanism. openibd script is installed with Required-Start: $network directive. This forces /etc/init.d/network to run before /etc/init.d/openibd This causes a bug when bonding is configured with ifcfg-* files. Files are read and parsed when network script runs but at this time ib* interfaces do not exist (openibd wasn't started yet). My questions are: 1) Why does openibd depends on nnetwork to start? 2) Isn't it more logical to reverse the dependency? (network should run only when interfaces exist). thanks MoniS ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] ib-bonding release 23
Hi, I have put a new release of the ib-bonding RPM (file latest.txt is up-to-date) Release content 1) Bug fix with bonding interface and multicast traffic 2) Improve failover mechanism. thanks MoniS ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] IB/IPoIB Check if grat. ARP changed had arrived when working in connected mode
Moni Shoua wrote: move a little up the code that checks for a situation where the remote GID stored in the ipoib_neigh is different than the one present in the neighbour (handle Gratuitous ARP) or that a bonding fail over has happened but the neighbour still has a pointer to an ipoib_neigh created not by the current slave. This will cause the driver to apply the check also for connected mode neighbours. This patch was tested against upstream kernel and ofed_kernel. Signed-off-by: Or Gerlitz [EMAIL PROTECTED] Signed-off-by: Moni Shoua [EMAIL PROTECTED] This patch resolves a critical bug: https://bugs.openfabrics.org/show_bug.cgi?id=878 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] ib-bonding release 22
Please take from my home dir. latest.txt was also updated.
Change Log:
--
1. Apply backport patches also for kernel 2.6.9-67 (Redhat4 UP6)
2. Fix bugs for working with OS tools (sysconfig/initscripts)
3. Change in documentation for working with OS tools
4. Fix: in ib-bons - bond0 appears as constant instead of $BOND_NAME in one
place
5. Fix: Destroy bonding master only if it exists
Vlad,
Please apply the patch below to ofed_1_3_scripts to complete the support for
RH4 Up6
Add 2.6.9-67 to the list of kernels that are supported by ib-bonding
Signed-off-by: Moni Shoua [EMAIL PROTECTED]
---
diff --git a/install.pl b/install.pl
index 256263d..fcae1fb 100755
--- a/install.pl
+++ b/install.pl
@@ -1579,7 +1579,7 @@ sub set_availability
}
# ib-bonding
-if ($kernel =~
m/2.6.9-34|2.6.9-42|2.6.9-55|2.6.16.[0-9.]*-[0-9.]*-[A-Za-z0-9.]*|el5|fc6/) {
+if ($kernel =~
m/2.6.9-34|2.6.9-42|2.6.9-55|2.6.9-67|2.6.16.[0-9.]*-[0-9.]*-[A-Za-z0-9.]*|el5|fc6/)
{
$packages_info{'ib-bonding'}{'available'} = 1;
$packages_info{'ib-bonding-debuginfo'}{'available'} = 1;
}
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: Can you send explanation how to work with bonding and the standard bonding setting
Scott Weitzenkamp (sweitzen) wrote: Or, I don't see /sbin/call_ifenslave in my OFED-1.3-20080115-0600 ib-bonding package. Also, please run ib-bond --version. /sbin/call_ifenslave should be there only from release 16 and higher. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: Can you send explanation how to work with bonding and the standard bonding setting
Scott Weitzenkamp (sweitzen) wrote: Or, I don't see /sbin/call_ifenslave in my OFED-1.3-20080115-0600 ib-bonding package. [EMAIL PROTECTED] ~]# uname -a Linux svbu-qa1850-1 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x8 6_64 x86_64 GNU/Linux [EMAIL PROTECTED] ~]# rpm -ql ib-bonding /lib/modules/2.6.9-55.ELsmp/updates/kernel/drivers/net/bonding/bonding.k o /usr/bin/ib-bond /usr/share/doc/ib-bonding-0.9.0/ib-bonding.txt Scott Very strange. I can't think of why this is happening for you. Can you please run rpm -qlp on the ib-bonding rpm binary file? if you still don't see sbin/call_ifenslave try to rebuild the SRPM of ib-bonding and run rpm -qlp on the resulted binrpm. MoniS ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] ofed_1_3/ofed_docs: Add vendor script documentaion
Moni,
Please send a patch to OFED_tips.txt explaining how to use this new
feature (or do you think it should go to the user guide?
Tziporet
Hi Tziporet,
After giving it a second thought, OFED_tips.txt look the right place. Please
see the patch below.
Thanks
diff --git a/OFED_tips.txt b/OFED_tips.txt
index d94fdf1..3953cb7 100644
--- a/OFED_tips.txt
+++ b/OFED_tips.txt
@@ -9,7 +9,7 @@ Table of Contents
1. OFED Utilities
2. Debug HOWTOs
3. Pinning (Locking) User Memory Pages
-
+4. Adding vedndor specific actions to the installation of OFED
===
1. OFED Utilities
@@ -236,3 +236,80 @@ these limits entirely.
Note: The file /etc/security/limits.conf contains further documentation.
+===
+4. Adding vendor specific actions to the installation of OFED
+===
+
+Vendors that want to add actions to the install/uninstall process of OFED can
+bind external scripts to hooks in install.pl and ofed_uninstall.sh.
+
+4.1 Specifying vendor scripts and configuration parameters
+---
+This option is only available when installing ofed in non interactive mode.
+Edit the OFED configuration file (ofed.conf ) and add the lines below (you
don't have to use all of them).
+
+# Script to run before install process starts
+vendor_pre_install=my_pre_install.sh
+# Script to run after install process finishes
+vendor_post_install=my_post_install.sh
+# Script to run before uninstall process starts
+vendor_pre_uninstall=my_pre_uninstall.sh
+# Script to run after uninstall process finishes
+vendor_post_uninstall=my_post_uninstall.sh
+
+You can also also add vendor specific configuration parameters. Lines that
start
+with vendor_config_ will not be parsed by install.pl and can be parsed by one
+of the vendor scripts
+
+vendor_config_something=value_for_that_something
+
+Running ./install.pl -c ofed.conf in the OFED directory will now invoke the
+relevant vendor specific actions.
+
+4.2. Requirements from vendor scripts
+-
+The script files that are given to install.pl in ofed.conf should
+ - be located in the root directory of OFED
+ - return zero on success
+
+If vendor script fails it fails the entire installation.
+
+4.2 Skeleton for pre/post install vendor script
+---
+install.pl passes some usefull installation variables to the vendor pre/post
+install scripts environment. See the example below for a typical usage.
+
+#!/bin/bash
+
+eval $*
+
+# The following env. parameters are set at this point
+#
+# CONFIG: full path filename of the OFED configuration file
+# RPMS: directory of binary RPMs
+# SRPMS: directory of source RPMS
+# PREFIX: prefix of installation
+# TOPDIR: root of OFED package
+# QUIET: quiet operation indicator
+
+function readconf() {
+local config=$1
+while read line; do
+# skip comments
+[[ ${line:0:1} == # ]] continue
+
+# skip empty lines
+[[ -z $line ]] continue
+
+# parse line
+token=$(echo $line|cut -f1 -d=)
+value=$(echo $line|cut -f2 -d=)
+
+done $config
+}
+
+readconf $CONFIG
+
+exit 0
+
+
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] ofed_1_3/ofed_scripts: Add vendor script pre/post hooks for OFED install/uninstall
Applied.
Regards,
Vladimir
Thanks. Please apply the following addition to the patch.
This will allow the users to add lines to ofed.conf which will not be parsed by
install.pl
and can be used by the vendor scripts. Such line should start with the string:
vendor_config
diff --git a/install.pl b/install.pl
index 915530e..c1432f3 100755
--- a/install.pl
+++ b/install.pl
@@ -2049,6 +2049,11 @@ sub select_packages
next;
}
+
+ if (substr($package,0,length(vendor_config)) eq
vendor_config) {
+ next;
+ }
+
if ($package eq vendor_pre_install) {
if ( -f $selected ) {
$vendor_pre_install = dirname($selected) . '/' .
basename($selected);
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] ofed_1_3/ofed_scripts: Add vendor script pre/post hooks for OFED install/uninstall
This is a modification to the section in the patch for the file install.pl
The pupose of the change is to allow ofed.conf to contain lines of the form
vendor_script* (e.g. vendor_config_fix_something=yes).
When install.pl parses the configuration file it silently ignores lines that
start with vendor_config.
--- a/install.pl2007-12-12 13:43:57.0 +0200
+++ b/install.pl2008-01-06 18:03:55.0 +0200
@@ -59,6 +59,11 @@
my $clear_string = `clear`;
my $upgrade_open_iscsi = 0;
+my $vendor_pre_install = ;
+my $vendor_post_install = ;
+my $vendor_pre_uninstall = ;
+my $vendor_post_uninstall = ;
+
my $distro;
my $build32 = 0;
@@ -2041,6 +2046,54 @@
next;
}
+if (substr($package,0,length(vendor_config)) eq
vendor_config) {
+ next;
+ }
+
+if ($package eq vendor_pre_install) {
+ if ( -f $selected ) {
+ $vendor_pre_install = dirname($selected) . '/' .
basename($selected);
+ }
+ else {
+ print RED \nVendor script $selected is not found,
RESET \n if (not $quiet);
+ exit 1
+ }
+next;
+}
+
+if ($package eq vendor_post_install) {
+ if ( -f $selected ) {
+ $vendor_post_install = dirname($selected) . '/' .
basename($selected);
+ }
+ else {
+ print RED \nVendor script $selected is not found,
RESET \n if (not $quiet);
+ exit 1
+ }
+next;
+}
+
+if ($package eq vendor_pre_uninstall) {
+ if ( -f $selected ) {
+ $vendor_pre_uninstall = dirname($selected) . '/' .
basename($selected);
+ }
+ else {
+ print RED \nVendor script $selected is not found,
RESET \n if (not $quiet);
+ exit 1
+ }
+next;
+}
+
+if ($package eq vendor_post_uninstall) {
+ if ( -f $selected ) {
+ $vendor_post_uninstall = dirname($selected) . '/' .
basename($selected);
+ }
+ else {
+ print RED \nVendor script $selected is not found,
RESET \n if (not $quiet);
+ exit 1
+ }
+next;
+}
+
if ($package eq kernel_configure_options or $package eq
OFA_KERNEL_PARAMS) {
$kernel_configure_options = $selected;
next;
@@ -3662,7 +3715,33 @@
# Uninstall the previous installations
uninstall();
+my $vendor_ret;
+if (length($vendor_pre_install) 0) {
+ print BLUE \nRunning vendor pre install script:
$vendor_pre_install, RESET \n if (not $quiet);
+ $vendor_ret = system ( $vendor_pre_install, CONFIG=$config,
+ RPMS=$RPMS, SRPMS=$SRPMS, PREFIX=$prefix,
TOPDIR=$TOPDIR, QUIET=$quiet );
+ if ($vendor_ret != 0) {
+ print RED \nExecution of vendor pre install script
failed., RESET \n if (not $quiet);
+ exit 1;
+ }
+}
install();
+if (length($vendor_pre_uninstall) 0) {
+ system cp $vendor_pre_uninstall
$prefix/sbin/vendor_pre_uninstall.sh;
+}
+if (length($vendor_post_uninstall) 0) {
+ system cp $vendor_post_uninstall
$prefix/sbin/vendor_post_uninstall.sh;
+}
+if (length($vendor_post_install) 0) {
+ print BLUE \nRunning vendor post install script:
$vendor_post_install, RESET \n if (not $quiet);
+ $vendor_ret = system ( $vendor_post_install, CONFIG=$config,
+ RPMS=$RPMS, SRPMS=$SRPMS, PREFIX=$prefix,
TOPDIR=$TOPDIR, QUIET=$quiet);
+ if ($vendor_ret != 0) {
+ print RED \nExecution of vendor post install script
failed., RESET \n if (not $quiet);
+ exit 1;
+ }
+}
+
if ($kernel_modules_info{'ipoib'}{'selected'}) {
ipoib_config();
}
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] ofed_1_3/ofed_scripts: Add vendor script pre/post hooks for OFED install/uninstall
Moni Shoua wrote: Vendors that distribute OFED sometimes need to add vendor specific actions to the install and/or the uninstall process. This patch adds this capability of adding scripts that would be executed before and after OFED install and uninstall. Names of the scripts are given in the configuration file for the install.pl script. Hi Vlad, I'd like to get your opinion please regarding this patch. Do you consider applying it? thanks MoniS ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
