Re: [openib-general] Current List of OFA Linux components and maintainers
> Attached is the latest list of component maintainers for the OFA Linux > stack that was compiled at the OFA developers workshop in Tampa. > Let me know if there are any changes or additions needed. > I would be good if we could get this posted somewhere on > the OFA website so that the larger OF community knows who to send > patches to for each component. Especially in the OFED distro I have now stuck my nose deep enough in IPoIB that I guess I can't avoid this responsibility now :) And Roland seems uninterested in backporting code to older kernels, so that's all my code, too. For SRP, all OFED backporting was done by Ishai Rabinovit <[EMAIL PROTECTED]>, and he's taken over the srp daemon from Roland, so I think you want to add him to maintainer list there. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH v2] [RFC] ofed_1_2 2.6.17 backport: simulate neighbourupdate events by snooping ARP packets]
> Quoting Steve Wise <[EMAIL PROTECTED]>: > Subject: [PATCH v2] [RFC] ofed_1_2 2.6.17 backport: simulate neighbourupdate > events by snooping ARP packets] > > Here is an updated patch for review. If you like this, then I'll post a > series to back-port this to all the kernels... Looks good. Let's do it. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] nightly osm_sim report 2007-01-25:normal completion
OSM Simulation Regression Summary OpenSM rev = Tue_Jan_23_18:08:59_2007 b49605 ibutils rev = Wed_Jan_3_11:42:12_2007 913448 Total=410 Pass=410 Fail=0 Pass: 30 Stability IS1-16.topo 30 Pkey IS1-16.topo 30 OsmTest IS1-16.topo 30 OsmStress IS1-16.topo 30 Multicast IS1-16.topo 30 LidMgr IS1-16.topo 10 Stability IS3-loop.topo 10 Stability IS3-128.topo 10 Pkey IS3-128.topo 10 OsmTest IS3-loop.topo 10 OsmTest IS3-128.topo 10 OsmStress IS3-128.topo 10 Multicast IS3-loop.topo 10 Multicast IS3-128.topo 10 LidMgr IS3-128.topo 10 FatTree part-4-ary-3-tree.topo 10 FatTree merge-roots-reorder-4-ary-2-tree.topo 10 FatTree merge-roots-4-ary-2-tree.topo 10 FatTree merge-root-4-ary-3-tree.topo 10 FatTree merge-root-12-ary-2-tree.topo 10 FatTree merge-2-ary-4-tree.topo 10 FatTree half-4-ary-3-tree.topo 10 FatTree blend-4-ary-2-tree.topo 10 FatTree 4-ary-4-tree.topo 10 FatTree 4-ary-3-tree.topo 10 FatTree 32nodes-3lvl-is1.topo 10 FatTree 2-ary-4-tree.topo 10 FatTree 12-node-spaced.topo 10 FatTree 12-ary-2-tree.topo Failures: ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] modules compilation status for OFED 1.2
Hi, > We stay with same build process but the backport patches give a solution > for such cases. > Michael Tsirkin can help you how we solved such problems with other > kernel code we needed. I need to be more specific here: ibmebus requires two symbols in arch/ppc64/kernel/dma.c to be exported, which means one really needs to rebuild and install the patched kernel. As far as I understood from Michael, when we looked at ofed-1.1, that approach is not supported by ofed build process. Regards Nam ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 0/6] osm: QoS policy parser
Hi Hal, Hal Rosenstock wrote: > Hi Yevgeny, > > On Wed, 2007-01-24 at 09:15, Yevgeny Kliteynik wrote: > > [snip...] > >>> I also have some questions about the patches >> Shoot > > First, as I understand it, this higher level QoS is not yet an approved > standard (annex) so is this code experimental? I guess so > In any case, some things > might change, etc. so IMO this QoS should be implemented in a way that > minimizes the risk to the non QoS code. Agree > I suspect the main interactions > are in osm_sa_path/multipath_record.c but will also extend to the QoS > manager. So should this all be conditionalized with something like > QOS_ANNEX and by default be off with some build switch to enable this > code in OpenSM until be becomes standard ? I suggest that instead of enclosing the code in ifdef, this new code will be invoked only when QoS in OpenSM has been turned on. > When will the remainder of the changes to the QoS manager be ready ? It > would be good to see the whole picture. Are there any other missing > pieces ? I'm working right now on checking path record for QoS constraints. I'm hoping to finish it in a day or two. After that, I'll do the same with multipath record. > It would be good to have some documentation for this including an opensm > man page update. > > As far as using lex/yacc, are they invoked as part of the build > procedure or are the files they generate just checked in and used ? When lex/yacc are invoked, they generate three files: - osm_qos_parser_l.c - osm_qos_parser_y.c - osm_qos_parser_y.h These generated files should be included in the git repository, and they are the ones that are compiled by 'make' command. To cause lex/yacc generate these files on every compilation, a configuration flag '--enable-maintainer-mode' should be used when running 'configure'. So normally, lex/yacc won't be invoked during the build (unless the --enable-maintainer-mode option was selected). > How could/would multiple file versions be supported ? One previous > example was a mention that port groups can be shared by more than one > manager (e.g. QoS and partitions) so this might be made hierarchical. > I'd like to understand this before we get locked in. The parser can be enhanced to support different versions of grammar. It will just check the first line of the policy file: and then it will decide which grammar rules to apply according to the 'version' value. --Yevgeny > There are some other lower level questions which I'll get to later. I'll > also review the XML file format in detail later. > > -- Hal > > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH v2] osm: QoS: added qos class and service id to the path record
Hi Hal
[V2] QoS patch: added qos class and service id to the path record
Signed-off-by: Yevgeny Kliteynik <[EMAIL PROTECTED]>
---
osm/include/iba/ib_types.h | 148 ++---
osm/opensm/osm_helper.c |8 +-
osm/opensm/osm_sa_multipath_record.c |2 +-
osm/opensm/osm_sa_path_record.c |5 +-
osm/osmtest/osmtest.c|2 +-
5 files changed, 144 insertions(+), 21 deletions(-)
diff --git a/osm/include/iba/ib_types.h b/osm/include/iba/ib_types.h
index 22f7f62..2bbb8b4 100644
--- a/osm/include/iba/ib_types.h
+++ b/osm/include/iba/ib_types.h
@@ -1700,6 +1700,28 @@ ib_class_is_rmpp(
#define IB_SMINFO_STATE_MASTER 3
/**/
+/d* IBA Base: Constants/IB_PATH_REC_SL_MASK
+* NAME
+* IB_PATH_REC_SL_MASK
+*
+* DESCRIPTION
+* Mask for the sl field for path record
+*
+* SOURCE
+*/
+#define IB_PATH_REC_SL_MASK 0xF
+
+/d* IBA Base: Constants/IB_PATH_REC_QOS_CLASS_MASK
+* NAME
+* IB_PATH_REC_QOS_CLASS_MASK
+*
+* DESCRIPTION
+* Mask for the QoS class field for path record
+*
+* SOURCE
+*/
+#define IB_PATH_REC_QOS_CLASS_MASK 0xFFF0
+
/d* IBA Base: Constants/IB_PATH_REC_SELECTOR_MASK
* NAME
* IB_PATH_REC_SELECTOR_MASK
@@ -2314,7 +2336,7 @@ ib_gid_get_guid(
#include
typedef struct _ib_path_rec
{
- uint8_t resv0[8];
+ ib_net64_t service_id;
ib_gid_tdgid;
ib_gid_tsgid;
ib_net16_t dlid;
@@ -2323,7 +2345,7 @@ typedef struct _ib_path_rec
uint8_t tclass;
uint8_t num_path;
ib_net16_t pkey;
- ib_net16_t sl;
+ ib_net16_t qos_class_sl;
uint8_t mtu;
uint8_t rate;
uint8_t pkt_life;
@@ -2334,8 +2356,8 @@ typedef struct _ib_path_rec
#include
/*
* FIELDS
-* resv0
-* Reserved bytes.
+* service_id
+* Service ID.
*
* dgid
* GID of destination port.
@@ -2363,11 +2385,8 @@ typedef struct _ib_path_rec
* pkey
* Partition key (P_Key) to use on this path.
*
-* resv1
-* Reserved byte.
-*
-* sl
-* Service level to use on this path.
+* qos_class_sl
+* QoS class and service level to use on this path.
*
* mtu
* MTU and MTU selector fields to use on this path
@@ -2388,6 +2407,7 @@ typedef struct _ib_path_rec
*/
/* Path Record Component Masks */
+#define IB_PR_COMPMASK_SERVICEID (CL_HTON64(((uint64_t)1)<<1))
#define IB_PR_COMPMASK_DGID (CL_HTON64(((uint64_t)1)<<2))
#define IB_PR_COMPMASK_SGID (CL_HTON64(((uint64_t)1)<<3))
#define IB_PR_COMPMASK_DLID (CL_HTON64(((uint64_t)1)<<4))
@@ -2400,7 +2420,7 @@ typedef struct _ib_path_rec
#define IB_PR_COMPMASK_REVERSIBLE(CL_HTON64(((uint64_t)1)<<11))
#define IB_PR_COMPMASK_NUMBPATH (CL_HTON64(((uint64_t)1)<<12))
#define IB_PR_COMPMASK_PKEY (CL_HTON64(((uint64_t)1)<<13))
-#define IB_PR_COMPMASK_RESV1 (CL_HTON64(((uint64_t)1)<<14))
+#define IB_PR_COMPMASK_QOS_CLASS (CL_HTON64(((uint64_t)1)<<14))
#define IB_PR_COMPMASK_SL(CL_HTON64(((uint64_t)1)<<15))
#define IB_PR_COMPMASK_MTUSELEC (CL_HTON64(((uint64_t)1)<<16))
#define IB_PR_COMPMASK_MTU (CL_HTON64(((uint64_t)1)<<17))
@@ -2658,6 +2678,7 @@ ib_path_rec_init_local(
IN ib_net16_t slid,
IN uint8_t num_path,
IN ib_net16_t pkey,
+ IN uint16_tqos_class,
IN uint8_t sl,
IN uint8_t mtu_selector,
IN uint8_t mtu,
@@ -2673,8 +2694,8 @@ ib_path_rec_init_local(
p_rec->slid = slid;
p_rec->num_path = num_path;
p_rec->pkey = pkey;
- /* Lower 4 bits of path rec's SL are reserved. */
- p_rec->sl = cl_ntoh16( sl );
+ p_rec->qos_class_sl = cl_ntoh16( (sl & IB_PATH_REC_SL_MASK) |
+(qos_class << 4) );
p_rec->mtu = (uint8_t)((mtu & IB_PATH_REC_BASE_MASK) |
(uint8_t)(mtu_selector << 6));
p_rec->rate = (uint8_t)((rate & IB_PATH_REC_BASE_MASK) |
@@ -2686,8 +2707,8 @@ ib_path_rec_init_local(
/* Clear global routing fields for local path records */
p_rec->hop_flow_raw = 0;
p_rec->tclass = 0;
+ p_rec->service_id = 0;
- *((uint64_t*)p_rec->resv0) = 0;
Re: [openib-general] librdmacm and udapl: Which git branch to use in ofed_1_2 build
>> > Could you please rebase that to 2.6.20-rc5? >> >> Yes - but I probably won't get to this until tomorrow. > >Not a problem - I generated patches and put them in OFED already. I've updated my rdma-dev.git tree to the latest flavor of the day. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] autogen.sh in userspace/libmthca needs automake version check
Hi, I don't know if this is the right place to post this, but the autogen.sh in userspace/libmthca should have a version check for automake. With automake 1.4, I get an error: Makefile.am:5: invalid unused variable name: `MTHCA_SOURCES' ...whereas after upgrading to automake 1.9, it seems to run cleanly. There's a version check in the autogen.sh in userspace/libibutils that seems appropriate. FYI, I pulled the userspace code off git yesterday (1/23) via the instructions on the wiki, and am in the process of trying to get things built for a 2.6.19.2 kernel. OFED 1.1 doesn't seem to build due to conflicts with the kernel, so I'm giving the development tree a shot. Cheers, -Daniel ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH v2] [RFC] ofed_1_2 2.6.17 backport: simulate neighbour update events by snooping ARP packets]
Here is an updated patch for review. If you like this, then I'll post a
series to back-port this to all the kernels...
Steve.
---
2.6.17 backport: simulate neighbour update events by snooping ARP packets
Needed to support iWARP devices on backported kernels. This also allows
using the current drivers/infiniband/core/addr.c which requires netevents
as well.
For each incoming ARP request or response, we add a destructor function
to the skb. When the skb is freed (ie when the ARP subsystem has updated
the neighbour entry if needed) our destructor function will get called
and we can generate a NEIGH_UPDATE netevent.
When the first consumer registers for netevents, we add an ARP packet
filter to start snooping. When the last consumer unregisters, we remove
the filter.
Changes:
- add the snoop code to the backport netevent.c file.
- remove the backport patch to revert addr.c to snoop ARP packets.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
.../backport/2.6.17/include/src/netevent.c | 67
.../2.6.17/addr_1_netevents_revert_to_2_6_17.patch | 76
---
2 files changed, 65 insertions(+), 78 deletions(-)
diff --git a/kernel_addons/backport/2.6.17/include/src/netevent.c
b/kernel_addons/backport/2.6.17/include/src/netevent.c
index 35d02c3..26a0920 100644
--- a/kernel_addons/backport/2.6.17/include/src/netevent.c
+++ b/kernel_addons/backport/2.6.17/include/src/netevent.c
@@ -15,6 +15,55 @@
#include
#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+static DEFINE_MUTEX(lock);
+static int count;
+
+static void destructor(struct sk_buff *skb)
+{
+ struct neighbour *n;
+ u8 *arp_ptr;
+ __be32 gw;
+
+ /* Pull the SPA */
+ arp_ptr = skb->nh.raw + sizeof(struct arphdr) + skb->dev->addr_len;
+ memcpy(&gw, arp_ptr, 4);
+ n = neigh_lookup(&arp_tbl, &gw, skb->dev);
+ if (n)
+ call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, n);
+ return;
+}
+
+static int arp_recv(struct sk_buff *skb, struct net_device *dev,
+struct packet_type *pkt, struct net_device *dev2)
+{
+ struct arphdr *arp_hdr;
+ u16 op;
+
+ arp_hdr = (struct arphdr *) skb->nh.raw;
+ op = ntohs(arp_hdr->ar_op);
+
+ if ((op == ARPOP_REQUEST || op == ARPOP_REPLY) && !skb->destructor)
+ skb->destructor = destructor;
+
+ kfree_skb(skb);
+ return 0;
+}
+
+static struct packet_type arp = {
+ .type = __constant_htons(ETH_P_ARP),
+ .func = arp_recv,
+ .af_packet_priv = (void *)1,
+};
static ATOMIC_NOTIFIER_HEAD(netevent_notif_chain);
@@ -30,8 +79,13 @@ static ATOMIC_NOTIFIER_HEAD(netevent_not
int register_netevent_notifier(struct notifier_block *nb)
{
int err;
-
err = atomic_notifier_chain_register(&netevent_notif_chain, nb);
+ if (!err) {
+ mutex_lock(&lock);
+ if (count++ == 0)
+ dev_add_pack(&arp);
+ mutex_unlock(&lock);
+ }
return err;
}
@@ -47,7 +101,16 @@ int register_netevent_notifier(struct no
int unregister_netevent_notifier(struct notifier_block *nb)
{
- return atomic_notifier_chain_unregister(&netevent_notif_chain, nb);
+ int err;
+
+ err = atomic_notifier_chain_unregister(&netevent_notif_chain, nb);
+ if (!err) {
+ mutex_lock(&lock);
+ if (--count == 0)
+ dev_remove_pack(&arp);
+ mutex_unlock(&lock);
+ }
+ return err;
}
/**
diff --git
a/kernel_patches/backport/2.6.17/addr_1_netevents_revert_to_2_6_17.patch
b/kernel_patches/backport/2.6.17/addr_1_netevents_revert_to_2_6_17.patch
deleted file mode 100644
index 316d8d2..000
--- a/kernel_patches/backport/2.6.17/addr_1_netevents_revert_to_2_6_17.patch
+++ /dev/null
@@ -1,76 +0,0 @@
-commit e795d092507d571d66f2ec98d3efdc7dd284bf80
-Author: Tom Tucker <[EMAIL PROTECTED]>
-Date: Sun Jul 30 20:44:19 2006 -0700
-
-[NET] infiniband: Cleanup ib_addr module to use the netevents
-
-Signed-off-by: Tom Tucker <[EMAIL PROTECTED]>
-Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
-Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
-
-diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
-index 1205e80..d294bbc 100644
a/drivers/infiniband/core/addr.c
-+++ b/drivers/infiniband/core/addr.c
-@@ -35,7 +35,6 @@ #include
- #include
- #include
- #include
--#include
- #include
-
- MODULE_AUTHOR("Sean Hefty");
-@@ -327,22 +326,25 @@ void rdma_addr_cancel(struct rdma_dev_ad
- }
- EXPORT_SYMBOL(rdma_addr_cancel);
-
--static int netevent_callback(struct notifier_block *self, unsigned long
event,
-- void *ctx)
-+static int addr_arp_recv(struct sk_buff *skb, struct net_device *dev,
-+ struct packet_type *pkt, struct net_device *orig_dev)
- {
[openib-general] [PATCH] opensm: cleanup unused osm_req_ctrl
This cleanups unused osm_req_ctrl stuff and corresponded objects.
Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---
osm/include/Makefile.am |1 -
osm/include/opensm/osm_msgdef.h | 16 +---
osm/include/opensm/osm_req_ctrl.h | 228 -
osm/include/opensm/osm_sm.h |5 -
osm/opensm/Makefile.am|2 +-
osm/opensm/osm_helper.c |2 +-
osm/opensm/osm_req_ctrl.c | 136 --
osm/opensm/osm_sm.c |6 -
8 files changed, 3 insertions(+), 393 deletions(-)
delete mode 100644 osm/include/opensm/osm_req_ctrl.h
delete mode 100644 osm/opensm/osm_req_ctrl.c
diff --git a/osm/include/Makefile.am b/osm/include/Makefile.am
index b49cf21..5a186ff 100644
--- a/osm/include/Makefile.am
+++ b/osm/include/Makefile.am
@@ -71,7 +71,6 @@ EXTRA_DIST = \
$(srcdir)/opensm/osm_pkey.h \
$(srcdir)/opensm/osm_pkey_mgr.h \
$(srcdir)/opensm/osm_sa_mad_ctrl.h \
- $(srcdir)/opensm/osm_req_ctrl.h \
$(srcdir)/opensm/osm_sa_link_record.h \
$(srcdir)/opensm/osm_mcm_port.h \
$(srcdir)/opensm/osm_log.h \
diff --git a/osm/include/opensm/osm_msgdef.h b/osm/include/opensm/osm_msgdef.h
index 87c943f..a90e3b9 100644
--- a/osm/include/opensm/osm_msgdef.h
+++ b/osm/include/opensm/osm_msgdef.h
@@ -77,20 +77,6 @@ BEGIN_C_DECLS
*
*/
-/s* OpenSM: Dispatcher Messages/OSM_MSG_REQ
-* NAME
-* OSM_MSG_REQ
-*
-* DESCRIPTION
-* Initiates a QP0 attribute request.
-*
-* NOTES
-* Sent by:osm_sm_t
-* Received by:osm_req_ctrl_t
-* Delivery notice:yes
-*
-***/
-
/s* OpenSM: Dispatcher Messages/OSM_MSG_MAD_NODE_INFO
* NAME
* OSM_MSG_MAD_NODE_INFO
@@ -166,7 +152,7 @@ BEGIN_C_DECLS
***/
enum
{
- OSM_MSG_REQ = 0,
+ OSM_MSG_NONE = 0,
OSM_MSG_MAD_NODE_INFO,
OSM_MSG_MAD_PORT_INFO,
OSM_MSG_MAD_SWITCH_INFO,
diff --git a/osm/include/opensm/osm_req_ctrl.h
b/osm/include/opensm/osm_req_ctrl.h
deleted file mode 100644
index 7823823..000
--- a/osm/include/opensm/osm_req_ctrl.h
+++ /dev/null
@@ -1,228 +0,0 @@
-/*
- * Copyright (c) 2004, 2005 Voltaire, Inc. All rights reserved.
- * Copyright (c) 2002-2005 Mellanox Technologies LTD. All rights reserved.
- * Copyright (c) 1996-2003 Intel Corporation. All rights reserved.
- *
- * This software is available to you under a choice of one of two
- * licenses. You may choose to be licensed under the terms of the GNU
- * General Public License (GPL) Version 2, available from the file
- * COPYING in the main directory of this source tree, or the
- * OpenIB.org BSD license below:
- *
- * Redistribution and use in source and binary forms, with or
- * without modification, are permitted provided that the following
- * conditions are met:
- *
- * - Redistributions of source code must retain the above
- *copyright notice, this list of conditions and the following
- *disclaimer.
- *
- * - Redistributions in binary form must reproduce the above
- *copyright notice, this list of conditions and the following
- *disclaimer in the documentation and/or other materials
- *provided with the distribution.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
- * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
- * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
- * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
- * SOFTWARE.
- *
- */
-
-/*
- * Abstract:
- * Declaration of osm_req_ctrl_t.
- * This object represents a controller that calls the
- * generic requester object to retrieve attributes from a node.
- * This object is part of the OpenSM family of objects.
- *
- * Environment:
- * Linux User Mode
- *
- * $Revision: 1.4 $
- */
-
-#ifndef _OSM_REQ_CTRL_H_
-#define _OSM_REQ_CTRL_H_
-
-#include
-#include
-#include
-#include
-
-#ifdef __cplusplus
-# define BEGIN_C_DECLS extern "C" {
-# define END_C_DECLS }
-#else /* !__cplusplus */
-# define BEGIN_C_DECLS
-# define END_C_DECLS
-#endif /* __cplusplus */
-
-BEGIN_C_DECLS
-
-/h* OpenSM/Generic Request Controller
-* NAME
-* Generic Request Controller
-*
-* DESCRIPTION
-* The Generic Request Controller object encapsulates the information
-* needed to request an attribute from a node.
-*
-* The Generic Request Controller object is thread safe.
-*
-* This object should be treated as opaque and should be
-* manipulated only through the provided functions.
-*
-* AUTHOR
-* Steve King, Intel
-*
-*/
-
-/s* OpenSM: Generic Request Controller/osm_req_ctrl
Re: [openib-general] [PATCH 2/2 vex branch] IB/VNIC Fix failover delay issue
> Thanks Roland. But for some reason, I do not see the commit > logs for these two patches in the vex branch, even though I can see from > the code that the patches have been applied. (I can see the commit > logs for the initial set of patches though). Any idea why ? Yes, because I rolled the patches into the existing patches already there rather than adding them on top of what I had. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] InfiniBand Maintainers Summit/BOF at Ottawa Linux Symposium
Hay guys, I was wondering how many people are planning to attend the Ottawa Linux Symposium this year and if there was any interest in getting the maintainers together for an InfiniBand BOF. I think it would be good to get the maintainers together once in a while face to face just to discuss how the general process of InfiniBand development is working for people, are there anything we should be doing different, what new features are coming and what kernel versions might they be targeted at, etc. If a lot of people are already planning on attending, then this might be an opportunity to get together. Please respond with, 1.) If you are planning on attending OLS this year ? 2.) If you are interested in having an InfiniBand BOF. If there is enough interest, I will send in a request to OLS for a BOF timeslot Please respond by Monday 1/29/07 since if we want to get something added to the agenda, we need to submit something before the end of the month. woody ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH MINOR] opensm: minor usage strings simplification
Minor usage string simplification - this helps to avoid warning with some version of vim c code analyzer. Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]> --- osm/opensm/main.c |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/osm/opensm/main.c b/osm/opensm/main.c index a63fbeb..0993441 100644 --- a/osm/opensm/main.c +++ b/osm/opensm/main.c @@ -217,12 +217,11 @@ show_usage(void) " SMPs.\n" " Without -maxsmps, OpenSM defaults to a maximum of\n" " 4 outstanding SMPs.\n\n" ); + printf( "-console [off|local" #ifdef ENABLE_OSM_CONSOLE_SOCKET - printf( "-console [off|local|socket]\n" -#else - printf( "-console [off|local]\n" + "|socket" #endif - " This option activates the OpenSM console. (default off)\n\n"); + "]\n This option activates the OpenSM console. (default off)\n\n"); #ifdef ENABLE_OSM_CONSOLE_SOCKET printf( "-console-port \n" " Specify an alternate telnet port for the console (default %d).\n\n", -- 1.5.0.rc2.g11a3 ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 1/2] rdma_cm: add support to join IPOIB multicast groups
On 1/24/07, Sean Hefty <[EMAIL PROTECTED]> wrote: > > The peer IPoIB would send an ARP and then would assume it can send its > > packets to the QP number provided in the arp reply, so it would be > > talking not with the rdma cm consumer but rather with the underlying > > IPoIB in this node. > > Okay - so you want to change the QPN from that given in the ARP? I missed > that > you wanted this, and I think I understand better what you're trying to do. we don't want to use the QPN from the arp reply but rather the sidr exchange etc as it is implemented in the rdma cm. > > no! it is broken since the PS_IPOIB ID/QP that joined/attached the > > multicast group is now using the ipoib broadcast qkey where the PS_UDP > > ID/QP is using the RDMA_UDP_QKEY > > I'm only trying to support communication within the same port space, not > between > them. Unicast is supported between different RDMA_PS_IPOIB QPs. working only within a port space makes sense. However, your patch does not allow for PS_IPOIB IDs to do unicast since some places in the cma kernel code only care for PS_UDP where they should care for PS_UDP OR PS_IPOIB as i did in my patch... > The question > is how to obtain the IB unicast address (i.e. QPN, etc.) for RDMA_PS_IPOIB. > My > assumption was that this capability wasn't needed, but you're saying that it > is. > I will update the patches. thanks, and again its fine to obtain the IB unicast address for PS_IPOIB IDs using the sidr exchange, you don't need to worry on the ARP result. Only make sure that PS_IPOIB uses the ipoib broadcast group qkey and also to what i mention above (code branching on PS_UDP where it should do so on PS_UDP or PS_IPOIB). thanks! Or. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 1/2] rdma_cm: add support to join IPOIB multicast groups
> The peer IPoIB would send an ARP and then would assume it can send its > packets to the QP number provided in the arp reply, so it would be > talking not with the rdma cm consumer but rather with the underlying > IPoIB in this node. Okay - so you want to change the QPN from that given in the ARP? I missed that you wanted this, and I think I understand better what you're trying to do. > no! it is broken since the PS_IPOIB ID/QP that joined/attached the > multicast group is now using the ipoib broadcast qkey where the PS_UDP > ID/QP is using the RDMA_UDP_QKEY I'm only trying to support communication within the same port space, not between them. Unicast is supported between different RDMA_PS_IPOIB QPs. The question is how to obtain the IB unicast address (i.e. QPN, etc.) for RDMA_PS_IPOIB. My assumption was that this capability wasn't needed, but you're saying that it is. I will update the patches. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 2/2 vex branch] IB/VNIC Fix failover delay issue
> thanks, I (finally) rolled these into my vex branch. Thanks Roland. But for some reason, I do not see the commit logs for these two patches in the vex branch, even though I can see from the code that the patches have been applied. (I can see the commit logs for the initial set of patches though). Any idea why ? ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] modules compilation status for OFED 1.2
We stay with same build process but the backport patches give a solution for such cases. Michael Tsirkin can help you how we solved such problems with other kernel code we needed. Tziporet -Original Message- From: Hoang-Nam Nguyen [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 24, 2007 10:03 PM To: Tziporet Koren Cc: Bryan O'Sullivan; EWG; [EMAIL PROTECTED]; OPENIB; [EMAIL PROTECTED] Subject: Re: [openfabrics-ewg] modules compilation status for OFED 1.2 Hi Tziporet! > ehca driver (Nam) - SLES9, Redhat EL4 up4, SLES10 SP1, 2.6.19 Backport for SLES9 and RHEL4.4/5 is doable only with a kernel patch in order to get ibmebus running, which is a prereq for ehca. Since ofed-1.1 build process compiles the components out of kernel tree, such one kernel patch is not possible. Will that change with ofed-1.2 build process? Regards Nam ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [openfabrics-ewg] modules compilation status for OFED 1.2
Hi Tziporet! > ehca driver (Nam) - SLES9, Redhat EL4 up4, SLES10 SP1, 2.6.19 Backport for SLES9 and RHEL4.4/5 is doable only with a kernel patch in order to get ibmebus running, which is a prereq for ehca. Since ofed-1.1 build process compiles the components out of kernel tree, such one kernel patch is not possible. Will that change with ofed-1.2 build process? Regards Nam ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] OFED 1.2 bug reporting
First version will be 1.2-alpha1 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Weitzenkamp (sweitzen) Sent: Wednesday, January 24, 2007 6:39 PM To: Steve Wise; openib-general Subject: Re: [openib-general] OFED 1.2 bug reporting I have added a version "1.2". Tziporet is the first build going to be called rc1 or something else? Scott > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steve Wise > Sent: Wednesday, January 24, 2007 6:41 AM > To: openib-general > Subject: [openib-general] OFED 1.2 bug reporting > > Should I be using the open fabrics bugzilla to open bugs against OFED > 1.2? If so, should a new 'version' be added for ofed-1.2? Right now > the only version that makes sense is 'gen2', but that doesn't really > cover bugs against backport code... > > > Steve. > > > > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 1/2] rdma_cm: add support to join IPOIB multicast groups
On 1/24/07, Or Gerlitz <[EMAIL PROTECTED]> wrote: > On 1/24/07, Sean Hefty <[EMAIL PROTECTED]> wrote: > > > However, it is possible that an RDMA_PS_IPOIB consumer would want to > > > talk over ---one-- UD QP with two peers: > > > 1) IPoIB - multicast traffic > > > 2) --another-- RDMA CM consumer - unicast traffic > > After the user joins the multicast group, unicast traffic is still > > supported. > no! it is broken since the PS_IPOIB ID/QP that joined/attached the > multicast group is now using the ipoib broadcast qkey where the PS_UDP > ID/QP is using the RDMA_UDP_QKEY OK, i have managed to confuse myself... with the patch you have sent PS_IPOIB ID does not does support unicast traffic so this all use scanrio is not possible from the first place. But, my preferation is not to block RDMA CM use patterns of UD unicast to UD unicast and UD unicast to UD unicast/multicast etc. Or. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 1/2] rdma_cm: add support to join IPOIB multicast groups
On 1/24/07, Sean Hefty <[EMAIL PROTECTED]> wrote: > > However, it is possible that an RDMA_PS_IPOIB consumer would want to > > talk over ---one-- UD QP with two peers: > > > > 1) IPoIB - multicast traffic > > 2) --another-- RDMA CM consumer - unicast traffic > My thinking on this was that path record lookup and SIDR resolution isn't part > of the ipoib protocol, and I wanted to limit the scope of the patch. indeed they are not part of the ipoib protocol, but the reason there interop is not possible between PS_IPOIB ID/QP to peer node IPoIB UD - is much more simple - as of IPoIB address resolution... The peer IPoIB would send an ARP and then would assume it can send its packets to the QP number provided in the arp reply, so it would be talking not with the rdma cm consumer but rather with the underlying IPoIB in this node. On the other direction you are correct, IPoIB does not listen for SIDR requests. > After the user joins the multicast group, unicast traffic is still supported. no! it is broken since the PS_IPOIB ID/QP that joined/attached the multicast group is now using the ipoib broadcast qkey where the PS_UDP ID/QP is using the RDMA_UDP_QKEY > The issue I see is whether the rdma_cm uses address resolution (which ends up > being IP ARP), an SA query, and SIDR to resolve the remote QPN, or if it can > obtain it through some other method. A possible fallback to RDMA CM consumer is: issue ARP, then send SIDR - if there is no response use the IPoIB QP from the ARP reply and the ipv4 broadcast qkey to talk directly with IPoIB. However, as i mention above this hack is not possible in the other direction, that is you can't make IPoIB do unicast talking with PS_IPOIB consumer. Or. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 1/2] rdma_cm: add support to join IPOIB multicast groups
> However, it is possible that an RDMA_PS_IPOIB consumer would want to > talk over ---one-- UD QP with two peers: > > 1) IPoIB - multicast traffic > 2) --another-- RDMA CM consumer - unicast traffic My thinking on this was that path record lookup and SIDR resolution isn't part of the ipoib protocol, and I wanted to limit the scope of the patch. After the user joins the multicast group, unicast traffic is still supported. The issue I see is whether the rdma_cm uses address resolution (which ends up being IP ARP), an SA query, and SIDR to resolve the remote QPN, or if it can obtain it through some other method. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RDMA CM multicast
On Wed, 2007-01-24 at 13:13, Sean Hefty wrote: > > Doesn't this carve a hole in the IPv6 (multicast) address space (group > > ID) ? If so, is that a hole we can carve out ? > > I don't think that this causes any issues that weren't previously there. > IPOIB > maps an IPv6 address into 80-bits, so not every IPv6 address can be mapped > into > an MGID using the ipoib algorithm. I forgot about this. > What the rdma_cm needs to determine is whether the sockaddr passed into > rdma_join_multicast is an IPv6 address that needs to be translated into an > MGID, > or whether the address is itself an MGID. I guess that it might be able to > look > at the address to see if it matches the SA created MGID format > (0xff1?a01b...). Makes sense. -- Hal > - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] ib_addr: Handle Ethernet neighbour updates during route resolution.
On 1/24/07, Steve Wise <[EMAIL PROTECTED]> wrote: > Handle Ethernet neighbour updates during route resolution. > The IWCM uses the ib_addr services to do route resolution (neighbour > discovery in the IP world). The ib_addr netevent callback routine, > however, currently only acts on Inifininband neighbour updates. It needs > to act on ethernet neighbour updates as well. > This patch just removes filtering on device type altogether and > will trigger on any neighour updates where the nud_type is valid. > This simplifies the code some. OK, as I have mentioned in the past there is a check in the fast path xmit code of IPoIB to verify that the neighbour we are using now to xmit (skb->neigh) has not changed its HA address since the last time IPoIB xmit-ed with it - that is that the GID in the struct neighbous->ha is the same as the GID in struct ipoib_neigh. Such a diff happens when the kernel is acting to gratitius arp - that is a remote peer has changed its HW address (eg as of fail-over of an IP address from one IPoIB NIC to another IPoIB NIC - eg with bonding). >From this patch i understand that we can register to the neighbour change event in IPoIB and eliminate the run time check !?!?!? Or. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RDMA CM multicast
On 1/24/07, Sean Hefty <[EMAIL PROTECTED]> wrote: > What would be needed is a way for the user to indicate that they need a unique > address. An obvious way to accomplish this is for the user to specify an IP > address of 0.0.0.0 when calling rdma_join_multicast(). The user would first > need to bind to a specific device by calling rdma_bind_addr() with a local IP > address. > Your code would look something like this: > rdma_bind_addr(local IP address) > rdma_join_multicast(0.0.0.0, port 0)<- exchange group info out of band > rdma_join_multicast(0.0.0.0, port 1)<- exchange group info out of band > send data to a lot of nodes at once > rdma_leave_multicast(0.0.0.0, port 0) > rdma_leave_multicast(0.0.0.0, port 1) Sean, This seems to me as a little bit of over engineering... since we do require that to use the RDMA CM the consumers must have a functional IPoIB NIC (so they can call rdma_bind_addrress to resolve the device/port/pkey) we can add another requirement to have the sys admin configure their routing such that some multicast IP subnet (eg net 224.0.0.0 mask 255.0.0.0) is routed to the IPoIB NIC. Once this routing is in place, the only thing they need is to enhance the MPI job starter/etc to allocate to each job (say) two unique multicast --IP-- addresses on the relevant subnet and provide these IP addresses to each rank. Now the rank can use the RDMA CM without any hack. Or. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] ib_addr: Handle Ethernet neighbour updates during route resolution.
Looks good to me.
Acked-by: Sean Hefty <[EMAIL PROTECTED]>
Steve Wise wrote:
> Handle Ethernet neighbour updates during route resolution.
>
> The IWCM uses the ib_addr services to do route resolution (neighbour
> discovery in the IP world). The ib_addr netevent callback routine,
> however, currently only acts on Inifininband neighbour updates. It needs
> to act on ethernet neighbour updates as well.
>
> This patch just removes filtering on device type altogether and
> will trigger on any neighour updates where the nud_type is valid.
> This simplifies the code some.
>
> Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
> ---
>
> drivers/infiniband/core/addr.c |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
> index af93979..d2bb5a9 100644
> --- a/drivers/infiniband/core/addr.c
> +++ b/drivers/infiniband/core/addr.c
> @@ -360,8 +360,7 @@ static int netevent_callback(struct noti
> if (event == NETEVENT_NEIGH_UPDATE) {
> struct neighbour *neigh = ctx;
>
> - if (neigh->dev->type == ARPHRD_INFINIBAND &&
> - (neigh->nud_state & NUD_VALID)) {
> + if (neigh->nud_state & NUD_VALID) {
> set_timeout(jiffies);
> }
> }
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RDMA CM multicast
> Doesn't this carve a hole in the IPv6 (multicast) address space (group > ID) ? If so, is that a hole we can carve out ? I don't think that this causes any issues that weren't previously there. IPOIB maps an IPv6 address into 80-bits, so not every IPv6 address can be mapped into an MGID using the ipoib algorithm. What the rdma_cm needs to determine is whether the sockaddr passed into rdma_join_multicast is an IPv6 address that needs to be translated into an MGID, or whether the address is itself an MGID. I guess that it might be able to look at the address to see if it matches the SA created MGID format (0xff1?a01b...). - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 1/2] rdma_cm: add support to join IPOIB multicast groups
On 1/24/07, Sean Hefty <[EMAIL PROTECTED]> wrote: > > However, it will not support "mixed mode" communication patterns (which > > you were raising last week) that is one app having a UD QP for both > > multicast and unicast that talks with two "peers" IPoIB multicast and > > another app doing only unicast. > Separating ipoib to its own port space alleviated my concerns on existing > usage. > The RDMA_PS_UDP continues operating as before, with mixed mode traffic > supported. Mixed mode for RDMA_PS_IPOIB is not supported, since it's not > clear > to me how that would be used. The IPOIB protocol doesn't use SIDR, so I'm > hesitant to extend the capabilities until there's a clear need/use. Indeed, it is not possible to have UDP --unicast-- interop between "IPoIB UD" (ie not IPoIB CM) and an RDMA_PS_IPOIB RDMA CM consumer. However, it is possible that an RDMA_PS_IPOIB consumer would want to talk over ---one-- UD QP with two peers: 1) IPoIB - multicast traffic 2) --another-- RDMA CM consumer - unicast traffic since both talks are over the same QP everyone must use the same --QKEY--, now since RDMA_PS_IPOIB does not support the SIDR exchange this config is broken. The patch i have sent allows this, and it can be really nice to remove this restriction with some documentation explaining the restrictions. > > Also, just a clarification - how exactly the patch enforces that an app > > would not be able to do listen/connect/accept on RDMA_PS_IPOIB ID??? > This is not enforce directly yet. (It just requires an if statement in > resolve > route.) I would expect that if it were tried, there would be a failure at > some > point. OK, that (failure at some point) was my thought as well. Or. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RDMA CM multicast
>>Is this how it works with sockets? > > > I'm not aware of IP multicast having this functionality. This is a > major problem with IP multicast, as some sort of address selection > arbitration has to be done. From what I've seen, this ranges from IANA > assigning multicast addresses for specific uses to best-effort protocols > for selecting unused addresses from an available range. It's a fairly > hard problem, and having OFED choose an unused address (my understanding > is that the SM is capable of this) sidesteps the issue and makes life > much better. This is an IB specific feature that could be exposed through the rdma_cm. I can envision other RDMA transports providing a similar capability, even if it requires some sort of proprietary method. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 1/2] rdma_cm: add support to join IPOIB multicast groups
> However, it will not support "mixed mode" communication patterns (which > you were raising last week) that is one app having a UD QP for both > multicast and unicast that talks with two "peers" IPoIB multicast and > another app doing only unicast. Separating ipoib to its own port space alleviated my concerns on existing usage. The RDMA_PS_UDP continues operating as before, with mixed mode traffic supported. Mixed mode for RDMA_PS_IPOIB is not supported, since it's not clear to me how that would be used. The IPOIB protocol doesn't use SIDR, so I'm hesitant to extend the capabilities until there's a clear need/use. > Also, just a clarification - how exactly the patch enforces that an app > would not be able to do listen/connect/accept on RDMA_PS_IPOIB ID??? This is not enforce directly yet. (It just requires an if statement in resolve route.) I would expect that if it were tried, there would be a failure at some point. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [Bug 322] New: 2.6.17 backport: reading the rdma-cm abi file causes fault.
https://bugs.openfabrics.org/show_bug.cgi?id=322
Summary: 2.6.17 backport: reading the rdma-cm abi file causes
fault.
Product: OpenFabrics Linux
Version: 1.2
Platform: X86-64
OS/Version: SLES 10
Status: NEW
Severity: normal
Priority: P3
Component: RDMA CM
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I think the misc device patch is broken for 2.6.17. Everything builds and
loads ok, but when librdmacm (or a user) reads
/sys/class/misc/rdma_cm/abi_file, the system logs this fault:
[62266.670174] invalid opcode: [1] SMP
[62266.682226] CPU 0
[62266.688276] Modules linked in: rdma_ucm nfs lockd nfs_acl sunrpc rdma_cm
iw_cm ib_addr ib_local_sa ib_ucm ib_uverbs ib_umad iw_cxgb3 ib_ipoib ib_cm
ib_sa edd button battery ac cxgb3 ib_mthca ib_mad shpchp ib_core pci_hotplug
i2c_i801 e1000 rdma_ne i2c_core fan thermal processor aic79xx
[62266.764826] Pid: 16190, comm: cat Tainted: GF 2.6.17-ofed-1.2 #3
[62266.783832] RIP: 0010:[] []
[62266.801073] RSP: 0018:81011f273eb0 EFLAGS: 00010203
[62266.817510] RAX: 0002 RBX: 8101421bd848 RCX:
0001
[62266.838855] RDX: RSI: 810103c558f6 RDI:
810083c558f9
[62266.860199] RBP: 8041508e R08: R09:
0020
[62266.881542] R10: R11: R12:
81013dd5f138
[62266.902887] R13: 81013dd5f158 R14: 81011f273f48 R15:
805b18f0
[62266.924232] FS: 2abb806756d0() GS:806e5000()
knlGS:
[62266.948431] CS: 0010 DS: ES: CR0: 8005003b
[62266.965621] CR2: 00402f30 CR3: 000123782000 CR4:
06e0
[62266.986966] Process cat (pid: 16190, threadinfo 81011f272000, task
810144814850)
[62267.011165] Stack: 802bddb6 1000
0050a000
[62267.034690]810083c55908 881d7fa0 8101424ea400
0050a000
[62267.058787]81011f273f48 1000
[62267.074003] Call Trace: {sysfs_read_file+193}
[62267.091845]{vfs_read+204}
{sys_read+71}
[62267.114927]{system_call+126}
[62267.130946]
[62267.130947] Code: 27 1f 01 81 ff ff 13 f5 27 80 ff ff ff ff 00 a4 4e 42 01
81
[62267.157535] RIP [] RSP
--
Configure bugmail: https://bugs.openfabrics.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] IPOIB CM with Non SRQ support
Michael, I am working on a prototype based on your IPOIB CM patch to incorporate support for Non SRQ as well. IPOIB CM was planned to be in OFED 1.2 if I remember correctly. If I were to submit a patch for non SRQ support, what would be the cut off date to make it into OFED 1.2? Pradeep [EMAIL PROTECTED]___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 0/6] osm: QoS policy parser
Hi Yevgeny, On 16:10 Wed 24 Jan , Yevgeny Kliteynik wrote: > Hi Hal, Sasha. > > Here's a description of the QoS policy file, and an > example of such file (with more comments inside). > > QoS Policy file > --- > > The QoS policy file is divided into 4 sub sections: > > * Node Group: a set of HCAs, Routers or Switches that share the same > settings. > A node groups might be a partition defined by the partition manager policy > in > terms of GUIDs. Future implementations might provide support for > NodeDescription > based definition of node groups. > In the discussion following RFC (available in ML archive), we talked about to make port groups definition separate from QoS, so it could be sharable between different OpenSM components (like QoS and Partition manager). Any reason why it was not done? Sasha > * Fabric Setup: > Defines how the SL2VL and VLArb tables should be setup. This policy > definition > assumes the computation of target behavior should be performed outside of > OpenSM. > > * QoS-Levels Definition: > This section defines the possible sets of parameters for QoS that a client > might > be mapped to. Each set holds: SL and optionally: Max MTU, Max Rate, Path > Bits > (in case LMC > 0 is used for QoS) and TClass. > > * Matching Rules: > A list of rules that match an incoming PathRecord request to a QoS-Level. > The > rules are processed in order such as the first match is applied. Each rule > is > built out of set of match expressions which should all match for the rule > to > apply. The matching expressions are defined for the following fields > - SRC and DST to lists of node groups > - Service-ID to a list of Service-ID or Service-ID ranges > - TClass to a list of TClass values or ranges > > QoS policy file example > --- > > > > > > > > Storage > our SRP storage targets > 0x1001 > 0x1002 > > > > Virtual Servers > node desc and IB port # > vs1/HCA-1/P1 > vs3/HCA-1/P1 > vs3/HCA-2/P1 > > > > Partition 1 > default settings > Part1 > > > > Routers > all routers > ROUTER > > > > > > > > > Part1 > * > * > > 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,7 > > > > Storage > > Storage2 > > Storage3 I guess "across-from" and "across-to" include all ports on the path. What shoud hapen in case of configuration "overlap"? > * > 1 > 0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0 > > > > > > > > Storage > > > 0:255,1:127,2:63,3:31,4:15,5:7,6:3,7:1 > 8:255,9:127,10:63,11:31,12:15,13:7,14:3 > 10 > > > > > > > > 1 > for the lowest priority comm > 16 > > > > 2 > low latency best bandwidth > 0 > 7 > > > > 3 > just an example > 0 > 32 > 1 > 1 > > > > > > > > 1 > low latency by class 7-9 or 11 > 7-9,11 > 1 > > > > 2 > Storage targets connection> > Storage > 22,4719 > 3 > > > > > > > > -- Yevgeny > > Yevgeny Kliteynik wrote: > > Hi Sasha, > > > > Sasha Khapyorsky wrote: > >> On 10:46 Sun 21 Jan , Yevgeny Kliteynik wrote: > >>> Hi Sasha. > >>> > >>> Sasha Khapyorsky wrote: > Hi Yevgeny, > > On 17:01 Wed 17 Jan , Yevgeny Kliteynik wrote: > > Hi Hal > > > > The following series of six patches implements QoS policy file parser: > > > > 1. QoS parser Lex file > > 2. QoS parser Lex-generated c file > > 3. QoS parser grammar (Yacc) file > > 4. QoS parser Yacc-generated grammar c and h file > > 5. QoS parser header file that defines parse tree data structures > > 6. Changes in makefiles and configure.in file for compiling QoS parser > > files > Is there any description of proposed format and functionality? > >>> The parser is based on QoS RFC sent by Eitan in May 2006, with a few > >>> minor modifications. You can find the RFC here: > >>> h
Re: [openib-general] OFED 1.2 bug reporting
I have added a version "1.2". Tziporet is the first build going to be called rc1 or something else? Scott > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steve Wise > Sent: Wednesday, January 24, 2007 6:41 AM > To: openib-general > Subject: [openib-general] OFED 1.2 bug reporting > > Should I be using the open fabrics bugzilla to open bugs against OFED > 1.2? If so, should a new 'version' be added for ofed-1.2? Right now > the only version that makes sense is 'gen2', but that doesn't really > cover bugs against backport code... > > > Steve. > > > > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]
On 17:33 Wed 24 Jan , Yevgeny Kliteynik wrote: > Hi Hal, > > Hal Rosenstock wrote: > > Hi Yevgeny, > > > > On Wed, 2007-01-24 at 01:26, Yevgeny Kliteynik wrote: > >> Hi Hal, > >> > >> Hal Rosenstock wrote: > >>> Hi again Yevgeny, > >>> > >>> On Tue, 2007-01-23 at 11:20, Yevgeny Kliteynik wrote: > Hi Hal, > > Hal Rosenstock wrote: > > Hi Yevgeny, > > > > On Sun, 2007-01-21 at 04:17, Yevgeny Kliteynik wrote: > >> Sasha Khapyorsky wrote: > >>> On 18:24 Thu 11 Jan , Yevgeny Kliteynik wrote: > As for the mailing list it's [EMAIL PROTECTED] You can access > it here: http://openib.org/mailman/listinfo/openib-windows > >>> I found only references to svn://windows.openib.org, where > >>> 'svn log svn://windows.openib.org/gen1/trunk/ulp/opensm/user/opensm | > >>> head -n 40' shows: > >>> > >>> > >>> r474 | sleybo | 2006-08-31 11:57:19 +0300 (Thu, 31 Aug 2006) | 1 line > >>> > >>> Set property svn:keywords "id" on all repository > >>> > >>> r472 | sleybo | 2006-08-31 11:08:18 +0300 (Thu, 31 Aug 2006) | 1 line > >>> > >>> [OPENSM] When running as a service, if all ports are down, use the > >>> first port. > >>> > >>> r460 | sleybo | 2006-08-20 16:55:49 +0300 (Sun, 20 Aug 2006) | 3 lines > >>> > >>> [OPENSM] When trying to set to INIT the remote port of the given > >>> physical port > >>> in function __osm_lid_mgr_set_remote_pi_state_to_init, there was no > >>> check whether the physical port in null (e.g., if it's disconnected). > >>> > >>> r458 | tzachid | 2006-08-17 11:12:37 +0300 (Thu, 17 Aug 2006) | 1 line > >>> > >>> [opensm] Base service status on results that were received from > >>> opensm log messages. > >>> > >>> r410 | leonidk | 2006-07-09 20:56:01 +0300 (Sun, 09 Jul 2006) | 1 line > >>> > >>> [OPENSM] missed fix for OPENSM logging to System Event Log > >>> > >>> r402 | leonidk | 2006-07-05 16:19:23 +0300 (Wed, 05 Jul 2006) | 5 > >>> lines > >>> > >>> [OPENSM] 1. feature: added SHUT_DOWN support. Without that one can't > >>> perform reboot with opensm running as service ! > >>> 2. bugfix: added message file for correct logging to System Event Log. > >>> 3. bugfix: wrong passing parameters in server mode; > >>> 4. bugfix: error in table of parameters > >>> > >>> > >>> r366 | tzachid | 2006-05-28 14:49:08 +0300 (Sun, 28 May 2006) | 1 line > >>> > >>> [opensm] Fix a trivial build break > >>> > >>> r361 | eitan | 2006-05-23 13:07:09 +0300 (Tue, 23 May 2006) | 3 lines > >>> > >>> if the guid2lid is corrupted, don't exit when running with -y option > >>> (don't exit on fatal) - just ignore the file > >>> > >>> > >>> > >>> Seems that development there was stopped in Aug 2006, and it doesn't > >>> have recent Win port patches. Am I looking in the wrong place? > >> You were looking in the right place. It appears that I didn't describe > >> the development process correctly. I think this repository is updated > >> with stable OSM versions, after the code is tested. > > Any idea on when the next version is expected ? > The SVN will be updated in a couple of days. > >>> Glad to hear it. To what OpenSM version will it correspond ? Will it be > >>> based on OFED 1.1 or beyond ? What OpenIB svn or git commit does it > >>> correspond to ? Thanks. > >> > >> The local SVN repository is syncronized with OpenSM GIT repository > >> (head of master), and the changes from git are merged into the svn daily. > >> This local SVN will be uploaded to the SVN repository on the web. > > > > How frequently ? Is there only the released OpenSM version on the web ? > > Why not a work in progress one as well ? Wouldn't that help get more > > early testing in the Windows environment ? > > There's no defined procedure on when should the svn on the web should > be updated. This daily synchronization with OpenSM is pretty new, so > I guess some sort of procedure will be defined soon. This should be clear for the projects which called "open source". Isn't it? > As for the testing - the local version of SM (the one that is synchronized > with OpenSM) is tested nightly on windows machines. By "the local version of SM" you actually mean not published mainstream devel
Re: [openib-general] [PATCH 0/6] osm: QoS policy parser
Hi Yevgeny, On Wed, 2007-01-24 at 09:15, Yevgeny Kliteynik wrote: [snip...] > > I also have some questions about the patches > > Shoot First, as I understand it, this higher level QoS is not yet an approved standard (annex) so is this code experimental ? In any case, some things might change, etc. so IMO this QoS should be implemented in a way that minimizes the risk to the non QoS code. I suspect the main interactions are in osm_sa_path/multipath_record.c but will also extend to the QoS manager. So should this all be conditionalized with something like QOS_ANNEX and by default be off with some build switch to enable this code in OpenSM until be becomes standard ? When will the remainder of the changes to the QoS manager be ready ? It would be good to see the whole picture. Are there any other missing pieces ? It would be good to have some documentation for this including an opensm man page update. As far as using lex/yacc, are they invoked as part of the build procedure or are the files they generate just checked in and used ? How could/would multiple file versions be supported ? One previous example was a mention that port groups can be shared by more than one manager (e.g. QoS and partitions) so this might be made hierarchical. I'd like to understand this before we get locked in. There are some other lower level questions which I'll get to later. I'll also review the XML file format in detail later. -- Hal ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] OFED 1.2 RPMs
On Wed, 2007-01-24 at 09:40 -0600, Steve Wise wrote: > What do I need to do to get the Chelsio code into the RPM packaging? > The wiki doesn't say much yet about rpms. I see file > ofed_1_2/ofed_scripts/openib.spec. Should I add the chelsio stuff to > that spec file? > > > Thanks, > > Steve. > Hi Steve, I am going to split openib.spec file into ofa_user.spec and ofa_kernel.spec. Then I will add Chelsio and all other packages to these files. This will happen next week, I hope. -- Vladimir Sokolovsky <[EMAIL PROTECTED]> Mellanox Technologies Ltd. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] The neigh_setup patch for upstream
Hi,
This is the upstream version of the patch that I sent in for OFED.
Please comment.
thanks
- MoniS
IPoIB uses a two layer neighboring scheme, such that for each struct neighbour
whose device is an ipoib one, there is a struct ipoib_neigh buddy which is
created on demand at the tx flow by an ipoib_neigh_alloc(skb->dst->neighbour)
call.
When using the bonding driver, neighbours are created by the net stack on behalf
of the bonding (master) device. On the tx flow the bonding code gets an skb such
that skb->dev points to the master device, it changes this skb to point on the
slave device and calls the slave hard_start_xmit function.
Combing these two flows, there is a hole if some code at ipoib
(ipoib_neigh_destructor) assumes that for each struct neighbour it gets, n->dev
is an ipoib device so for example netdev_priv(n->dev) would be of type struct
ipoib_dev_priv.
To fix it, this patch adds a dev field to struct ipoib_neigh which is used
instead of the struct neighbour dev one.
Signed-off-by: Moni Shoua <[EMAIL PROTECTED]>
Signed-off-by: Or Gerlitz <[EMAIL PROTECTED]>
---
ipoib.h |4 +++-
ipoib_main.c | 23 +--
ipoib_multicast.c |2 +-
3 files changed, 17 insertions(+), 12 deletions(-)
Index: infiniband/drivers/infiniband/ulp/ipoib/ipoib.h
===
--- infiniband.orig/drivers/infiniband/ulp/ipoib/ipoib.h2007-01-22
12:11:25.0 +0200
+++ infiniband/drivers/infiniband/ulp/ipoib/ipoib.h 2007-01-22
12:18:06.101698456 +0200
@@ -216,6 +216,7 @@ struct ipoib_neigh {
struct sk_buff_head queue;
struct neighbour *neighbour;
+ struct net_device *dev;
struct list_headlist;
};
@@ -232,7 +233,8 @@ static inline struct ipoib_neigh **to_ip
INFINIBAND_ALEN, sizeof(void *));
}
-struct ipoib_neigh *ipoib_neigh_alloc(struct neighbour *neigh);
+struct ipoib_neigh *ipoib_neigh_alloc(struct neighbour *neigh,
+ struct net_device *dev);
void ipoib_neigh_free(struct net_device *dev, struct ipoib_neigh *neigh);
extern struct workqueue_struct *ipoib_workqueue;
Index: infiniband/drivers/infiniband/ulp/ipoib/ipoib_main.c
===
--- infiniband.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c 2007-01-22
12:11:33.0 +0200
+++ infiniband/drivers/infiniband/ulp/ipoib/ipoib_main.c2007-01-22
12:34:57.599156580 +0200
@@ -490,7 +490,7 @@ static void neigh_add_path(struct sk_buf
struct ipoib_path *path;
struct ipoib_neigh *neigh;
- neigh = ipoib_neigh_alloc(skb->dst->neighbour);
+ neigh = ipoib_neigh_alloc(skb->dst->neighbour, skb->dev);
if (!neigh) {
++priv->stats.tx_dropped;
dev_kfree_skb_any(skb);
@@ -769,32 +769,34 @@ static void ipoib_set_mcast_list(struct
static void ipoib_neigh_destructor(struct neighbour *n)
{
struct ipoib_neigh *neigh;
- struct ipoib_dev_priv *priv = netdev_priv(n->dev);
+ struct ipoib_dev_priv *priv;
unsigned long flags;
struct ipoib_ah *ah = NULL;
- ipoib_dbg(priv,
- "neigh_destructor for %06x " IPOIB_GID_FMT "\n",
- IPOIB_QPN(n->ha),
- IPOIB_GID_RAW_ARG(n->ha + 4));
-
- spin_lock_irqsave(&priv->lock, flags);
neigh = *to_ipoib_neigh(n);
if (neigh) {
+ priv = netdev_priv(neigh->dev);
+ ipoib_dbg(priv,
+ "neigh_destructor for %06x " IPOIB_GID_FMT "\n",
+ IPOIB_QPN(n->ha),
+ IPOIB_GID_RAW_ARG(n->ha + 4));
+
+ spin_lock_irqsave(&priv->lock, flags);
if (neigh->ah)
ah = neigh->ah;
list_del(&neigh->list);
ipoib_neigh_free(n->dev, neigh);
+ spin_unlock_irqrestore(&priv->lock, flags);
}
- spin_unlock_irqrestore(&priv->lock, flags);
if (ah)
ipoib_put_ah(ah);
}
-struct ipoib_neigh *ipoib_neigh_alloc(struct neighbour *neighbour)
+struct ipoib_neigh *ipoib_neigh_alloc(struct neighbour *neighbour,
+ struct net_device *dev)
{
struct ipoib_neigh *neigh;
@@ -803,6 +805,7 @@ struct ipoib_neigh *ipoib_neigh_alloc(st
return NULL;
neigh->neighbour = neighbour;
+ neigh->dev = dev;
*to_ipoib_neigh(neighbour) = neigh;
skb_queue_head_init(&neigh->queue);
Index: infiniband/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
===
--- infiniband.orig/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
2007-01-22 12:11:25.0 +0200
+++ infiniband/drivers/i
Re: [openib-general] Add bonding suuport to OFED
Hi, Vlad, Can you please pull this to OFED-1.2? I guess this requires some changes in the build scripts and configuration files. I'd be happy to help and any way I can to help with that. Please let me know. thanks - MoniS Moni Shoua wrote: > Originally, bonding is a High Availability solution for Ethernet network > interfaces. > It is a module that implements a virtual network device (not bounded to > hardware) and enslaves "real" devices. Bonding device controls its slaves > according > to the bonding policy and the slave's health. > > I am adding a bonding device which is good for IPoIB interfaces. Feel free to > install it > send comments. > > You just have to build source RPM, rebuild it and install the binary. > > For now, I have tested the module under RH4-UP3 and SLES10 with OFED-1.1. > > HOW TO BUILD THE SOURCE RPM > === > git clone git://staging.openfabrics.org/~monis/ofed-bond-pkg.git mydir > cd mydir/ > ./build_rpm.sh > ./build_rpm.sh OR ./build_rpm.sh --git-url > > > After installing the binary RPM read the instructions in > /usr/local/ofed/docs/ib-bonding.txt > > Note: Using ib-bonding requires applying a patch for IPoIB and replacing > ib_ipoib.ko. Please find the patch in the following message. > Please also note that the patch should be applied after > ipoib_8111_to_2_6_16.patch. > > - MoniS > > > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general > > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] modules compilation status for OFED 1.2
Hi All, We are approaching code freeze and I want to make sure that all kernel modules indeed will compile on the supported OSes of OFED 1.2: * Redhat EL4 up5 (currently tested on up4) * Redhat EL5 - if will be available * SLES9 SP3 * SLES10 SP1 * kernel.org: 2.6.19.x and 2.6.20.x The status is that all modules (except ehca) pass compilation on kernel 2.6.19. The following modules have issues with support for some distros: * vnic (Ram) - SLES9 * ipath driver (Bryan) : SLES9, Redhat EL4 up4, SLES10 SP1 * ehca driver (Nam) - SLES9, Redhat EL4 up4, SLES10 SP1, 2.6.19 Owners of these modules: Please take an action to fix as soon as possible or reply if you don't want your module to be supported on some of the distros Thanks, Tziporet ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] OFED 1.2 RPMs
What do I need to do to get the Chelsio code into the RPM packaging? The wiki doesn't say much yet about rpms. I see file ofed_1_2/ofed_scripts/openib.spec. Should I add the chelsio stuff to that spec file? Thanks, Steve. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]
Hi Hal, Hal Rosenstock wrote: > Hi Yevgeny, > > On Wed, 2007-01-24 at 01:26, Yevgeny Kliteynik wrote: >> Hi Hal, >> >> Hal Rosenstock wrote: >>> Hi again Yevgeny, >>> >>> On Tue, 2007-01-23 at 11:20, Yevgeny Kliteynik wrote: Hi Hal, Hal Rosenstock wrote: > Hi Yevgeny, > > On Sun, 2007-01-21 at 04:17, Yevgeny Kliteynik wrote: >> Sasha Khapyorsky wrote: >>> On 18:24 Thu 11 Jan , Yevgeny Kliteynik wrote: As for the mailing list it's [EMAIL PROTECTED] You can access it here: http://openib.org/mailman/listinfo/openib-windows >>> I found only references to svn://windows.openib.org, where >>> 'svn log svn://windows.openib.org/gen1/trunk/ulp/opensm/user/opensm | >>> head -n 40' shows: >>> >>> >>> r474 | sleybo | 2006-08-31 11:57:19 +0300 (Thu, 31 Aug 2006) | 1 line >>> >>> Set property svn:keywords "id" on all repository >>> >>> r472 | sleybo | 2006-08-31 11:08:18 +0300 (Thu, 31 Aug 2006) | 1 line >>> >>> [OPENSM] When running as a service, if all ports are down, use the >>> first port. >>> >>> r460 | sleybo | 2006-08-20 16:55:49 +0300 (Sun, 20 Aug 2006) | 3 lines >>> >>> [OPENSM] When trying to set to INIT the remote port of the given >>> physical port >>> in function __osm_lid_mgr_set_remote_pi_state_to_init, there was no >>> check whether the physical port in null (e.g., if it's disconnected). >>> >>> r458 | tzachid | 2006-08-17 11:12:37 +0300 (Thu, 17 Aug 2006) | 1 line >>> >>> [opensm] Base service status on results that were received from opensm >>> log messages. >>> >>> r410 | leonidk | 2006-07-09 20:56:01 +0300 (Sun, 09 Jul 2006) | 1 line >>> >>> [OPENSM] missed fix for OPENSM logging to System Event Log >>> >>> r402 | leonidk | 2006-07-05 16:19:23 +0300 (Wed, 05 Jul 2006) | 5 lines >>> >>> [OPENSM] 1. feature: added SHUT_DOWN support. Without that one can't >>> perform reboot with opensm running as service ! >>> 2. bugfix: added message file for correct logging to System Event Log. >>> 3. bugfix: wrong passing parameters in server mode; >>> 4. bugfix: error in table of parameters >>> >>> >>> r366 | tzachid | 2006-05-28 14:49:08 +0300 (Sun, 28 May 2006) | 1 line >>> >>> [opensm] Fix a trivial build break >>> >>> r361 | eitan | 2006-05-23 13:07:09 +0300 (Tue, 23 May 2006) | 3 lines >>> >>> if the guid2lid is corrupted, don't exit when running with -y option >>> (don't exit on fatal) - just ignore the file >>> >>> >>> >>> Seems that development there was stopped in Aug 2006, and it doesn't >>> have recent Win port patches. Am I looking in the wrong place? >> You were looking in the right place. It appears that I didn't describe >> the development process correctly. I think this repository is updated >> with stable OSM versions, after the code is tested. > Any idea on when the next version is expected ? The SVN will be updated in a couple of days. >>> Glad to hear it. To what OpenSM version will it correspond ? Will it be >>> based on OFED 1.1 or beyond ? What OpenIB svn or git commit does it >>> correspond to ? Thanks. >> >> The local SVN repository is syncronized with OpenSM GIT repository >> (head of master), and the changes from git are merged into the svn daily. >> This local SVN will be uploaded to the SVN repository on the web. > > How frequently ? Is there only the released OpenSM version on the web ? > Why not a work in progress one as well ? Wouldn't that help get more > early testing in the Windows environment ? There's no defined procedure on when should the svn on the web should be updated. This daily synchronization with OpenSM is pretty new, so I guess some sort of procedure will be defined soon. As for the testing - the local version of SM (the one that is synchronized with OpenSM) is tested nightly on windows machines. -- Yevgeny > -- Hal > >> -- Yevgeny >> >>> -- Hal >>> -- Yevgeny > -- Hal > >> If you need more details, I think it's better for you to ask windows >> folks >> directly, since as we see, my knowledge in this area is very limited. >> >> -- Yevgeny >> >>> Sasha >>> >> ___ >> openib-general mailing l
Re: [openib-general] [PATCH] IB/ipoib: Add field dev to struct ipoib_neigh
Michael S. Tsirkin wrote: >>> >>>Just to clarify - you previously mentionned you saw problems with 2.6.16 >>>backport. Is this an issue you see with 2.6.20 as well? >> >>Yes, the same thing happens with kernel 2.6.20. However, the patch for 2.6.20 >>looks a little bit different. I will post it today or tommorow. > > > Let's see that first. I prefer to first look at upstream code, then think > about backporting. > OK, I will post this patch today. > But this would hardly help if ipoib module is unloaded while neighbour > for bonding device is still around and has a pointer to > ipoib_neigh_destructor. > > >>For later kernels, bond device "borrows" the slave's neigh_setup >>function in the bond's setup function. >> >> ==> bond_dev->neigh_setup = slave_dev->neigh_setup; >> >>So even if the beighbour points to bond device the >>ipoib_neigh_destructor will be called. > > > Same applies here. > This is a good point. The right solution in my opinion is to enforce a correct order of unloading the modules. First bonding and than IPoIB. We still have to think how do we want to implement this. > Further, in both cases, it seems that accessing data at to_ipoib_neigh on a > neighbour for > non-ipoib device can cause a crash if hardware address is !=0 at offset 20. > I don't see such risk. the ipoib_neigh_destructor is called only for neighbours that were passed as an argument to ipoib_neigh_alloc (for kernels <= 2.6.16) or for devices that set their neigh_setup function to ipoib_neigh_setup_dev (for bigger kernels). The only one (besides IPoIB of course) that does that is bonding and bonding cannot enslave devices of different types. So, once bonding sets its neigh_setup to ipoib_neigh_setup_dev, it means it enslaves an IPoIB device and won't enslave devices of other types. However, it might be good idea to change the condition in bonding to "borrow" the neigh_setup function. Currently it is (slave_type != Ethernet) but should be (slave_type == IPoIB). ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH RFC ] ofed_1_2 simulate neighbour update events by snooping ARP packets
> > > > I'd prefer not to have a new module rdma_ne. Scripts need to be written to > > install it, > > and making these kernel dependent is a big pain. > > Can we continue keeping it in ib_core? > > Or move to ib_addr you see a problem with this. > > > > The nice thing about making it a stand-alone module is that its init > function gets called when loaded. If we add it to ib_core or ib_addr, > then we'll have to modify one of those init functions. > > I'm all for keeping this simple, so do you have a suggestion for how to > call the init function? One idea: This code can register as an ib_client. Then it will a callback when providers are registered. Upon the first provider registration, it can do its init functionality... So then the code could be bound into ib_core or ib_addr without modifying those sources. Steve. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RDMA CM multicast
Michael S. Tsirkin wrote: >> What would be needed is a way for the user to indicate that they need a >> unique >> address. An obvious way to accomplish this is for the user to specify an IP >> address of 0.0.0.0 when calling rdma_join_multicast(). The user would first >> need to bind to a specific device by calling rdma_bind_addr() with a local IP >> address. > > Is this how it works with sockets? I'm not aware of IP multicast having this functionality. This is a major problem with IP multicast, as some sort of address selection arbitration has to be done. From what I've seen, this ranges from IANA assigning multicast addresses for specific uses to best-effort protocols for selecting unused addresses from an available range. It's a fairly hard problem, and having OFED choose an unused address (my understanding is that the SM is capable of this) sidesteps the issue and makes life much better. Andrew ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] ofed_1_2 iw_cxgb3: allow doorbell mappings with VM_READ set.
iw_cxgb3: allow doorbell mappings with VM_READ set.
This is needed on RHEL4U4. The vma passed into the iw_cxgb3 mmap function
has VM_READ set even though the library only request write.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
.../2.6.9_U4/iwch_provider_to_2.6.9_U4.patch | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/kernel_patches/backport/2.6.9_U4/iwch_provider_to_2.6.9_U4.patch
b/kernel_patches/backport/2.6.9_U4/iwch_provider_to_2.6.9_U4.patch
new file mode 100644
index 000..1fbc717
--- /dev/null
+++ b/kernel_patches/backport/2.6.9_U4/iwch_provider_to_2.6.9_U4.patch
@@ -0,0 +1,16 @@
+--- a/drivers/infiniband/hw/cxgb3/iwch_provider.c 2007-01-17
09:22:39.0 -0600
b/drivers/infiniband/hw/cxgb3/iwch_provider.c 2007-01-22
17:46:16.0 -0600
+@@ -337,13 +337,6 @@ static int iwch_mmap(struct ib_ucontext
+ (pgaddr < (rdev_p->rnic_info.udbell_physbase +
+ rdev_p->rnic_info.udbell_len))) {
+
+- /*
+- * Map T3 DB register.
+- */
+- if (vma->vm_flags & VM_READ) {
+- return -EPERM;
+- }
+-
+ vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+ vma->vm_flags |= VM_DONTCOPY | VM_DONTEXPAND;
+ vma->vm_flags &= ~VM_MAYREAD;
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RDMA CM multicast
Sean Hefty wrote: > Posting to openib-general list... > >> RDMA CM has multicast of course, though it seems no means of preventing >> address collisions (to me, that means two separate MPI jobs using the >> same multicast address). I know that part of the new multicast support >> you had developed a few months ago was the ability to specify a '0' >> MGID/MLID to indicate that an unused multicast address should be used >> and returned. >> >> How hard would it be to add this functionality to RDMA CM? > > I looked into this, and it seems doable. I hacked the kernel rdma_cm to join > a > multicast group with an mgid of 0, and it seemed to work as far as I could > test > it without more extensive changes. (My test didn't actually transfer data, > but > the join succeeded, the MGID/MLID was exported to userspace, and different > applications joined different groups.) > > What would be needed is a way for the user to indicate that they need a unique > address. An obvious way to accomplish this is for the user to specify an IP > address of 0.0.0.0 when calling rdma_join_multicast(). The user would first > need to bind to a specific device by calling rdma_bind_addr() with a local IP > address. Fine with me -- I would be using rdma_bind_addr() all the time anyway. Though finding a way to remove this requirement might be useful to someone else.. > If more than one group is joined this way, then rdma_leave_multicast() would > need someway to distinguish between the different groups joined by a single > user. (rdma_leave_multicast takes the IP address of the group to leave.) > Providing a "port number" with the sockaddr would work. The port number would > need to match when joining/leaving, but is not part of the multicast address, > essentially making it a join index specified by the user. > > Your code would look something like this: > > rdma_bind_addr(local IP address) > rdma_join_multicast(0.0.0.0, port 0) <- exchange group info out of band > rdma_join_multicast(0.0.0.0, port 1) <- exchange group info out of band > send data to a lot of nodes at once > rdma_leave_multicast(0.0.0.0, port 0) > rdma_leave_multicast(0.0.0.0, port 1) Not sure I understand this -- RDMA CM will be exchanging whatever multicast address is selected as part of the rdma_join_multicast call? How exactly do you plan to do that? i.e. How do you know who to communicate that information to? Unless I'm missing something, it sounds like this approach just moves the address collision problem over to port numbers, which wouldn't really accomplish anything. What I would have expected is a means to get at the address that gets chosen instead of 0.0.0.0 -- either directly returned at rdma_join_multicast or successful join notification, or made available in a data structure somewhere. From there it's trivial (for me) to pass the address to the other peers I care about, and have them join by expicitly specifying the multicast address. Andrew > If this sounds like it would work for you, let me know, and I can create a > patch > to test this idea more. > > - Sean > > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RDMA CM multicast
On Tue, 2007-01-23 at 19:58, Sean Hefty wrote: > > rdma_join_multicast(0.0.0.0, port 0)<- exchange group info out of > > band > > Trying to work through this more, having the first node join seems trivial. > Getting additional nodes to join the same group through the rdma_cm is > proving > more difficult... The MGID of the group would need to be treated as an IPv6 > address, with a join done using that address directly, versus mapping an IPv6 > address to an MGID using the ipoib algorithm. Doesn't this carve a hole in the IPv6 (multicast) address space (group ID) ? If so, is that a hole we can carve out ? -- Hal > I still believe this is doable, it's just going to require more > thought/discussion to ensure that we get a clean implementation. > > - Sean > > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] OFED 1.2 bug reporting
Should I be using the open fabrics bugzilla to open bugs against OFED 1.2? If so, should a new 'version' be added for ofed-1.2? Right now the only version that makes sense is 'gen2', but that doesn't really cover bugs against backport code... Steve. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH RFC ] ofed_1_2 simulate neighbour update events by snooping ARP packets
On Wed, 2007-01-24 at 12:14 +0200, Michael S. Tsirkin wrote:
> > Quoting Steve Wise <[EMAIL PROTECTED]>:
> > Subject: [PATCH RFC ] ofed_1_2 simulate neighbour update events by snooping
> > ARP packets
> >
> > OFED/iWARP Developers,
> >
> > Here is a proposal for supporting the minimum required neighbour update
> > event notifications needed for iwarp devices on the older kernels
> > supported by ofed.
> >
> > This patch is a request for comments. Please review. If you think it
> > looks ok, then I'll provide patches to all the various backports.
> >
> > Steve
>
> I am generally very positive about this, let's try to do this for OFED 1.2.
> Some comments on code:
>
> > 2.6.17 backport: simulate neighbour update events by snooping ARP packets
> >
> > Needed to support iWARP devices on backported kernels. This also allows
> > using the current drivers/infiniband/core/addr.c which requires netevents
> > as well.
> >
> > This patch rearranges things a bit:
> >
> > - add the new file in the kernel_addons/backport dir for the ARP
> > snooping / netevent callout code. This file is called
> > rdma_netevents.c.
> >
> > - modify the kernel_patches/backports/2.6.17/linux_stuff* patch to
> > include rdma_netevents.c _and_ the netevent.c file into its own
> > module called rdma_ne
>
> Maybe roll these two into a common netevent.c? Is there a reason not to?
> Are there kernels where you will want one of these but not the other?
> And the name is a bit confusing - nothing here is actually related to rdma in
> any way ...
>
I kept them seperate because the netevent.c is pulled as-is from 2.6.20.
It does make sense to just add the stuff I put in rdma_netevent.c into
netevent.c and just have that one file.
> > - remove the backport patch to revert addr.c to snoop ARP packets.
> >
> > Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
> >
> > .../backport/2.6.17/include/src/rdma_netevents.c | 91
> > +++
> > .../2.6.17/addr_1_netevents_revert_to_2_6_17.patch | 76
> > ---
> > .../backport/2.6.17/linux_stuff_to_2_6_17.patch| 13 ++-
> > 3 files changed, 99 insertions(+), 81 deletions(-)
> >
> > diff --git a/kernel_addons/backport/2.6.17/include/src/rdma_netevents.c
> > b/kernel_addons/backport/2.6.17/include/src/rdma_netevents.c
> > new file mode 100644
> > index 000..1e9422f
> > --- /dev/null
> > +++ b/kernel_addons/backport/2.6.17/include/src/rdma_netevents.c
> > @@ -0,0 +1,91 @@
> > +/*
> > + * Copyright (c) 2007 Open Grid Computing, Inc. All rights reserved.
> > + * Copyright (c) 2007 Chelsio Communications, Inc. All rights reserved.
> > + *
> > + * This Software is licensed under one of the following licenses:
> > + *
> > + * 1) under the terms of the "Common Public License 1.0" a copy of which is
> > + *available from the Open Source Initiative, see
> > + *http://www.opensource.org/licenses/cpl.php.
> > + *
> > + * 2) under the terms of the "The BSD License" a copy of which is
> > + *available from the Open Source Initiative, see
> > + *http://www.opensource.org/licenses/bsd-license.php.
> > + *
> > + * 3) under the terms of the "GNU General Public License (GPL) Version 2" a
> > + *copy of which is available from the Open Source Initiative, see
> > + *http://www.opensource.org/licenses/gpl-license.php.
> > + *
> > + * Licensee has the right to choose one of the above licenses.
> > + *
> > + * Redistributions of source code must retain the above copyright
> > + * notice and one of the license notices.
> > + *
> > + * Redistributions in binary form must reproduce both the above copyright
> > + * notice, one of the license notices in the documentation
> > + * and/or other materials provided with the distribution.
> > + *
> > + */
> > +
> > +/*
> > + * Simulate neighbour update netevents by snooping ARP packets.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +MODULE_AUTHOR("Steve Wise");
> > +MODULE_DESCRIPTION("Netevent Notification Module");
> > +MODULE_LICENSE("Dual BSD/GPL");
> > +
> > +static int arp_recv(struct sk_buff *skb, struct net_device *dev,
> > +struct packet_type *pkt, struct net_device *dev2)
> > +{
> > + struct arphdr *arp_hdr;
> > + struct neighbour *n;
> > + u8 *arp_ptr;
> > + __be32 gw;
> > + u16 op;
> > +
> > + arp_hdr = (struct arphdr *) skb->nh.raw;
> > + op = ntohs(arp_hdr->ar_op);
> > +
> > + if (op == ARPOP_REQUEST || op == ARPOP_REPLY) {
> > + arp_ptr = (u8 *)(arp_hdr + 1); /* skip fixed-size arp header */
>
> I think this is correct, but this looks weird because arp_hdr + 1
> is a pointer to an *invalid* arp header.
This is common practice for bumping past a fixed size header.
>
> I know arp_hdr + 1 does math in units of sizeof *arp_hdr, but just
> arp_ptr = skb->nh.raw + sizeof (struct arphdr) would much clearer -
> leave the pointer math for w
Re: [openib-general] win related [was: Re: [PATCH 1/2] opensm: sigusr1: syslog() fixes]
Hi Yevgeny, On Wed, 2007-01-24 at 01:26, Yevgeny Kliteynik wrote: > Hi Hal, > > Hal Rosenstock wrote: > > Hi again Yevgeny, > > > > On Tue, 2007-01-23 at 11:20, Yevgeny Kliteynik wrote: > >> Hi Hal, > >> > >> Hal Rosenstock wrote: > >>> Hi Yevgeny, > >>> > >>> On Sun, 2007-01-21 at 04:17, Yevgeny Kliteynik wrote: > Sasha Khapyorsky wrote: > > On 18:24 Thu 11 Jan , Yevgeny Kliteynik wrote: > >> As for the mailing list it's [EMAIL PROTECTED] You can access > >> it here: http://openib.org/mailman/listinfo/openib-windows > > I found only references to svn://windows.openib.org, where > > 'svn log svn://windows.openib.org/gen1/trunk/ulp/opensm/user/opensm | > > head -n 40' shows: > > > > > > r474 | sleybo | 2006-08-31 11:57:19 +0300 (Thu, 31 Aug 2006) | 1 line > > > > Set property svn:keywords "id" on all repository > > > > r472 | sleybo | 2006-08-31 11:08:18 +0300 (Thu, 31 Aug 2006) | 1 line > > > > [OPENSM] When running as a service, if all ports are down, use the > > first port. > > > > r460 | sleybo | 2006-08-20 16:55:49 +0300 (Sun, 20 Aug 2006) | 3 lines > > > > [OPENSM] When trying to set to INIT the remote port of the given > > physical port > > in function __osm_lid_mgr_set_remote_pi_state_to_init, there was no > > check whether the physical port in null (e.g., if it's disconnected). > > > > r458 | tzachid | 2006-08-17 11:12:37 +0300 (Thu, 17 Aug 2006) | 1 line > > > > [opensm] Base service status on results that were received from opensm > > log messages. > > > > r410 | leonidk | 2006-07-09 20:56:01 +0300 (Sun, 09 Jul 2006) | 1 line > > > > [OPENSM] missed fix for OPENSM logging to System Event Log > > > > r402 | leonidk | 2006-07-05 16:19:23 +0300 (Wed, 05 Jul 2006) | 5 lines > > > > [OPENSM] 1. feature: added SHUT_DOWN support. Without that one can't > > perform reboot with opensm running as service ! > > 2. bugfix: added message file for correct logging to System Event Log. > > 3. bugfix: wrong passing parameters in server mode; > > 4. bugfix: error in table of parameters > > > > > > r366 | tzachid | 2006-05-28 14:49:08 +0300 (Sun, 28 May 2006) | 1 line > > > > [opensm] Fix a trivial build break > > > > r361 | eitan | 2006-05-23 13:07:09 +0300 (Tue, 23 May 2006) | 3 lines > > > > if the guid2lid is corrupted, don't exit when running with -y option > > (don't exit on fatal) - just ignore the file > > > > > > > > Seems that development there was stopped in Aug 2006, and it doesn't > > have recent Win port patches. Am I looking in the wrong place? > You were looking in the right place. It appears that I didn't describe > the development process correctly. I think this repository is updated > with stable OSM versions, after the code is tested. > >>> Any idea on when the next version is expected ? > >> The SVN will be updated in a couple of days. > > > > Glad to hear it. To what OpenSM version will it correspond ? Will it be > > based on OFED 1.1 or beyond ? What OpenIB svn or git commit does it > > correspond to ? Thanks. > > The local SVN repository is syncronized with OpenSM GIT repository > (head of master), and the changes from git are merged into the svn daily. > This local SVN will be uploaded to the SVN repository on the web. How frequently ? Is there only the released OpenSM version on the web ? Why not a work in progress one as well ? Wouldn't that help get more early testing in the Windows environment ? -- Hal > > -- Yevgeny > > > -- Hal > > > >> -- Yevgeny > >> > >>> -- Hal > >>> > If you need more details, I think it's better for you to ask windows > folks > directly, since as we see, my knowledge in this area is very limited. > > -- Yevgeny > > > Sasha > > > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general > > > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, pl
Re: [openib-general] [PATCH] ib_addr: Handle Ethernet neighbour updates during route resolution.
On Wed, 2007-01-24 at 10:15 +0200, Michael S. Tsirkin wrote: > > Quoting Steve Wise <[EMAIL PROTECTED]>: > > Subject: [PATCH] ib_addr: Handle Ethernet neighbour updates during route > > resolution. > > > > > > Handle Ethernet neighbour updates during route resolution. > > > > The IWCM uses the ib_addr services to do route resolution (neighbour > > discovery in the IP world). The ib_addr netevent callback routine, > > however, currently only acts on Inifininband neighbour updates. It needs > > to act on ethernet neighbour updates as well. > > > > This patch just removes filtering on device type altogether and > > will trigger on any neighour updates where the nud_type is valid. > > This simplifies the code some. > > > > Signed-off-by: Steve Wise <[EMAIL PROTECTED]> > > BTW, Steve, if this is a patch you want in OFED, pls specify this. > Right...sorry: I believe it should go in OFED 1.2 and queued for 2.6.21. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] osm: QoS: added qos class and service id to the path record
On Tue, 2007-01-23 at 02:07, Yevgeny Kliteynik wrote: [snip...] > Hal, should I resubmit the patch? Yes, please do. -- Hal > Thanks. > > -- Yevgeny ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 0/6] osm: QoS policy parser
Hi Hal, Hal Rosenstock wrote: > Hi Yevgeny, > > On Sun, 2007-01-21 at 03:46, Yevgeny Kliteynik wrote: >> Hi Sasha. >> >> Sasha Khapyorsky wrote: >>> Hi Yevgeny, >>> >>> On 17:01 Wed 17 Jan , Yevgeny Kliteynik wrote: Hi Hal The following series of six patches implements QoS policy file parser: 1. QoS parser Lex file 2. QoS parser Lex-generated c file 3. QoS parser grammar (Yacc) file 4. QoS parser Yacc-generated grammar c and h file 5. QoS parser header file that defines parse tree data structures 6. Changes in makefiles and configure.in file for compiling QoS parser files >>> Is there any description of proposed format and functionality? >> The parser is based on QoS RFC sent by Eitan in May 2006, with a few >> minor modifications. You can find the RFC here: >> http://openib.org/pipermail/openib-general/2006-May/022336.html >> >>> Also what about using human readable formats? >> To me the xml-like format in the RFC looks pretty readable. >> It has very limited number of keywords (tags), so it's easy >> to follow and/or to modify. > > Putting aside the issue of plain text versus XML file formats for a > moment, can an example of the XML format be supplied ? What are the tags > used and their relationships ? I don't think there's been a discussion > on this yet. I've just sent a QoS policy file example with some explanations. You might get this mail more than once - I think I messed up with the mail address... > Also, why were lex and yacc chosen to be used rather than some open > source XML parser (already written in C) ? Yacc and Lex produce simple stand alone code which is not dependant on any other package. On top of it they are the most accurate syntax parsers and easy to handle. Also an XML parser would have provided only TAG parsing without any type checking. > I also have some questions about the patches Shoot > but I'll wait to see more of the bigger picture here. Hope the mail with the file example sheds some light. -- Yevgeny > -- Hal > >> -- Yevgeny >> >>> Sasha >>> > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] ofa_1_2_kernel 20070124-0553 daily build status
This email was generated automatically, please do not reply Common build parameters: --with-ipoib-mod --with-sdp-mod --with-srp-mod --with-user_mad-mod --with-user_access-mod --with-mthca-mod --with-core-mod --with-addr_trans-mod --with-cxgb3-mod Passed: Passed on i686 with 2.6.15-23-server Passed on i686 with linux-2.6.19 Passed on i686 with linux-2.6.16 Passed on i686 with linux-2.6.17 Passed on i686 with linux-2.6.12 Passed on i686 with linux-2.6.13 Passed on i686 with linux-2.6.14 Passed on i686 with linux-2.6.15 Passed on i686 with linux-2.6.18 Passed on x86_64 with linux-2.6.19 Passed on powerpc with linux-2.6.19 Passed on powerpc with linux-2.6.18 Passed on x86_64 with linux-2.6.12 Passed on x86_64 with linux-2.6.13 Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.16 Passed on powerpc with linux-2.6.17 Passed on x86_64 with linux-2.6.14 Passed on x86_64 with linux-2.6.15 Passed on x86_64 with linux-2.6.17 Passed on ppc64 with linux-2.6.12 Passed on powerpc with linux-2.6.12 Passed on ppc64 with linux-2.6.19 Passed on powerpc with linux-2.6.13 Passed on ia64 with linux-2.6.19 Passed on powerpc with linux-2.6.14 Passed on ppc64 with linux-2.6.17 Passed on powerpc with linux-2.6.15 Passed on ppc64 with linux-2.6.16 Passed on powerpc with linux-2.6.16 Passed on ppc64 with linux-2.6.15 Passed on ppc64 with linux-2.6.13 Passed on ppc64 with linux-2.6.14 Passed on ia64 with linux-2.6.12 Passed on ppc64 with linux-2.6.18 Passed on ia64 with linux-2.6.18 Passed on ia64 with linux-2.6.17 Passed on ia64 with linux-2.6.16 Passed on ia64 with linux-2.6.15 Passed on ia64 with linux-2.6.14 Passed on ia64 with linux-2.6.13 Failed: ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 0/6] osm: QoS policy parser
Hi Hal, Sasha. Here's a description of the QoS policy file, and an example of such file (with more comments inside). QoS Policy file --- The QoS policy file is divided into 4 sub sections: * Node Group: a set of HCAs, Routers or Switches that share the same settings. A node groups might be a partition defined by the partition manager policy in terms of GUIDs. Future implementations might provide support for NodeDescription based definition of node groups. * Fabric Setup: Defines how the SL2VL and VLArb tables should be setup. This policy definition assumes the computation of target behavior should be performed outside of OpenSM. * QoS-Levels Definition: This section defines the possible sets of parameters for QoS that a client might be mapped to. Each set holds: SL and optionally: Max MTU, Max Rate, Path Bits (in case LMC > 0 is used for QoS) and TClass. * Matching Rules: A list of rules that match an incoming PathRecord request to a QoS-Level. The rules are processed in order such as the first match is applied. Each rule is built out of set of match expressions which should all match for the rule to apply. The matching expressions are defined for the following fields - SRC and DST to lists of node groups - Service-ID to a list of Service-ID or Service-ID ranges - TClass to a list of TClass values or ranges QoS policy file example --- Storage our SRP storage targets 0x1001 0x1002 Virtual Servers node desc and IB port # vs1/HCA-1/P1 vs3/HCA-1/P1 vs3/HCA-2/P1 Partition 1 default settings Part1 Routers all routers ROUTER Part1 * * 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,7 Storage Storage2 Storage3 * 1 0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0 Storage 0:255,1:127,2:63,3:31,4:15,5:7,6:3,7:1 8:255,9:127,10:63,11:31,12:15,13:7,14:3 10 1 for the lowest priority comm 16 2 low latency best bandwidth 0 7 3 just an example 0 32 1 1 1 low latency by class 7-9 or 11 7-9,11 1 2 Storage targets connection> Storage 22,4719 3 -- Yevgeny Yevgeny Kliteynik wrote: > Hi Sasha, > > Sasha Khapyorsky wrote: >> On 10:46 Sun 21 Jan , Yevgeny Kliteynik wrote: >>> Hi Sasha. >>> >>> Sasha Khapyorsky wrote: Hi Yevgeny, On 17:01 Wed 17 Jan , Yevgeny Kliteynik wrote: > Hi Hal > > The following series of six patches implements QoS policy file parser: > > 1. QoS parser Lex file > 2. QoS parser Lex-generated c file > 3. QoS parser grammar (Yacc) file > 4. QoS parser Yacc-generated grammar c and h file > 5. QoS parser header file that defines parse tree data structures > 6. Changes in makefiles and configure.in file for compiling QoS parser > files Is there any description of proposed format and functionality? >>> The parser is based on QoS RFC sent by Eitan in May 2006, with a few >>> minor modifications. You can find the RFC here: >>> http://openib.org/pipermail/openib-general/2006-May/022336.html >> This was RFC and couple of issues were discussed then. Now you are about >> implementation phase and exact format description would be desired. For >> example what "few minor modifications" are? > > I'll prepare an example file with explanations. > > -- Yevgeny > Also what about using human readable formats? >>> To me the xml-like format in the RFC looks pretty readable. >>> It has very limited number of keywords (tags), so it's easy >>> to follow and/or to modify. >> It is your opinion, not everybody will agree with it (AFAIR this was >> discussed too during RFC). >> >> I would not be care, but I don't know any example of really successful >> XML using for configuration purposes (especially where advanced graphical >> config editors/viewers were not used).
Re: [openib-general] [PATCH 0/6] osm: QoS policy parser
Hi Hal, Sasha. Here's a description of the QoS policy file, and an example of such file (with more comments inside). QoS Policy file --- The QoS policy file is divided into 4 sub sections: * Node Group: a set of HCAs, Routers or Switches that share the same settings. A node groups might be a partition defined by the partition manager policy in terms of GUIDs. Future implementations might provide support for NodeDescription based definition of node groups. * Fabric Setup: Defines how the SL2VL and VLArb tables should be setup. This policy definition assumes the computation of target behavior should be performed outside of OpenSM. * QoS-Levels Definition: This section defines the possible sets of parameters for QoS that a client might be mapped to. Each set holds: SL and optionally: Max MTU, Max Rate, Path Bits (in case LMC > 0 is used for QoS) and TClass. * Matching Rules: A list of rules that match an incoming PathRecord request to a QoS-Level. The rules are processed in order such as the first match is applied. Each rule is built out of set of match expressions which should all match for the rule to apply. The matching expressions are defined for the following fields - SRC and DST to lists of node groups - Service-ID to a list of Service-ID or Service-ID ranges - TClass to a list of TClass values or ranges QoS policy file example --- Storage our SRP storage targets 0x1001 0x1002 Virtual Servers node desc and IB port # vs1/HCA-1/P1 vs3/HCA-1/P1 vs3/HCA-2/P1 Partition 1 default settings Part1 Routers all routers ROUTER Part1 * * 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,7 Storage Storage2 Storage3 * 1 0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0 Storage 0:255,1:127,2:63,3:31,4:15,5:7,6:3,7:1 8:255,9:127,10:63,11:31,12:15,13:7,14:3 10 1 for the lowest priority comm 16 2 low latency best bandwidth 0 7 3 just an example 0 32 1 1 1 low latency by class 7-9 or 11 7-9,11 1 2 Storage targets connection> Storage 22,4719 3 -- Yevgeny Yevgeny Kliteynik wrote: > Hi Sasha, > > Sasha Khapyorsky wrote: >> On 10:46 Sun 21 Jan , Yevgeny Kliteynik wrote: >>> Hi Sasha. >>> >>> Sasha Khapyorsky wrote: Hi Yevgeny, On 17:01 Wed 17 Jan , Yevgeny Kliteynik wrote: > Hi Hal > > The following series of six patches implements QoS policy file parser: > > 1. QoS parser Lex file > 2. QoS parser Lex-generated c file > 3. QoS parser grammar (Yacc) file > 4. QoS parser Yacc-generated grammar c and h file > 5. QoS parser header file that defines parse tree data structures > 6. Changes in makefiles and configure.in file for compiling QoS parser > files Is there any description of proposed format and functionality? >>> The parser is based on QoS RFC sent by Eitan in May 2006, with a few >>> minor modifications. You can find the RFC here: >>> http://openib.org/pipermail/openib-general/2006-May/022336.html >> This was RFC and couple of issues were discussed then. Now you are about >> implementation phase and exact format description would be desired. For >> example what "few minor modifications" are? > > I'll prepare an example file with explanations. > > -- Yevgeny > Also what about using human readable formats? >>> To me the xml-like format in the RFC looks pretty readable. >>> It has very limited number of keywords (tags), so it's easy >>> to follow and/or to modify. >> It is your opinion, not everybody will agree with it (AFAIR this was >> discussed too during RFC). >> >> I would not be care, but I don't know any example of really successful >> XML using for configuration purposes (especially where advanced graphical >> config editors/viewers were not used).
Re: [openib-general] [PATCH] IB/ipoib: Add field dev to struct ipoib_neigh
> > > > > > Just to clarify - you previously mentionned you saw problems with 2.6.16 > > backport. Is this an issue you see with 2.6.20 as well? > Yes, the same thing happens with kernel 2.6.20. However, the patch for 2.6.20 > looks a little bit different. I will post it today or tommorow. Let's see that first. I prefer to first look at upstream code, then think about backporting. > > > > Also - in your approach, what prevents the device from going away while > > there > > are still ipoib_neigh objects around? > Nothing prevents it. You can modprobe -r bonding whenever you want (even when > IPoIB is up) > and still be safe from leaks. I think my answer for that is below. > > > Also - if neigh does not point to ipoib device, our neigh destructor won't > > be called > > for it, will it? What will clean the ipoib neigh then? > > > With kernels up to 2.6.16, patch ipoib_8111_to_2_6_16 adds this to > ipoib_neigh_alloc > ==> neigh->neighbour->ops->destructor = ipoib_neigh_destructor; > So I guess there is no such problem here. But this would hardly help if ipoib module is unloaded while neighbour for bonding device is still around and has a pointer to ipoib_neigh_destructor. > For later kernels, bond device "borrows" the slave's neigh_setup > function in the bond's setup function. > > ==> bond_dev->neigh_setup = slave_dev->neigh_setup; > > So even if the beighbour points to bond device the > ipoib_neigh_destructor will be called. Same applies here. Further, in both cases, it seems that accessing data at to_ipoib_neigh on a neighbour for non-ipoib device can cause a crash if hardware address is !=0 at offset 20. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] IB/ipoib: Add field dev to struct ipoib_neigh
> > > Just to clarify - you previously mentionned you saw problems with 2.6.16 > backport. Is this an issue you see with 2.6.20 as well? Yes, the same thing happens with kernel 2.6.20. However, the patch for 2.6.20 looks a little bit different. I will post it today or tommorow. > > Also - in your approach, what prevents the device from going away while there > are still ipoib_neigh objects around? Nothing prevents it. You can modprobe -r bonding whenever you want (even when IPoIB is up) and still be safe from leaks. I think my answer for that is below. > Also - if neigh does not point to ipoib device, our neigh destructor won't be > called > for it, will it? What will clean the ipoib neigh then? > With kernels up to 2.6.16, patch ipoib_8111_to_2_6_16 adds this to ipoib_neigh_alloc ==> neigh->neighbour->ops->destructor = ipoib_neigh_destructor; So I guess there is no such problem here. For later kernels, bond device "borrows" the slave's neigh_setup function in the bond's setup function. ==> bond_dev->neigh_setup = slave_dev->neigh_setup; So even if the beighbour points to bond device the ipoib_neigh_destructor will be called. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH RFC ] ofed_1_2 simulate neighbour update events by snooping ARP packets
> Quoting Steve Wise <[EMAIL PROTECTED]>:
> Subject: [PATCH RFC ] ofed_1_2 simulate neighbour update events by snooping
> ARP packets
>
> OFED/iWARP Developers,
>
> Here is a proposal for supporting the minimum required neighbour update
> event notifications needed for iwarp devices on the older kernels
> supported by ofed.
>
> This patch is a request for comments. Please review. If you think it
> looks ok, then I'll provide patches to all the various backports.
>
> Steve
I am generally very positive about this, let's try to do this for OFED 1.2.
Some comments on code:
> 2.6.17 backport: simulate neighbour update events by snooping ARP packets
>
> Needed to support iWARP devices on backported kernels. This also allows
> using the current drivers/infiniband/core/addr.c which requires netevents
> as well.
>
> This patch rearranges things a bit:
>
> - add the new file in the kernel_addons/backport dir for the ARP
> snooping / netevent callout code. This file is called
> rdma_netevents.c.
>
> - modify the kernel_patches/backports/2.6.17/linux_stuff* patch to
> include rdma_netevents.c _and_ the netevent.c file into its own
> module called rdma_ne
Maybe roll these two into a common netevent.c? Is there a reason not to?
Are there kernels where you will want one of these but not the other?
And the name is a bit confusing - nothing here is actually related to rdma in
any way ...
> - remove the backport patch to revert addr.c to snoop ARP packets.
>
> Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
>
> .../backport/2.6.17/include/src/rdma_netevents.c | 91
> +++
> .../2.6.17/addr_1_netevents_revert_to_2_6_17.patch | 76 ---
> .../backport/2.6.17/linux_stuff_to_2_6_17.patch| 13 ++-
> 3 files changed, 99 insertions(+), 81 deletions(-)
>
> diff --git a/kernel_addons/backport/2.6.17/include/src/rdma_netevents.c
> b/kernel_addons/backport/2.6.17/include/src/rdma_netevents.c
> new file mode 100644
> index 000..1e9422f
> --- /dev/null
> +++ b/kernel_addons/backport/2.6.17/include/src/rdma_netevents.c
> @@ -0,0 +1,91 @@
> +/*
> + * Copyright (c) 2007 Open Grid Computing, Inc. All rights reserved.
> + * Copyright (c) 2007 Chelsio Communications, Inc. All rights reserved.
> + *
> + * This Software is licensed under one of the following licenses:
> + *
> + * 1) under the terms of the "Common Public License 1.0" a copy of which is
> + *available from the Open Source Initiative, see
> + *http://www.opensource.org/licenses/cpl.php.
> + *
> + * 2) under the terms of the "The BSD License" a copy of which is
> + *available from the Open Source Initiative, see
> + *http://www.opensource.org/licenses/bsd-license.php.
> + *
> + * 3) under the terms of the "GNU General Public License (GPL) Version 2" a
> + *copy of which is available from the Open Source Initiative, see
> + *http://www.opensource.org/licenses/gpl-license.php.
> + *
> + * Licensee has the right to choose one of the above licenses.
> + *
> + * Redistributions of source code must retain the above copyright
> + * notice and one of the license notices.
> + *
> + * Redistributions in binary form must reproduce both the above copyright
> + * notice, one of the license notices in the documentation
> + * and/or other materials provided with the distribution.
> + *
> + */
> +
> +/*
> + * Simulate neighbour update netevents by snooping ARP packets.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +MODULE_AUTHOR("Steve Wise");
> +MODULE_DESCRIPTION("Netevent Notification Module");
> +MODULE_LICENSE("Dual BSD/GPL");
> +
> +static int arp_recv(struct sk_buff *skb, struct net_device *dev,
> + struct packet_type *pkt, struct net_device *dev2)
> +{
> + struct arphdr *arp_hdr;
> + struct neighbour *n;
> + u8 *arp_ptr;
> + __be32 gw;
> + u16 op;
> +
> + arp_hdr = (struct arphdr *) skb->nh.raw;
> + op = ntohs(arp_hdr->ar_op);
> +
> + if (op == ARPOP_REQUEST || op == ARPOP_REPLY) {
> + arp_ptr = (u8 *)(arp_hdr + 1); /* skip fixed-size arp header */
I think this is correct, but this looks weird because arp_hdr + 1
is a pointer to an *invalid* arp header.
I know arp_hdr + 1 does math in units of sizeof *arp_hdr, but just
arp_ptr = skb->nh.raw + sizeof (struct arphdr) would much clearer -
leave the pointer math for when there is an array.
And then you will not need a cast.
> + arp_ptr += skb->dev->addr_len; /* skip src ha */
> + memcpy(&gw, arp_ptr, 4);/* pull the SPA */
> + n = neigh_lookup(&arp_tbl, &gw, skb->dev);
> + if (n) {
> + call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, n);
> + }
> + }
> +
> + kfree_skb(skb);
> + return 0;
> +}
> +
> +static struct packet_type arp = {
> + .type = __constant_htons(ETH_P_ARP),
> + .func = arp_recv,
>
Re: [openib-general] [PATCH] ib_addr: Handle Ethernet neighbour updates during route resolution.
> Quoting Steve Wise <[EMAIL PROTECTED]>: > Subject: [PATCH] ib_addr: Handle Ethernet neighbour updates during route > resolution. > > > Handle Ethernet neighbour updates during route resolution. > > The IWCM uses the ib_addr services to do route resolution (neighbour > discovery in the IP world). The ib_addr netevent callback routine, > however, currently only acts on Inifininband neighbour updates. It needs > to act on ethernet neighbour updates as well. > > This patch just removes filtering on device type altogether and > will trigger on any neighour updates where the nud_type is valid. > This simplifies the code some. > > Signed-off-by: Steve Wise <[EMAIL PROTECTED]> BTW, Steve, if this is a patch you want in OFED, pls specify this. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RDMA CM multicast
> What would be needed is a way for the user to indicate that they need a unique > address. An obvious way to accomplish this is for the user to specify an IP > address of 0.0.0.0 when calling rdma_join_multicast(). The user would first > need to bind to a specific device by calling rdma_bind_addr() with a local IP > address. Is this how it works with sockets? -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] librdmacm and udapl: Which git branch to use in ofed_1_2 build
> Quoting Sean Hefty <[EMAIL PROTECTED]>: > Subject: Re: librdmacm and udapl: Which git branch to use in ofed_1_2 build > > > Could you please rebase that to 2.6.20-rc5? > > Yes - but I probably won't get to this until tomorrow. Not a problem - I generated patches and put them in OFED already. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
