Re: [PATCH 3/3] ibacm: check for special handling of loopback requests
Ralph Campbell wrote: I guess what I'm objecting to is hard coding mlx4. I was trying to think of a way that would allow other HCAs to support the block loopback option in the future. It looks like ipoib sets IB_QP_CREATE_BLOCK_MULTICAST_LOOPBACK for kernel QPs but this isn't defined in libibverbs yet. It seems reasonable to add that feature some time in the future and change ibacm to use it. In the mean time, I guess I don't see an alternative to your patch. Ralph, Sean Its been couple of years since some folks from Voltaire tried to push this flag and the grounds for adding similar flags for QP creation, on the bright side, its there for kernel consumers where existing flags are LSO, block-multicast-loopback. On the somehow disappointing side, we didn't get that merged for user space. Basically, there was a claim on dependency with XRC patch set which also added flags for QPs, at some point, Ron Livne managed to introduce patch set which is independent of the XCR, see (*) below, but it didn't get in. As such one of our application teams pushed to ofed that mlx4 patch which sets this bit by default and the acm code is trying to identify and act upon its existence (**) Or. (*) latest post of the patch set 0/4: https://kerneltrap.org/mailarchive/openfabrics-general/2008/12/11/4392994 1/4: https://kerneltrap.org/mailarchive/openfabrics-general/2008/12/11/4393054 2/4: https://kerneltrap.org/mailarchive/openfabrics-general/2008/12/11/4393004 3/4: https://kerneltrap.org/mailarchive/openfabrics-general/2008/12/11/4393014 4/4: https://kerneltrap.org/mailarchive/openfabrics-general/2008/12/11/4393024 (**) ofed patch http://git.openfabrics.org/git?p=ofed_1_5/linux-2.6.git;a=blob;f=kernel_patches/fixes/mlx4_0290_mcast_loopback.patch;h=786a3926529befac2c2d1fa6d8c36bada79d61a7;hb=HEAD http://git.openfabrics.org/git?p=ofed_1_5/linux-2.6.git;a=blob;f=kernel_patches/fixes/mlx4_0290_mcast_loopback.patch;h=786a3926529befac2c2d1fa6d8c36bada79d61a7;hb=HEAD -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ibacm: check for special handling of loopback requests
Hefty, Sean wrote: One could argue that this change is reasonable regardless of the OFED kernel patch. It avoids sending multicast traffic when the destination is local. The main drawback beyond the extra code is that a node can't send a multicast message to itself, with the intent that remote listeners will be able to cache the address data. Sean, To be precise, the bit avoids recieving multicast packets by the QP that --sent-- it, not by other QPs subscribed to that group on the same node/hca, the patch change-log even states that Inter QP multicast packets on the relevant HCA will still be delivered. You can test that with two mckey processes running on a node which has the patch active. So with acm the functionality you need is for the same QP to receive the packets it sent? Or. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mlx4: properly mask MGM entry members count
On Tue, Nov 16, 2010 at 02:43:46PM -0800, Roland Dreier wrote: Where is the change in handling in the members_count field? In the firmware? The firmware now distinguishes between differnet multicast addresses according to a protocol field located in the high MS byte which previously was reserved. The patches that Alekseys will will probably send later make use of this. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
rdma_lat whos
Hi Ido,
We came into a situation where running rdma_lat with vs with out the -c flag,
which means w. or w.o using the rdma-cm introduces a notable ~1us difference in
latency for 1k messages, that is ~3us w.o using rdma-cm and 3.9us when using
the rdma-cm.
I have reproduced that now with the latest code from your git tree and also
with the RHEL provided package of perftest-1.2.3-1.el5, see the results below.
Also, your tree is not available through the ofa git web service, Vlad, can you
help set this out.
Now, Jack, using this patch,
Index: perftest/rdma_lat.c
===
--- perftest.orig/rdma_lat.c
+++ perftest/rdma_lat.c
@@ -666,7 +666,7 @@ static int pp_connect_ctx(struct pingpon
{
struct ibv_qp_attr attr = {
.qp_state = IBV_QPS_RTR,
- .path_mtu = IBV_MTU_256,
+ .path_mtu = IBV_MTU_2048,
.dest_qp_num= data-rem_dest-qpn,
.rq_psn = data-rem_dest-psn,
.max_dest_rd_atomic = 1,
I could get rdma_lat which doesn't use the rdma-cm, which means setting all the
low-level QP params
by the hand to produce the SAME result of 3.9us as with the rdma-cm, as you
can see its one liner
patch which uses higher MTU of 2048 vs the hard coded MTU of 256 used in the
code. This is quite counter
intuitive, for packets whose size is 256, correct? is there any known issue
that can
explain that?! The SA is convinced that 2048 (0x84) is the best MTU for that
path, both nodes
have ConnectX DDR with firmware 2.7.0
Or.
# saquery -p --src-to-dst 1:14
Path record for 1 - 14
PathRecord dump:
service_id..0x
dgidfe80::8:f104:399:3c91
sgidfe80::2:c903:2:6be3
dlid0xE
slid0x1
hop_flow_raw0x0
tclass..0x0
num_path_revers.0x80
pkey0x
qos_class...0x0
sl..0x0
mtu.0x84
rate0x86
pkt_life0x92
preference..0x0
resv2...0x0
resv3...0x0
before the patch
active side, w.o rdma-cm
# rdma_lat 192.168.20.15 -s 1024 -n 1
26113:pp_client_connect: Couldn't connect to 192.168.20.15:18515
[r...@nsg1 ~]# rdma_lat 192.168.20.15 -s 1024 -n 1
local address: LID 0x0e QPN 0x1c004d PSN 0x3a3dca RKey 0x48002600 VAddr
0x0008a71400
remote address: LID 0x04 QPN 0x20004c PSN 0x27973 RKey 0x50042700 VAddr
0x001b724400
Latency typical: 3.01932 usec
Latency best : 2.97582 usec
Latency worst : 11.3183 usec
passive side w.o rdma-cm
# rdma_lat -s 1024 -n 1
local address: LID 0x04 QPN 0x20004c PSN 0x27973 RKey 0x50042700 VAddr
0x001b724400
remote address: LID 0x0e QPN 0x1c004d PSN 0x3a3dca RKey 0x48002600 VAddr
0x0008a71400
Latency typical: 3.02386 usec
Latency best : 2.97436 usec
Latency worst : 6.63569 usec
active side, w.o rdma-cm
# rdma_lat 192.168.20.15 -s 1024 -n 1 -c
26133: Local address: LID , QPN 00, PSN 0xa12538 RKey 0x50002600
VAddr 0x0013d27400
26133: Remote address: LID , QPN 00, PSN 0x5c01e8, RKey 0x58042700
VAddr 0x0006dbb400
Latency typical: 3.89977 usec
Latency best : 3.83227 usec
Latency worst : 13.6462 usec
passive side, w.o rdma-cm
# rdma_lat -s 1024 -n 1 -c
21826: Local address: LID , QPN 00, PSN 0x5c01e8 RKey 0x58042700
VAddr 0x0006dbb400
21826: Remote address: LID , QPN 00, PSN 0xa12538, RKey 0x50002600
VAddr 0x0013d27400
Latency typical: 3.89982 usec
Latency best : 3.83082 usec
Latency worst : 13.6974 usec
after the patch, the result w.o -c and with MTU=2048 becomes 3.9us as well,
/home/ogerlitz/linux/tools/perftest/rdma_lat 192.168.20.15 -s 1024 -n 1
local address: LID 0x0e QPN 0x3c004d PSN 0x14ff1e RKey 0x68002600 VAddr
0x0016c5d400
remote address: LID 0x04 QPN 0x40004c PSN 0xba137e RKey 0x70042700 VAddr
0x001f259400
Latency typical: 3.88327 usec
Latency best : 3.80378 usec
Latency worst : 8.27951 usec
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rdma_lat whos
Or Gerlitz wrote: Now, Jack, using this patch, I could get rdma_lat which doesn't use the rdma-cm, which means setting all the low-level QP params by the hand to produce the SAME result of 3.9us as with the rdma-cm, as you can see its one liner patch which uses higher MTU of 2048 vs the hard coded MTU of 256 used in the code. This is quite counter intuitive, for packets whose size is 256, correct? is there any known issue that can explain that?! The SA is convinced that 2048 (0x84) is the best MTU for that path, both nodes have ConnectX DDR with firmware 2.7.0 running with mtu=256 vs mtu=2048 on various msg size, you can see this phenomena in action 2.70us for 1k msg with LOWER mtu vs 3.54us with mtu=2048 # ib_send_lat -a -m 256 celery -- Send Latency Test Inline data is used up to 400 bytes message Connection type : RC local address: LID 0x04 QPN 0x4c004b PSN 0xf91b6e remote address: LID 0x04 QPN 0x4c004a PSN 0xb9e19a Mtu : 256 -- #bytes #iterationst_min[usec]t_max[usec] t_typical[usec] 21000 1.04 10.33 1.06 41000 1.03 9.80 1.07 81000 1.03 7.89 1.07 161000 1.05 7.81 1.09 321000 1.09 7.77 1.11 641000 1.18 7.99 1.21 1281000 1.48 8.05 1.51 2561000 2.06 8.67 2.19 5121000 2.31 14.38 2.38 10241000 2.62 14.54 2.70 20481000 3.26 14.90 3.36 40961000 4.54 28.84 4.64 81921000 7.19 18.48 7.30 163841000 12.61 24.1512.75 327681000 23.46 34.7724.30 655361000 45.19 56.4845.75 1310721000 88.64 102.9989.22 2621441000 175.78 186.59 175.97 5242881000 349.16 359.92 349.35 10485761000 695.80 706.90 696.22 209715210001389.411400.87 1389.95 419430410002777.212799.41 2778.08 838860810005691.775752.48 5737.45 -- All resources were Released successfully # ib_send_lat -a -m 2048 celery -- Send Latency Test Inline data is used up to 400 bytes message Connection type : RC local address: LID 0x04 QPN 0x54004b PSN 0x59384f remote address: LID 0x04 QPN 0x54004a PSN 0xcac60e Mtu : 2048 -- #bytes #iterationst_min[usec]t_max[usec] t_typical[usec] 21000 1.02 10.66 1.06 41000 1.03 54.53 1.06 81000 1.04 36.84 1.06 161000 1.05 34.58 1.08 321000 1.08 40.70 1.11 641000 1.18 66.86 1.21 1281000 1.48 38.76 1.51 2561000 2.07 39.15 2.18 5121000 2.58 45.90 2.67 10241000 3.46 38.07 3.54 20481000 5.22 40.55 5.31 40961000 6.53 39.17 6.61 81921000 9.16 38.85 9.29 163841000 14.52 50.1414.99 327681000 25.54 51.2025.64 655361000 47.18 59.7647.30 1310721000 90.87 96.9290.99 2621441000 178.22 183.27 178.37 5242881000 352.93 358.01 353.13 10485761000 702.37 707.69 702.66 209715210001401.301411.63 1401.66 419430410002799.162845.59 2801.92 838860810005833.305911.70 5886.55 -- -- To unsubscribe from
[PATCH] mlx4: Fix vlan insertion order
We must update the control segment before marking it as valid.
Signed-off-by: Eli Cohen e...@mellanox.co.il
---
drivers/infiniband/hw/mlx4/qp.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/qp.c b/drivers/infiniband/hw/mlx4/qp.c
index ec2c9bb..3d0c6d7 100644
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -1953,14 +1953,14 @@ int mlx4_ib_post_send(struct ib_qp *ibqp, struct
ib_send_wr *wr,
goto out;
}
- ctrl-owner_opcode = mlx4_ib_opcode[wr-opcode] |
- (ind qp-sq.wqe_cnt ? cpu_to_be32(1 31) : 0) | blh;
-
if (be16_to_cpu(vlan) 0x1000) {
ctrl-ins_vlan = 1 6;
ctrl-vlan_tag = vlan;
}
+ ctrl-owner_opcode = mlx4_ib_opcode[wr-opcode] |
+ (ind qp-sq.wqe_cnt ? cpu_to_be32(1 31) : 0) | blh;
+
stamp = ind + qp-sq_spare_wqes;
ind += DIV_ROUND_UP(size * 16, 1U qp-sq.wqe_shift);
--
1.7.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] ibacm: check for special handling of loopback requests
To be precise, the bit avoids recieving multicast packets by the QP that --sent-- it, not by other QPs subscribed to that group on the same node/hca, the patch change-log even states that Inter QP multicast packets on the relevant HCA will still be delivered. You can test that with two mckey processes running on a node which has the patch active. yes - I confirmed that using mckey. So with acm the functionality you need is for the same QP to receive the packets it sent? yes - the code treats all destination addresses the same. (This is useful for testing and to populate remote caches.) My patch works around the issue, but long term, I agree with Ralph. User space needs some other way to determine if this is needed. - Sean -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] ibacm: check for special handling of loopback requests
I guess what I'm objecting to is hard coding mlx4. I was trying to think of a way that would allow other HCAs to support the block loopback option in the future. It looks like ipoib sets IB_QP_CREATE_BLOCK_MULTICAST_LOOPBACK for kernel QPs but this isn't defined in libibverbs yet. If there's a per QP flag for kernel users, I don't understand why it was automatically disabled HCA wide. It seems reasonable to add that feature some time in the future and change ibacm to use it. In the mean time, I guess I don't see an alternative to your patch. The best alternative I can think of is to add a 'loopback' configuration option to acm. The benefits of being able to block loopback multicast traffic may be greater than anything gained by not doing so. I'll make this change and just use a default value that does not require loopback multicast. At some point, when libibverbs exposes this capability, acm can take advantage of it. - Sean -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mlx4: properly mask MGM entry members count
Where is the change in handling in the members_count field? In the firmware? The firmware now distinguishes between differnet multicast addresses according to a protocol field located in the high MS byte which previously was reserved. The patches that Alekseys will will probably send later make use of this. OK, so what you seem to be saying is that this patch is not fixing anything until we add Alekseys patches? - R. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3 v2] ibacm: Introduce loopback resolution 'protocol'
OFED 1.5.2 introduced a kernel patch that disables looping
back multicast messages to the sending QP. This capability
was enabled by default. The current ACM address resolution
protocol depends on this feature of multicast. To handle
the case where multicast loopback has been disabled, add an
option to ACM to resolve loopback addresses using local data
only. This option is enabled by default.
When loopback resolution is set to 'local', ACM will automatically
insert a loopback destination into each endpoint. Requests
to resolve a loopback address will find this destination
and use it to respond to client requests.
Signed-off-by: Sean Hefty sean.he...@intel.com
---
change from v1:
Used acm configuration option to specify loopback resolution rather
than reading from mlx4 module parameter file.
acm_opts.cfg |8 +++
src/acm.c| 62 ++
src/acme.c |8 +++
3 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/acm_opts.cfg b/acm_opts.cfg
index 3dbb0c6..65faac9 100644
--- a/acm_opts.cfg
+++ b/acm_opts.cfg
@@ -41,6 +41,14 @@ addr_prot acm
route_prot sa
+# loopback_prot:
+# Address and route resolution protocol to resolve local addresses
+# Supported protocols are:
+# none - Use same protocols defined for addr_prot and route_prot
+# local - Resolve information used locally available data
+
+loopback_prot local
+
# server_port:
# TCP port number that the server listens on.
# If this value is changed, then a corresponding change is required for
diff --git a/src/acm.c b/src/acm.c
index 77194ff..099518e 100644
--- a/src/acm.c
+++ b/src/acm.c
@@ -69,6 +69,12 @@ enum acm_route_prot
ACM_ROUTE_PROT_SA
};
+enum acm_loopback_prot
+{
+ ACM_LOOPBACK_PROT_NONE,
+ ACM_LOOPBACK_PROT_LOCAL
+};
+
/*
* Nested locking order: dest - ep, dest - port
*/
@@ -204,6 +210,7 @@ static char log_file[128] = stdout;
static int log_level = 0;
static enum acm_addr_prot addr_prot = ACM_ADDR_PROT_ACM;
static enum acm_route_prot route_prot = ACM_ROUTE_PROT_ACM;
+static enum acm_loopback_prot loopback_prot = ACM_LOOPBACK_PROT_LOCAL;
static short server_port = 6125;
static int timeout = 2000;
static int retries = 15;
@@ -2133,6 +2140,16 @@ static enum acm_route_prot acm_convert_route_prot(char
*param)
return route_prot;
}
+static enum acm_loopback_prot acm_convert_loopback_prot(char *param)
+{
+ if (!stricmp(none, param))
+ return ACM_LOOPBACK_PROT_NONE;
+ else if (!stricmp(local, param))
+ return ACM_LOOPBACK_PROT_LOCAL;
+
+ return loopback_prot;
+}
+
static enum ibv_rate acm_get_rate(uint8_t width, uint8_t speed)
{
switch (width) {
@@ -2294,6 +2311,43 @@ static int acm_assign_ep_names(struct acm_ep *ep)
return !index;
}
+static int acm_init_ep_loopback(struct acm_ep *ep)
+{
+ struct acm_dest *dest;
+ int i;
+
+ acm_log(2, \n);
+ if (loopback_prot != ACM_LOOPBACK_PROT_LOCAL)
+ return 0;
+
+ for (i = 0; i MAX_EP_ADDR ep-addr_type[i]; i++) {
+ dest = acm_acquire_dest(ep, ep-addr_type[i], ep-addr[i].addr);
+ if (!dest) {
+ acm_format_name(0, log_data, sizeof log_data,
+ ep-addr_type[i], ep-addr[i].addr,
+ sizeof ep-addr[i].addr);
+ acm_log(0, ERROR - unable to create loopback dest
%s\n, log_data);
+ return -1;
+ }
+
+ ibv_query_gid(ep-port-dev-verbs, ep-port-port_num,
+ 0, dest-path.sgid);
+
+ dest-path.dgid = dest-path.sgid;
+ dest-path.dlid = dest-path.slid = htons(ep-port-lid);
+ dest-path.reversible_numpath = IBV_PATH_RECORD_REVERSIBLE;
+ dest-path.pkey = htons(ep-pkey);
+ dest-path.mtu = (uint8_t) ep-port-mtu;
+ dest-path.rate = (uint8_t) ep-port-rate;
+
+ dest-remote_qpn = ep-qp-qp_num;
+ dest-state = ACM_READY;
+ acm_put_dest(dest);
+ acm_log(1, added loopback dest %s\n, dest-name);
+ }
+ return 0;
+}
+
static int acm_activate_ep(struct acm_port *port, struct acm_ep *ep, uint16_t
pkey_index)
{
struct ibv_qp_init_attr init_attr;
@@ -2383,6 +2437,11 @@ static int acm_activate_ep(struct acm_port *port, struct
acm_ep *ep, uint16_t pk
if (ret)
goto err2;
+ ret = acm_init_ep_loopback(ep);
+ if (ret) {
+ acm_log(0, ERROR - unable to init loopback\n);
+ goto err2;
+ }
return 0;
err2:
@@ -2599,6 +2658,8 @@ static void acm_set_options(void)
addr_prot = acm_convert_addr_prot(value);
else if (!stricmp(route_prot, opt))
route_prot = acm_convert_route_prot(value);
+
Re: [PATCH 0/3] IB Netlink Interface and RDMA CM exports
I was under the impression that a different module is appropriate here based on the structure of the IB modules and similar modules like netfilter_netlink, and other architectures in the kernel. However, I'm naturally open to other views. If the other way around is the consensus nowadays, and I'm in minority here, then certainly, things can be done the other way. I'd be happy to hear other views to concur/reject my view. I think we should probably put this in the core module rather than creating yet another module. I don't really see what the advantage of separating netlink into its own module is. We probably over-modularized the RDMA stack early on, it might in fact make sense to collapse things down from where they are now. In fact I'm not sure even for embedded it's worth making this something that can be configured out. We probably have too many config options that no one ever uses as it is. Are there any embedded systems that are both so small that a few K of code matters and also use RDMA? - R. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mxl4 and rpcrdma: connection to 192.168.0.100:20049 on mlx4_0, memreg 5 slots 32 ird 16
On Wed, Nov 17, 2010 at 12:43 PM, Steve Wise sw...@opengridcomputing.com wrote: I think NFSRDMA server will close the connection after 5 minutes of inactivity... Thanks Steve. I mistook the messages as being a problem that may have been related to nfs speed issues. I think it is something else now. Steve Steve. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mxl4 and rpcrdma: connection to 192.168.0.100:20049 on mlx4_0, memreg 5 slots 32 ird 16
Nov 15 09:39:00 node4 kernel: rpcrdma: connection to 192.168.0.100:20049 on mlx4_0, memreg 5 slots 32 ird 16 and then 5 minutes later: Nov 15 09:44:00 node4 kernel: rpcrdma: connection to 192.168.0.100:20049 closed (-103) I think NFSRDMA server will close the connection after 5 minutes of inactivity... Should the code be spamming the logs for normal events? (Or is this with an elevated log level) -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
building RDMA perftests with g++
I have what is probably a silly question If I compile the rdma_bw example from perftests with g++, it doesn't work... granted I have to make a few changes wrt structure initialization, but I would think it should behave as when built with gcc... I am getting an error message in pp_client_init/pp_server_init that ai_family SOCK_STREAM is not support for the port. If I use cma I get an unrecognized event on the client side... Am I missing something? I am trying to develop some C++ classes with RDMA/verbs. Thanks, Ed -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] svcrdma: Change DMA mapping logic to avoid the page_address kernel API
On 11/16/10 1:39 PM, Or Gerlitz wrote: Tom Tuckert...@ogc.us wrote: This patch changes the bus mapping logic to avoid page_address() where necessary Hi Tom, Does when necessary comes to say that invocations of page_address which remained in the code after this patch was applied are safe and no kmap call is needed? That's the premise. Please let me know if something looks suspicious. Thanks, Tom Or. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mlx4: properly mask MGM entry members count
On Wed, Nov 17, 2010 at 09:38:47AM -0800, Roland Dreier wrote: Where is the change in handling in the members_count field? In the firmware? The firmware now distinguishes between differnet multicast addresses according to a protocol field located in the high MS byte which previously was reserved. The patches that Alekseys will will probably send later make use of this. OK, so what you seem to be saying is that this patch is not fixing anything until we add Alekseys patches? It only keeps the code and the PRM in sync. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] IB Netlink Interface and RDMA CM exports
On Wed, Nov 17, 2010 at 01:34:29PM -0800, Roland Dreier wrote: In fact I'm not sure even for embedded it's worth making this something that can be configured out. We probably have too many config options that no one ever uses as it is. Are there any embedded systems that are both so small that a few K of code matters and also use RDMA? I experimented with re-tasking rxe to act as a soft-IB. The only reason to do this was to run IPOIB, and the system was very small. So in that instance I did benefit from running without may of the IB modules - but I would have been entirely happy with a CONFIG_XX controlled by CONFIG_EMBEDDED, since the system didn't use modules at all anyhow. I agree that there are too many IB modules - the main problem is that they do not demand-load. Just today I had to walk someone through loading rdma_ucm because the system was brand new Ubuntu and there is no automatic script to load them. There is sort of a general failing of the module dependency/autoload system here that would be awesome to fix.. Jason -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
