Re: sysfs IPoIB root owned writable files
the following files created under /sys which are world writeable
/sys/class/net/ib0/delete_child /sys/class/net/ib0/create_child
At least the create_child delete_child files appear to be dangerous to leave
as world writeable because they result in resources allocations.
Roland,
If I see a patch in linux-rdma patchwork, e.g
https://patchwork.kernel.org/patch/104502 with the below patch, does
this mean it will get to be reviewed/merged towards 2.6.36, or you
prefer a reminder on the list?
Or.
Yes, this looks bad. The below patch fixes that, I tested it on 2.6.35-rc1
[PATCH] make ipoib child entries non-world writable
Sumeet Lahorani sumeet.lahor...@oracle.com reported that the ipoib
child entries are world writable, fix them to be root only writable
Signed-off-by: Or Gerlitz ogerl...@voltaire.com
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index df3eb8c..b4b2257 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1163,7 +1163,7 @@ static ssize_t create_child(struct device *dev,
return ret ? ret : count;
}
-static DEVICE_ATTR(create_child, S_IWUGO, NULL, create_child);
+static DEVICE_ATTR(create_child, S_IWUSR, NULL, create_child);
static ssize_t delete_child(struct device *dev,
struct device_attribute *attr,
@@ -1183,7 +1183,7 @@ static ssize_t delete_child(struct device *dev,
return ret ? ret : count;
}
-static DEVICE_ATTR(delete_child, S_IWUGO, NULL, delete_child);
+static DEVICE_ATTR(delete_child, S_IWUSR, NULL, delete_child);
int ipoib_add_pkey_attr(struct net_device *dev)
{
--
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] opensm: event plig-in API fixed to compile with g++
Event API should have been able to be used by libraries
written both in C and C++. The problem is, one of the
fields in struct osm_event_plugin is called delete.
Changing it to destroy and promoting the API version.
Signed-off-by: Yevgeny Kliteynik klit...@dev.mellanox.co.il
---
opensm/include/opensm/osm_event_plugin.h|2 +-
opensm/opensm/osm_event_plugin.c|4 ++--
opensm/osmeventplugin/libosmeventplugin.ver |2 +-
opensm/osmeventplugin/src/osmeventplugin.c |2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/opensm/include/opensm/osm_event_plugin.h
b/opensm/include/opensm/osm_event_plugin.h
index 0b3464e..aa3fed4 100644
--- a/opensm/include/opensm/osm_event_plugin.h
+++ b/opensm/include/opensm/osm_event_plugin.h
@@ -145,7 +145,7 @@ typedef struct osm_api_ps_event {
typedef struct osm_event_plugin {
const char *osm_version;
void *(*create) (struct osm_opensm *osm);
- void (*delete) (void *plugin_data);
+ void (*destroy) (void *plugin_data);
void (*report) (void *plugin_data, osm_epi_event_id_t event_id,
void *event_data);
} osm_event_plugin_t;
diff --git a/opensm/opensm/osm_event_plugin.c b/opensm/opensm/osm_event_plugin.c
index 2d67065..7f61960 100644
--- a/opensm/opensm/osm_event_plugin.c
+++ b/opensm/opensm/osm_event_plugin.c
@@ -141,8 +141,8 @@ DLOPENFAIL:
void osm_epi_destroy(osm_epi_plugin_t * plugin)
{
if (plugin) {
- if (plugin-impl-delete)
- plugin-impl-delete(plugin-plugin_data);
+ if (plugin-impl-destroy)
+ plugin-impl-destroy(plugin-plugin_data);
dlclose(plugin-handle);
free(plugin-plugin_name);
free(plugin);
diff --git a/opensm/osmeventplugin/libosmeventplugin.ver
b/opensm/osmeventplugin/libosmeventplugin.ver
index f755ff6..0c3a85b 100644
--- a/opensm/osmeventplugin/libosmeventplugin.ver
+++ b/opensm/osmeventplugin/libosmeventplugin.ver
@@ -6,4 +6,4 @@
# API_REV - advance on any added API
# RUNNING_REV - advance any change to the vendor files
# AGE - number of backward versions the API still supports
-LIBVERSION=1:0:0
+LIBVERSION=2:0:0
diff --git a/opensm/osmeventplugin/src/osmeventplugin.c
b/opensm/osmeventplugin/src/osmeventplugin.c
index f40f7fe..a82be07 100644
--- a/opensm/osmeventplugin/src/osmeventplugin.c
+++ b/opensm/osmeventplugin/src/osmeventplugin.c
@@ -207,6 +207,6 @@ static void report(void *_log, osm_epi_event_id_t event_id,
void *event_data)
osm_event_plugin_t osm_event_plugin = {
osm_version:OSM_VERSION,
create:construct,
- delete:destroy,
+ destroy:destroy,
report:report
};
--
1.5.1.4
--
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 synchronous operations
Hi all,
I’m testing the latency time of an RDMA system (2 card and 1 switch).
The connection server/client is established and the code is just as
mirror on both sides.
The RDMA action scheme is below:
1- client sends a buffer;
2- server receives a buffer;
3- server sends a buffer;
4- client receives a buffer.
The scheme is in a for loop, so after step 4 client repeats step 1.
On client side I put a clock: t_start is before loop and t_end is after
loop.
I consider the round trip time RTT as (t_end-t_start)/NTX where NTX is
number of transfer (number of loop). The latency time is half RTT, if
transfer time is negligible, i.e. for small (8 Bytes – 4 Kbytes) buffer
size and high NTX value ( 1) is true.
The RDMA communication stops casually with error status 5. It means that
the send or receive operation on one side (server or client) casually is
not in time. I summarize post_send and post_receive operation are
quasi-synchronous. I would like that RDMA operation are completely
synchronous. I use the completion queue and the acknowledgement event.
Do you see the same character in other RDMA use? How can I synchronize
all RDMA operation?
Could you please give me some suggestions?
Thank you very much,
Andrea
Example of structure code:
Ibv_recv_wr rrq(mr), *bad_rrq;
assert(!conn-post_recv(rrq, bad_rrq, 0));
assert(!conn-get_completion(compl_queue));
//printf(ok %p %s
, compl_queue, strerror(errno));
assert(1 == compl_queue-poll(1, wc));
//printf(status %i
, (int)wc.status);
if (wc.status !=0){
printf(RDMA server closes.
);
break;
}
-
Ibv_send_wr srq((void *)rpd-address, rpd-rkey), *bad_srq;
srq.add_sge(mr);
assert(!conn.post_send(srq, bad_srq, 0));
assert(!conn.get_completion(compl_queue));
assert(1 == compl_queue-poll(1, wc));
//printf(ok %p %s status %i
, compl_queue, strerror(errno), wc.status);
//printf(loop %i
, i);
if (wc.status != 0){
//printf(KO %p %s status %i
, compl_queue, strerror(errno), wc.status);
printf(RDMA data sending problem in loop %i.
, i);
break;
}
---
Andrea Gozzelino
INFN - Laboratori Nazionali di Legnaro (LNL)
Viale dell'Universita' 2 -I-35020 - Legnaro (PD)- ITALIA
Office: E-101
Tel: +39 049 8068346
Fax: +39 049 641925
Mail: andrea.gozzel...@lnl.infn.it
Cell: +39 3488245552
--
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 synchronous operations
Hi all,
I’m testing the latency time of an RDMA system (2 card and 1 switch).
The connection server/client is established and the code is just as
mirror on both sides.
The RDMA action scheme is below:
1- client sends a buffer;
2- server receives a buffer;
3- server sends a buffer;
4- client receives a buffer.
The scheme is in a for loop, so after step 4 client repeats step 1.
On client side I put a clock: t_start is before loop and t_end is after
loop.
I consider the round trip time RTT as (t_end-t_start)/NTX where NTX is
number of transfer (number of loop). The latency time is half RTT, if
transfer time is negligible, i.e. for small (8 Bytes – 4 Kbytes) buffer
size and high NTX value ( 1) is true.
The RDMA communication stops casually with error status 5. It means that
the send or receive operation on one side (server or client) casually is
not in time. I summarize post_send and post_receive operation are
quasi-synchronous. I would like that RDMA operation are completely
synchronous. I use the completion queue and the acknowledgement event.
Do you see the same character in other RDMA use? How can I synchronize
all RDMA operation?
Could you please give me some suggestions?
Thank you very much,
Andrea
Example of structure code:
Ibv_recv_wr rrq(mr), *bad_rrq;
assert(!conn-post_recv(rrq, bad_rrq, 0));
assert(!conn-get_completion(compl_queue));
//printf(ok %p %s
, compl_queue, strerror(errno));
assert(1 == compl_queue-poll(1, wc));
//printf(status %i
, (int)wc.status);
if (wc.status !=0){
printf(RDMA server closes.
);
break;
}
-
Ibv_send_wr srq((void *)rpd-address, rpd-rkey), *bad_srq;
srq.add_sge(mr);
assert(!conn.post_send(srq, bad_srq, 0));
assert(!conn.get_completion(compl_queue));
assert(1 == compl_queue-poll(1, wc));
//printf(ok %p %s status %i
, compl_queue, strerror(errno), wc.status);
//printf(loop %i
, i);
if (wc.status != 0){
//printf(KO %p %s status %i
, compl_queue, strerror(errno), wc.status);
printf(RDMA data sending problem in loop %i.
, i);
break;
}
---
Andrea Gozzelino
INFN - Laboratori Nazionali di Legnaro (LNL)
Viale dell'Universita' 2 -I-35020 - Legnaro (PD)- ITALIA
Office: E-101
Tel: +39 049 8068346
Fax: +39 049 641925
Mail: andrea.gozzel...@lnl.infn.it
Cell: +39 3488245552
--
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 synchronous operations
Hi all,
I’m testing the latency time of an RDMA system (2 card and 1 switch).
The connection server/client is established and the code is just as
mirror on both sides.
The RDMA action scheme is below:
1- client sends a buffer;
2- server receives a buffer;
3- server sends a buffer;
4- client receives a buffer.
The scheme is in a for loop, so after step 4 client repeats step 1.
On client side I put a clock: t_start is before loop and t_end is after
loop.
I consider the round trip time RTT as (t_end-t_start)/NTX where NTX is
number of transfer (number of loop). The latency time is half RTT, if
transfer time is negligible, i.e. for small (8 Bytes – 4 Kbytes) buffer
size and high NTX value ( 1) is true.
The RDMA communication stops casually with error status 5. It means that
the send or receive operation on one side (server or client) casually is
not in time. I summarize post_send and post_receive operation are
quasi-synchronous. I would like that RDMA operation are completely
synchronous. I use the completion queue and the acknowledgement event.
Do you see the same character in other RDMA use? How can I synchronize
all RDMA operation?
Could you please give me some suggestions?
Thank you very much,
Andrea
Example of structure code:
Ibv_recv_wr rrq(mr), *bad_rrq;
assert(!conn-post_recv(rrq, bad_rrq, 0));
assert(!conn-get_completion(compl_queue));
//printf(ok %p %s
, compl_queue, strerror(errno));
assert(1 == compl_queue-poll(1, wc));
//printf(status %i
, (int)wc.status);
if (wc.status !=0){
printf(RDMA server closes.
);
break;
}
-
Ibv_send_wr srq((void *)rpd-address, rpd-rkey), *bad_srq;
srq.add_sge(mr);
assert(!conn.post_send(srq, bad_srq, 0));
assert(!conn.get_completion(compl_queue));
assert(1 == compl_queue-poll(1, wc));
//printf(ok %p %s status %i
, compl_queue, strerror(errno), wc.status);
//printf(loop %i
, i);
if (wc.status != 0){
//printf(KO %p %s status %i
, compl_queue, strerror(errno), wc.status);
printf(RDMA data sending problem in loop %i.
, i);
break;
}
---
Andrea Gozzelino
INFN - Laboratori Nazionali di Legnaro (LNL)
Viale dell'Universita' 2 -I-35020 - Legnaro (PD)- ITALIA
Office: E-101
Tel: +39 049 8068346
Fax: +39 049 641925
Mail: andrea.gozzel...@lnl.infn.it
Cell: +39 3488245552
--
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 synchronous operations
Hi all,
I’m testing the latency time of an RDMA system (2 card and 1 switch).
The connection server/client is established and the code is just as
mirror on both sides.
The RDMA action scheme is below:
1- client sends a buffer;
2- server receives a buffer;
3- server sends a buffer;
4- client receives a buffer.
The scheme is in a for loop, so after step 4 client repeats step 1.
On client side I put a clock: t_start is before loop and t_end is after
loop.
I consider the round trip time RTT as (t_end-t_start)/NTX where NTX is
number of transfer (number of loop). The latency time is half RTT, if
transfer time is negligible, i.e. for small (8 Bytes – 4 Kbytes) buffer
size and high NTX value ( 1) is true.
The RDMA communication stops casually with error status 5. It means that
the send or receive operation on one side (server or client) casually is
not in time. I summarize post_send and post_receive operation are
quasi-synchronous. I would like that RDMA operation are completely
synchronous. I use the completion queue and the acknowledgement event.
Do you see the same character in other RDMA use? How can I synchronize
all RDMA operation?
Could you please give me some suggestions?
Thank you very much,
Andrea
Example of structure code:
Ibv_recv_wr rrq(mr), *bad_rrq;
assert(!conn-post_recv(rrq, bad_rrq, 0));
assert(!conn-get_completion(compl_queue));
//printf(ok %p %s
, compl_queue, strerror(errno));
assert(1 == compl_queue-poll(1, wc));
//printf(status %i
, (int)wc.status);
if (wc.status !=0){
printf(RDMA server closes.
);
break;
}
-
Ibv_send_wr srq((void *)rpd-address, rpd-rkey), *bad_srq;
srq.add_sge(mr);
assert(!conn.post_send(srq, bad_srq, 0));
assert(!conn.get_completion(compl_queue));
assert(1 == compl_queue-poll(1, wc));
//printf(ok %p %s status %i
, compl_queue, strerror(errno), wc.status);
//printf(loop %i
, i);
if (wc.status != 0){
//printf(KO %p %s status %i
, compl_queue, strerror(errno), wc.status);
printf(RDMA data sending problem in loop %i.
, i);
break;
}
---
Andrea Gozzelino
INFN - Laboratori Nazionali di Legnaro (LNL)
Viale dell'Universita' 2 -I-35020 - Legnaro (PD)- ITALIA
Office: E-101
Tel: +39 049 8068346
Fax: +39 049 641925
Mail: andrea.gozzel...@lnl.infn.it
Cell: +39 3488245552
--
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 synchronous operations
Hi all,
I’m testing the latency time of an RDMA system (2 card and 1 switch).
The connection server/client is established and the code is just as
mirror on both sides.
The RDMA action scheme is below:
1- client sends a buffer;
2- server receives a buffer;
3- server sends a buffer;
4- client receives a buffer.
The scheme is in a for loop, so after step 4 client repeats step 1.
On client side I put a clock: t_start is before loop and t_end is after
loop.
I consider the round trip time RTT as (t_end-t_start)/NTX where NTX is
number of transfer (number of loop). The latency time is half RTT, if
transfer time is negligible, i.e. for small (8 Bytes – 4 Kbytes) buffer
size and high NTX value ( 1) is true.
The RDMA communication stops casually with error status 5. It means that
the send or receive operation on one side (server or client) casually is
not in time. I summarize post_send and post_receive operation are
quasi-synchronous. I would like that RDMA operation are completely
synchronous. I use the completion queue and the acknowledgement event.
Do you see the same character in other RDMA use? How can I synchronize
all RDMA operation?
Could you please give me some suggestions?
Thank you very much,
Andrea
Example of structure code:
Ibv_recv_wr rrq(mr), *bad_rrq;
assert(!conn-post_recv(rrq, bad_rrq, 0));
assert(!conn-get_completion(compl_queue));
//printf(ok %p %s\n, compl_queue, strerror(errno));
assert(1 == compl_queue-poll(1, wc));
//printf(status %i\n, (int)wc.status);
if (wc.status !=0){
printf(RDMA server closes. \n);
break;
--
Ibv_send_wr srq((void *)rpd-address, rpd-rkey), *bad_srq;
srq.add_sge(mr);
assert(!conn.post_send(srq, bad_srq, 0));
assert(!conn.get_completion(compl_queue));
assert(1 == compl_queue-poll(1, wc));
//printf(ok %p %s status %i\n, compl_queue, strerror(errno),
wc.status);
//printf(loop %i\n, i);
if (wc.status != 0){
//printf(KO %p %s status %i\n, compl_queue,
strerror(errno),
wc.status);
printf(RDMA data sending problem in loop %i.\n, i);
break;
}
-
Andrea Gozzelino
INFN - Laboratori Nazionali di Legnaro (LNL)
Viale dell'Universita' 2 -I-35020 - Legnaro (PD)- ITALIA
Office: E-101
Tel: +39 049 8068346
Fax: +39 049 641925
Mail: andrea.gozzel...@lnl.infn.it
Cell: +39 3488245552
--
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: When IBoE will be merged to upstream?
Regarding GID to Eth mappings, we discussed using the standard create_ah() Verb for this. In the kernel, create_ah() will call a generic address resolution function in the cma. The returned information will be copied back to user-space in a device-specific structure (since address handles are device-specific). This eliminates adding a new get_eth_l2_addr() ABI call (device-specific or not). In fact, this approach eliminates adding new ABIs for any kind of address translation... Does this seem reasonable? --Liran -Original Message- From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Roland Dreier Sent: Thursday, June 24, 2010 2:24 AM To: Aleksey Senin Cc: linux-rdma; mo...@voltaire.com; aleks...@voltaire.com; yift...@voltaire.com; Tziporet Koren; al...@voltaire.com Subject: Re: When IBoE will be merged to upstream? This is actually a continue of the RAW_ET() issue. We want to make a submition of the patches to the upstream, but there is not support for IB transport in Ethernet devices, and the mlx4_en drivers version is a bit outdated 1.4.1.1 in upstream and 1.5.1 in the OFED There is also missing VLAN support that already present in the OFED. When do you planning to submit changes from OFED to upstream? - I do not search for more things to merge upstream. I have enough work reviewing things that are sent to me. So I will never look through OFED for changes. - I do not handle the mlx4_en driver. Changes for mlx4_en should go to netdev and Dave Miller. - I will try to get back to the IBoE changes when I have time, and I will admit that my time to spend as RDMA maintainer is nowhere near full time and less than it was in the past. - I did allocate a fair amount of time to spend on IBoE recently but unfortunately the patches were not really in a suitable state to merge, and I exhausted that time slice before we reached the end. When patch sets sit outside of the upstream kernel and are shipped in OFED for months and years, it would probably make upstream merging easier if that time was used to fix the patch set. - Specifically for the IBoE patches, shouldn't someone have realized that having a device-specific interface to do the standard mapping of GID to Ethernet address makes no sense? -- Roland Dreier rola...@cisco.com || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.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 -- 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
Fwd: [ewg] Updates to OFA Web site
Resending Hi all. In conjunction with the update below, we will slowly begin migrating to sofa.openfabrics.org as our server (finally 8^)). I have already set up gitweb, so sofa.openfabrics.org/gitweb shows all the git trees on sofa. It might be a good idea to start migrating your trees over there. Also, Vlad, perhaps we should start doing the nightly builds there. In addition, I have set up mediawiki (sofa.openfabrics.org/mediawiki) so if you want to add wiki content (there's nothing there yet), go ahead, but please coordinate with Cheri at Owen Media, as their team is looking at moving our old wiki content over. In particular, tell them about out-of-date content we don't want moved. Thanks, and let me know if you have any questions/issues. -jeff Original Message Subject:[ewg] Updates to OFA Web site Date: Wed, 23 Jun 2010 20:52:17 -0500 From: Cheri Winterberg che...@owenmedia.com To: e...@lists.openfabrics.org e...@lists.openfabrics.org EWG – the OFA is in the early stages of updating several elements of the OFA Web site. We'll be looking at the look feel, organization and content of the site. We're also considering adding a members-only area with password-protected pages. We'd like input from the technical working groups on the following: · What are the features of the current OFA Web site that you are using and would like to see remain relatively unchanged? · What are we missing on the current OFA Web site that you would like to see added? I'm with the marketing agency working on the site. If you have any input or feedback on potential changes, please e-mail me directly. Thanks! Cheri Cheri Winterberg │ Owen Media, Inc. │ 978.660.6405 │ che...@owenmedia.com -- 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: When IBoE will be merged to upstream?
S.B. --Liran -Original Message- From: Hefty, Sean [mailto:sean.he...@intel.com] Sent: Thursday, June 24, 2010 9:06 PM To: Liran Liss; Roland Dreier; Aleksey Senin Cc: linux-rdma; mo...@voltaire.com; aleks...@voltaire.com; yift...@voltaire.com; Tziporet Koren; al...@voltaire.com Subject: RE: When IBoE will be merged to upstream? Regarding GID to Eth mappings, we discussed using the standard create_ah() Verb for this. In the kernel, create_ah() will call a generic address resolution function in the cma. The returned information will be copied back to user-space in a device- specific structure (since address handles are device-specific). This eliminates adding a new get_eth_l2_addr() ABI call (device-specific or not). In fact, this approach eliminates adding new ABIs for any kind of address translation... Does this seem reasonable? The current behavior of ibv_create_ah() requires that the caller provide the L2, and if needed, L3 addressing. Any translation between the L3 and L2 addressing must be done before the call is made. E.g. ibv_create_ah does not use the GID to query the SA to obtain LIDs. Why doesn't IBoE follow this same model? LL: because of the RoCE spec, which states that only GID addressing is used at the Verbs level. The address handle fields are unchanged, and the L2 fields (e.g., lid) are reserved. Note that in Ethernet, you normally don't specify L2 addresses at the transport level (i.e., sockets). Callers can use some out of band mechanism for the mapping, call rdma_resolve_addr, or use some standard networking routine. LL: this would require changes to the Verbs API. rdmacm programs addresses using user-space Verbs, or even just passes the application just address handle attributes... -- 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: [ewg] [PATCH v4] IB Core: RAW ETH support
Thanks. I accept this remark. We will try to address all the bothering issues regarding the patch set of RAW QP support and resubmit them linux-rdma. Since it won't work with Mellanox the patches will be only for Intel (nes) driver. When time comes and Mellanox cards can be tested for RAQ QO feature they will benefit from the common part. --- Moni Shoua| +972-54-5567934 -Original Message- From: Roland Dreier [mailto:rdre...@cisco.com] Sent: Wednesday, June 23, 2010 8:32 PM To: Moni Shoua Cc: Aleksey Senin; Eli Cohen; e...@openfabrics.org; linux-rdma@vger.kernel.org; Tziporet Koren; Yiftah Shahar Subject: Re: [ewg] [PATCH v4] IB Core: RAW ETH support There is no qp type IBV_QPT_RAW_ETY in user space (at least not in the definitions coming with libibverbs). In fact, libibverbs that comes with OFED defines (in verbs.h) a qp type called IBV_QPT_RAW_ETT which equals to 7. The patch that is under discussion here adds a new qp type IB_QPT_RAW_ETH and equals it to 7 to match the definition in user space. This indeed changes the value of IB_QPT_RAW_ETY to 8 but I don't see who can be affected since 1. No user space program that uses IB_QPT_RAW_ETY exists 2. kernel is compiled as one piece of code. Why renumber the _ETY enum? Maybe it doesn't break anything serious but why risk it? -- Roland Dreier rola...@cisco.com || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- 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
