Re: [openib-general] [PATCH] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
I just noticed that once i apply the patch, the last + lines (that is pthread_mutex_lock, while loop doing pthread_cond_wait and then pthread_mutex_unlock) become part of rdma_leave_multicast which seems to me strictly buggy as no one is going to wake up this code. The leave must wait until all events have been reported on the multicast group. There can be more than one event on a group if an error occurs. See ucma_complete_mc_event() for where the condition is signaled. - 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
On 1/8/07, Sean Hefty [EMAIL PROTECTED] wrote: I just noticed that once i apply the patch, the last + lines (that is pthread_mutex_lock, while loop doing pthread_cond_wait and then pthread_mutex_unlock) become part of rdma_leave_multicast which seems to me strictly buggy as no one is going to wake up this code. The leave must wait until all events have been reported on the multicast group. There can be more than one event on a group if an error occurs. See ucma_complete_mc_event() for where the condition is signaled. OK, got you, however printing resp-events_reported after the write call returns shows complete junk most of the times where as you explain here it should be 1 unless some error occurs. Looking on the ucma kernel code under http://www2.openfabrics.org/git/?p=~shefty/rdma-dev.git;a=blob;f=drivers/infiniband/core/ucma.c I think to see the bug: there is no copy_to_user() before ucma_leave_multicast() returns and hence the response structure at rdma_leave_multicast of librdmacm is not set to anything, what do you say? 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
On 1/8/07, Or Gerlitz [EMAIL PROTECTED] wrote: explain here it should be 1 unless some error occurs. Looking on the ucma kernel code under http://www2.openfabrics.org/git/?p=~shefty/rdma-dev.git;a=blob;f=drivers/infiniband/core/ucma.c I have looked in the multicast-sa_cache branch. 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
I think to see the bug: there is no copy_to_user() before ucma_leave_multicast() returns and hence the response structure at rdma_leave_multicast of librdmacm is not set to anything, what do you say? This looks like problem. I wonder how this is working for me at all... maybe the response structure is being initialized to 0, but this doesn't match up with your debug output... I will look into this more, but the copy_to_user definitely seems to be missing. - 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
On 1/8/07, Sean Hefty [EMAIL PROTECTED] wrote: I think to see the bug: there is no copy_to_user() before ucma_leave_multicast() returns and hence the response structure at rdma_leave_multicast of librdmacm is not set to anything, what do you say? This looks like problem. I wonder how this is working for me at all... I don't think mckey calls rdma_leave_multicast so maybe this is why you did not notice the problem? 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
On 1/8/07, Sean Hefty [EMAIL PROTECTED] wrote: I just noticed that once i apply the patch, the last + lines (that is pthread_mutex_lock, while loop doing pthread_cond_wait and then pthread_mutex_unlock) become part of rdma_leave_multicast which seems to me strictly buggy as no one is going to wake up this code. The leave must wait until all events have been reported on the multicast group. There can be more than one event on a group if an error occurs. See ucma_complete_mc_event() for where the condition is signaled. let me see i follow your design: mc-events_completed is incremented in the library when the consumer calls rdma_ack_cm_event() and resp-events_reported is incremeted in the kernel called when the user calls rdma_get_cm_event() ? If this is indeed the case, the design seems fine to me, else it might be problematic eg if it does not support the case where there was multicast error but the user did not consume the associated event and now want to call rdma_leave_multicast(). 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
I don't think mckey calls rdma_leave_multicast so maybe this is why you did not notice the problem? Yep - this was the case. I've updated mckey and created a patch for the kernel, which I'll push out through my rdma-dev tree shortly. Thanks for the report. - 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
Are you wanting the rdma cm to join the same multicast groups that ipoib does? (This is simple to change, but it does not join the same groups today.) Actually, yes, we strogly prefer that you will remove the rdma cm signature byte from MGIDs generated by the cma. Would there be any issues that result from allowing this that requires more restrictive access to joining the groups? - 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
Sean Hefty wrote: Are you wanting the rdma cm to join the same multicast groups that ipoib does? (This is simple to change, but it does not join the same groups today.) Actually, yes, we strogly prefer that you will remove the rdma cm signature byte from MGIDs generated by the cma. Would there be any issues that result from allowing this that requires more restrictive access to joining the groups? I don't think so, generally speaking, using multicast has its security drawbacks eg as was mentioned by Roland earlier on this thread, however I don't see how the rdma cm MGID signature byte provides meaningful help against them. 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
On 11/2/06, Sean Hefty [EMAIL PROTECTED] wrote: Have you looked on that? from the compilation failure against libibverbs-1.0 the gap seem pretty small. If indeed this is the case, since libibverbs-1.1 is in development lets check with Roland if it makes sense for him to support these small-gap-features in libibverbs-1.0.X, i guess what matters here is ABI versions... I have not had time to look into this yet. I see, this is of great importance, but in second priority i think to the kernel push (we are now in post -rc4 time frame, which means 2.6.20 is going to get open within few weeks...). However, if u/k ABI issues are involved here, we might get into troubles... anyway, whenever you have some time... I think we do want it. The rdma cm provide the means to offload ip multicast to ib multicast though registration (join/leave etc) with the ib_sa module. IP Multicast does use the send-only feature and hence IP Multicast offloading apps need it as well. The rdma cm framework fits very well for such apps and the ib_usa (which does not exist now, and i am not sure needs to exist... it was a project of a summer student with open-mpi that required that...) not. Are you wanting the rdma cm to join the same multicast groups that ipoib does? (This is simple to change, but it does not join the same groups today.) Actually, yes, we strogly prefer that you will remove the rdma cm signature byte from MGIDs generated by the cma. I will likely need to spin these patches again to incorporate the changes for path failover, so adding in join options wouldn't be difficult. Are you just wanting to see them added the rdma_join_multicast directly? Yes, i'd like to have the rdma cm consumer being able to specify if it want to be joined as full member vs join as send only. This would also have an impact on the rdma cm calling the qp attach to mgid verb for the first case, only. 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
Sean,
This patch removes rdma_get/set_option(). Is that what you intended?
On Wed, 2006-10-25 at 13:49 -0700, Sean Hefty wrote:
Updates the librdmacm to work with ABI version 3, which is the proposed
kernel changes for inclusion in 2.6.20.
Test programs are also updated.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
Index: include/rdma/rdma_cma_abi.h
===
--- include/rdma/rdma_cma_abi.h (revision 9192)
+++ include/rdma/rdma_cma_abi.h (working copy)
@@ -33,14 +33,15 @@
#ifndef RDMA_CMA_ABI_H
#define RDMA_CMA_ABI_H
+#include infiniband/kern-abi.h
#include infiniband/sa-kern-abi.h
/*
* This file must be kept in sync with the kernel's version of rdma_user_cm.h
*/
-#define RDMA_USER_CM_MIN_ABI_VERSION 1
-#define RDMA_USER_CM_MAX_ABI_VERSION 2
+#define RDMA_USER_CM_MIN_ABI_VERSION 3
+#define RDMA_USER_CM_MAX_ABI_VERSION 3
#define RDMA_MAX_PRIVATE_DATA256
@@ -60,7 +61,7 @@ enum {
UCMA_CMD_GET_EVENT,
UCMA_CMD_GET_OPTION,
UCMA_CMD_SET_OPTION,
- UCMA_CMD_GET_DST_ATTR,
+ UCMA_CMD_ESTABLISH,
UCMA_CMD_JOIN_MCAST,
UCMA_CMD_LEAVE_MCAST
};
@@ -71,11 +72,6 @@ struct ucma_abi_cmd_hdr {
__u16 out;
};
-struct ucma_abi_create_id_v1 {
- __u64 uid;
- __u64 response;
-};
-
struct ucma_abi_create_id {
__u64 uid;
__u64 response;
@@ -133,7 +129,7 @@ struct ucma_abi_query_route_resp {
struct ucma_abi_conn_param {
__u32 qp_num;
- __u32 qp_type;
+ __u32 reserved;
__u8 private_data[RDMA_MAX_PRIVATE_DATA];
__u8 private_data_len;
__u8 srq;
@@ -145,6 +141,15 @@ struct ucma_abi_conn_param {
__u8 valid;
};
+struct ucma_abi_ud_param {
+ __u32 qp_num;
+ __u32 qkey;
+ struct ibv_kern_ah_attr ah_attr;
+ __u8 private_data[RDMA_MAX_PRIVATE_DATA];
+ __u8 private_data_len;
+ __u8 reserved[7];
+};
+
struct ucma_abi_connect {
struct ucma_abi_conn_param conn_param;
__u32 id;
@@ -180,25 +185,13 @@ struct ucma_abi_init_qp_attr {
__u32 qp_state;
};
-struct ucma_abi_join_mcast {
- __u32 id;
- struct sockaddr_in6 addr;
- __u64 uid;
-};
-
-struct ucma_abi_leave_mcast {
+struct ucma_abi_establish {
__u32 id;
- struct sockaddr_in6 addr;
-};
-
-struct ucma_abi_dst_attr_resp {
- __u32 remote_qpn;
- __u32 remote_qkey;
- struct ibv_kern_ah_attr ah_attr;
};
-struct ucma_abi_get_dst_attr {
- __u64 response;
+struct ucma_abi_join_mcast {
+ __u64 response; /* ucma_abi_create_id_resp */
+ __u64 uid;
struct sockaddr_in6 addr;
__u32 id;
};
@@ -212,30 +205,10 @@ struct ucma_abi_event_resp {
__u32 id;
__u32 event;
__u32 status;
- __u8 private_data_len;
- __u8 reserved[3];
- __u8 private_data[RDMA_MAX_PRIVATE_DATA];
-};
-
-struct ucma_abi_get_option {
- __u64 response;
- __u64 optval;
- __u32 id;
- __u32 level;
- __u32 optname;
- __u32 optlen;
-};
-
-struct ucma_abi_get_option_resp {
- __u32 optlen;
-};
-
-struct ucma_abi_set_option {
- __u64 optval;
- __u32 id;
- __u32 level;
- __u32 optname;
- __u32 optlen;
+ union {
+ struct ucma_abi_conn_param conn;
+ struct ucma_abi_ud_param ud;
+ } param;
};
#endif /* RDMA_CMA_ABI_H */
Index: include/rdma/rdma_cma.h
===
--- include/rdma/rdma_cma.h (revision 9272)
+++ include/rdma/rdma_cma.h (working copy)
@@ -61,11 +61,11 @@ enum rdma_port_space {
RDMA_PS_UDP = 0x0111,
};
-/* Protocol levels for get/set options. */
-enum {
- RDMA_PROTO_IP = 0,
- RDMA_PROTO_IB = 1,
-};
+/*
+ * Global qkey value for all UD QPs and multicast groups created via the
+ * RDMA CM.
+ */
+#define RDMA_UD_QKEY 0x01234567
struct ib_addr {
union ibv_gid sgid;
@@ -74,8 +74,12 @@ struct ib_addr {
};
struct rdma_addr {
- struct sockaddr_in6 src_addr;
- struct sockaddr_in6 dst_addr;
+ struct sockaddr src_addr;
+ uint8_t src_pad[sizeof(struct sockaddr_storage) -
+ sizeof(struct sockaddr)];
+ struct sockaddr dst_addr;
+ uint8_t dst_pad[sizeof(struct sockaddr_storage) -
+ sizeof(struct sockaddr)];
union {
struct ib_addr ibaddr;
} addr;
@@ -101,11 +105,25 @@ struct rdma_cm_id {
uint8_t port_num;
};
-struct rdma_multicast_data {
- void*context;
- struct sockaddr addr;
- uint8_t pad[sizeof(struct sockaddr_in6) -
- sizeof(struct sockaddr)];
+struct rdma_conn_param {
+
Re: [openib-general] [PATCH] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
Sean Hefty wrote: Sean Hefty wrote: One of the systems kernel is actually 2.6.19-rc3 and patches 1-7 (ie not roland's tree) and i see there some issues also with ip multicast over ipoib. I will move to use the same kernel config (roland's tree and patches 1-7), then test ipoib and only then mckey, will let you know. Will you have the chance to test ipoib multicast and mckey over this config at your environment? This seemed to work fine for me in loopback mode. I'm updating another test system to check between systems now. OK, ip multicast through ipoib works fine in my config, rping also works fine. However, mckey does not work. The receiver never polls anything from its cq. Adding some debug prints at librdmacm and mckey everything seems to be fine (both sender and receiver use same/correct mgid/mlid, the sender when creating its ah and the receiver when joining etc). The only thing i found was that the remote_qpn used for post sending was not 0xff but fixing this did not help. Below are some prints from the receiver, the sender and the SM, where i can see that both ports joined the same/correct mgid. Please let me know if you manage to get mckey working in non loopback mode and if yes, if you have an idea how can i further debug my config. thanks, Or. [EMAIL PROTECTED] librdmacm]# /home/ogerlitz/ib1.1/bin/mckey -m 224.5.5.5 mckey: starting server mckey: joining rdma_create_qp: created qp 0x505b00 ucma_process_join attaching to mlid c008 mgid ff12:4001:::::0005:0505 ucma_process_join: calling ibv_attach_mcast qp 0x505b00 rdma_get_cm_event: ucma_process_join returned 0 join handler, params: dlid c008 join handler, params: qp_num ff receiving data transfers [EMAIL PROTECTED] src]# /home/ogerlitz/ib1.1/bin/mckey -m 224.5.5.5 -s -C 10240 -S 1024 mckey: starting client mckey: joining rdma_create_qp: created qp 0x503c80 ucma_process_join attaching to mlid c008 mgid ff12:4001:::::0005:0505 ucma_process_join: calling ibv_attach_mcast qp 0x503c80 rdma_get_cm_event: ucma_process_join returned 0 join handler, params: dlid c008 join handler, params: qp_num ff initiating data transfers data transfers complete test complete return status 0 SM prints MCG MLID 0xC008 MGID 0xff12400100050505 0x0008f104039708dd 1 0x0003 0x0008f104039708dc 0008f104039708dc 0.0.0.0 0x0008f104039708fd 1 0x0007 0x0008f104039708fc 0008f104039708fc 0.0.0.0 ___ 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
Or Gerlitz wrote: Sean Hefty wrote: Sean Hefty wrote: One of the systems kernel is actually 2.6.19-rc3 and patches 1-7 (ie not roland's tree) and i see there some issues also with ip multicast over ipoib. I will move to use the same kernel config (roland's tree and patches 1-7), then test ipoib and only then mckey, will let you know. Will you have the chance to test ipoib multicast and mckey over this config at your environment? This seemed to work fine for me in loopback mode. I'm updating another test system to check between systems now. OK, ip multicast through ipoib works fine in my config, rping also works fine. However, mckey does not work. The receiver never polls anything from its cq. Adding some debug prints at librdmacm and mckey everything seems to be fine (both sender and receiver use same/correct mgid/mlid, the sender when creating its ah and the receiver when joining etc). The only thing i found was that the remote_qpn used for post sending was not 0xff but fixing this did not help. Below are some prints from the receiver, the sender and the SM, where i can see that both ports joined the same/correct mgid. Please let me know if you manage to get mckey working in non loopback mode and if yes, if you have an idea how can i further debug my config. I see now that if i am making the mckey sender also poll the cq, it never gets any completion! I have verified now that udaddy works fine, so basically the libibverbs IB UD (udadday) and RC (rping) support works well for the librdmacm examples. 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
Or Gerlitz wrote: Please let me know if you manage to get mckey working in non loopback mode and if yes, if you have an idea how can i further debug my config. I did get mckey working fine in non loopback mode. [EMAIL PROTECTED] librdmacm]# /home/ogerlitz/ib1.1/bin/mckey -m 224.5.5.5 [EMAIL PROTECTED] src]# /home/ogerlitz/ib1.1/bin/mckey -m 224.5.5.5 -s -C 10240 -S 1024 You need to use the same message parameters (count and size) for both sender and receiver. - 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
Or Gerlitz wrote: Or Gerlitz wrote: OK, Sean, i have one system up and running, with kernel based on Roland's git plus patches 1-7 and user space based on the svn with the librdmacm patch. Will clone this config on Sunday such that i can actually run mckey and see it working. Thanks a lot for putting everything together... rping works fine in this environment, mckey not yet. From the switch logs i see that both processes/ports (sender, receiver) joined the same/correct mgid and from prints i have added to mckey i see that both use the same mdlid. however, the receiver does not get completions from its cq. I will further investigate this and let you know. Sean, One of the systems kernel is actually 2.6.19-rc3 and patches 1-7 (ie not roland's tree) and i see there some issues also with ip multicast over ipoib. I will move to use the same kernel config (roland's tree and patches 1-7), then test ipoib and only then mckey, will let you know. Will you have the chance to test ipoib multicast and mckey over this config at your environment? 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
Sean Hefty wrote: One of the systems kernel is actually 2.6.19-rc3 and patches 1-7 (ie not roland's tree) and i see there some issues also with ip multicast over ipoib. I will move to use the same kernel config (roland's tree and patches 1-7), then test ipoib and only then mckey, will let you know. Will you have the chance to test ipoib multicast and mckey over this config at your environment? This seemed to work fine for me in loopback mode. I'm updating another test system to check between systems now. - 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
Or Gerlitz wrote: Sean Hefty wrote: Updates the librdmacm to work with ABI version 3, which is the proposed kernel changes for inclusion in 2.6.20. Test programs are also updated. OK, Sean, i have one system up and running, with kernel based on Roland's git plus patches 1-7 and user space based on the svn with the librdmacm patch. Will clone this config on Sunday such that i can actually run mckey and see it working. Thanks a lot for putting everything together... rping works fine in this environment, mckey not yet. From the switch logs i see that both processes/ports (sender, receiver) joined the same/correct mgid and from prints i have added to mckey i see that both use the same mdlid. however, the receiver does not get completions from its cq. I will further investigate this and let you know. 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
Sean/Roland, FYI: I'm running with: linus's 2.6.19-rc3 git tree + Sean's 7 kernel patches that include ucma + Sean's librdmacm patch + my 2 amso kernel fixes + the libamso library. I'm successfully running user mode rping over the Ammasso rnic on this setup. :-) Steve. On Wed, 2006-10-25 at 13:49 -0700, Sean Hefty wrote: Updates the librdmacm to work with ABI version 3, which is the proposed kernel changes for inclusion in 2.6.20. ___ 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
Michael S. Tsirkin wrote: Might it be a good idea to keep min ABI at 1, so that the library works e.g. against OFED kernel components? I looked at this, but the API to the library changed in such a way that it's difficult to provide support for older kernel ABI versions with the updated userspace APIs. This is in part because older kernel components did not provide connection parameters as part of their events. I'm definitely for trying to support older ABIs, I just don't see a good way to do so. - 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
Sean Hefty wrote: Updates the librdmacm to work with ABI version 3, which is the proposed kernel changes for inclusion in 2.6.20. Test programs are also updated. OK, Sean, i have one system up and running, with kernel based on Roland's git plus patches 1-7 and user space based on the svn with the librdmacm patch. Will clone this config on Sunday such that i can actually run mckey and see it working. Thanks a lot for putting everything together... Anyway, during working on that i have noted two issues which need to be addressed: 1) librdmacm does not get built against libibverbs-1.0 (see below) so i am using libibverbs (ie the non released yet libibverbs1.1) 2) the cma rdma multicast does not let a consumer to join as send-only Or. Path: . URL: https://openib.org/svn/gen2/trunk/src/userspace/librdmacm Repository UUID: 21a7a0b7-18d7-0310-8e21-e8b31bdbf5cd Revision: 9963 Node Kind: directory Schedule: normal Last Changed Author: swise Last Changed Rev: 9898 Last Changed Date: 2006-10-19 15:08:19 +0200 (Thu, 19 Oct 2006) make all-am make[1]: Entering directory `/home/ogerlitz/openib/infiniband-user-9963/librdmacm' if /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -I./include -g -Wall -D_GNU_SOURCE -I/home/ogerlitz/ib/include -MT cma.lo -MD -MP -MF .deps/cma.Tpo -c -o cma.lo `test -f 'src/cma.c' || echo './'`src/cma.c; \ then mv -f .deps/cma.Tpo .deps/cma.Plo; else rm -f .deps/cma.Tpo; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I. -I./include -g -Wall -D_GNU_SOURCE -I/home/ogerlitz/ib/include -MT cma.lo -MD -MP -MF .deps/cma.Tpo -c src/cma.c -fPIC -DPIC -o .libs/cma.o src/cma.c: In function `rdma_disconnect': src/cma.c:901: error: structure has no member named `transport_type' src/cma.c:902: error: `IBV_TRANSPORT_IB' undeclared (first use in this function) src/cma.c:902: error: (Each undeclared identifier is reported only once src/cma.c:902: error: for each function it appears in.) src/cma.c:905: error: `IBV_TRANSPORT_IWARP' undeclared (first use in this function) src/cma.c: In function `ucma_copy_ud_event': src/cma.c:1177: warning: implicit declaration of function `ibv_copy_ah_attr_from_kern' make[1]: *** [cma.lo] Error 1 make[1]: Leaving directory `/home/ogerlitz/openib/infiniband-user-9963/librdmacm' make: *** [all] Error 2 ___ 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
1) librdmacm does not get built against libibverbs-1.0 (see below) so i am using libibverbs (ie the non released yet libibverbs1.1) I need to think about what we can do here. The librdmacm uses functionality not found in libibverbs-1.0. 2) the cma rdma multicast does not let a consumer to join as send-only This would require some sort of change to the API and ABI, so if this is needed, I'd like to incorporate this now. (Adding it could be done by specifying join parameters.) Do we need/want this level of control in the librdmacm, or should users go to a direct IB interface for this? - 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] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA
Quoting r. Sean Hefty [EMAIL PROTECTED]: Subject: [PATCH] librdmacm: updated librdmacm to work with proposed 2.6.20 kernel CMA Updates the librdmacm to work with ABI version 3, which is the proposed kernel changes for inclusion in 2.6.20. Test programs are also updated. Signed-off-by: Sean Hefty [EMAIL PROTECTED] --- Index: include/rdma/rdma_cma_abi.h === --- include/rdma/rdma_cma_abi.h (revision 9192) +++ include/rdma/rdma_cma_abi.h (working copy) @@ -33,14 +33,15 @@ #ifndef RDMA_CMA_ABI_H #define RDMA_CMA_ABI_H +#include infiniband/kern-abi.h #include infiniband/sa-kern-abi.h /* * This file must be kept in sync with the kernel's version of rdma_user_cm.h */ -#define RDMA_USER_CM_MIN_ABI_VERSION 1 -#define RDMA_USER_CM_MAX_ABI_VERSION 2 +#define RDMA_USER_CM_MIN_ABI_VERSION 3 +#define RDMA_USER_CM_MAX_ABI_VERSION 3 Might it be a good idea to keep min ABI at 1, so that the library works e.g. against OFED kernel components? -- 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
