Re: [ewg] [PATCH v4] IB Core: RAW ETH support
Thanks. I accept this remark. We will try to address all the bothering issues regarding the patch set of RAW QP support and resubmit them linux-rdma. Since it won't work with Mellanox the patches will be only for Intel (nes) driver. When time comes and Mellanox cards can be tested for RAQ QO feature they will benefit from the common part. --- Moni Shoua| +972-54-5567934 -Original Message- From: Roland Dreier [mailto:rdre...@cisco.com] Sent: Wednesday, June 23, 2010 8:32 PM To: Moni Shoua Cc: Aleksey Senin; Eli Cohen; e...@openfabrics.org; linux-r...@vger.kernel.org; Tziporet Koren; Yiftah Shahar Subject: Re: [ewg] [PATCH v4] IB Core: RAW ETH support There is no qp type IBV_QPT_RAW_ETY in user space (at least not in the definitions coming with libibverbs). In fact, libibverbs that comes with OFED defines (in verbs.h) a qp type called IBV_QPT_RAW_ETT which equals to 7. The patch that is under discussion here adds a new qp type IB_QPT_RAW_ETH and equals it to 7 to match the definition in user space. This indeed changes the value of IB_QPT_RAW_ETY to 8 but I don't see who can be affected since 1. No user space program that uses IB_QPT_RAW_ETY exists 2. kernel is compiled as one piece of code. Why renumber the _ETY enum? Maybe it doesn't break anything serious but why risk it? -- Roland Dreier rola...@cisco.com || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
There is no qp type IBV_QPT_RAW_ETY in user space (at least not in the definitions coming with libibverbs). In fact, libibverbs that comes with OFED defines (in verbs.h) a qp type called IBV_QPT_RAW_ETT which equals to 7. The patch that is under discussion here adds a new qp type IB_QPT_RAW_ETH and equals it to 7 to match the definition in user space. This indeed changes the value of IB_QPT_RAW_ETY to 8 but I don't see who can be affected since 1. No user space program that uses IB_QPT_RAW_ETY exists 2. kernel is compiled as one piece of code. Why renumber the _ETY enum? Maybe it doesn't break anything serious but why risk it? -- Roland Dreier rola...@cisco.com || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
On 06/16/2010 02:35 PM, Steve Wise wrote: Jason Gunthorpe wrote: On Wed, Jun 16, 2010 at 12:12:06PM -0500, Steve Wise wrote: Granted our dev process may not be documented, but I always assumed the general idea was to get changes accepted upstream, then pull into ofed. OFED is just a mechanism to make top-of-tree linux work on distro kernels. There are some exceptions, but this stuff shouldn't be an exception. That is what many people wish for, me included, but it is not at all what generally happens :( In my observation the typical flow is: - A patch is written, it may or may not be sent to the list - 'business drivers' get it slammed into OFED right away - A patch is finally sent for proper review - It is not merged, there are comments.. - Interest in doing anything is lost because it is already in OFED and that is all that matters, right? - People complain. For instance, the iWarp thingy we were just discussing fits this process rather well. You're wrong. I started that iWARP change in 2007 on LKLM. I proposed a few ideas and show the pros/cons of each. And it was NAKed 100% by mister miller.It was then included in OFED as a last resort only because I couldn't get any help with trying to add this upstream in any form. I even spent a few weeks developing a way to administor iwarp only ipaddresses, but Roland didn't like that scheme for various reasons. So please don't mention that particular patch as a bad process unless you want to argue with me some more about it. Uhm, what you just described does fit my process outline: #1 - Patch written, sent to LKML. Check. #3 - Patch sent for proper review - in 2007. Check. #4 - Not merged. NAK by DM. Check. #2 - 'business drivers' force it into OFED - 'last resort' ie, iWarp cards can't be used without some fix. Check. #5 - Interest is lost. Yep, this was done in 2007, and it was idle till now. Check. #6 - People Complain. Hmm. Yep. Check. Note the ordering is different. IE I tried very hard to get the right solution designed and agreed-upon upstream. But failed. That's my bad.I did, however help with the iWARP core code including neighbour update net events which did go in upstream before ofed. Don't think I'm being critical toward only you, or singling out that little iWarp patch. But it really isn't special, or different, or an exception. Pick nearly any patch in OFED and someone will rush to its defense with a 'we tried to follow the process and it failed, so we did it anyway' argument. I also didn't say this is the only way that RDMA development goes, lots and lots of stuff goes into mainline first, from everyone. Jason OFED maintainers should be more rigid, perhaps, with requiring that changes be accepted upstream first. One observation is that there is no OFED RDMA maintainer, aka a Roland Dreier, for the OFED code. So each driver maintainer pretty much has free reign to do the right thing or the wrong thing... Yep, no doubt that has an impact on things. It's for this very reason that our next operating system is not following OFED but instead is using upstream as its basis. That will be true from now on with our products. -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: OpenPGP digital signature ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
On 06/16/2010 01:12 PM, Steve Wise wrote: Jason Gunthorpe wrote: On Wed, Jun 16, 2010 at 09:09:59AM -0500, Steve Wise wrote: Granted our dev process may not be documented, but I always assumed the general idea was to get changes accepted upstream, then pull into ofed. OFED is just a mechanism to make top-of-tree linux work on distro kernels. There are some exceptions, but this stuff shouldn't be an exception. That is what many people wish for, me included, but it is not at all what generally happens :( In my observation the typical flow is: - A patch is written, it may or may not be sent to the list - 'business drivers' get it slammed into OFED right away - A patch is finally sent for proper review - It is not merged, there are comments.. - Interest in doing anything is lost because it is already in OFED and that is all that matters, right? - People complain. For instance, the iWarp thingy we were just discussing fits this process rather well. You're wrong. I started that iWARP change in 2007 on LKLM. I proposed a few ideas and show the pros/cons of each. And it was NAKed 100% by mister miller.It was then included in OFED as a last resort only ^ Which, of course, is the problem. Once you have a solution besides get it upstream, you throw whatever you feel like into OFED instead of whatever upstream will accept. How long has OFED shipped the XRC stuff now while it *still* isn't upstream? because I couldn't get any help with trying to add this upstream in any form. Again, OFED is part of the reason this failed. That users had someplace else to get working code besides upstream meant that you didn't have end users putting pressure on the upstream kernel folks to accept *some* form of solution. So, your job was harder because there were no users present to put pressure on mister miller or others, and then you perpetuated the issue by caving and going back to OFED as a last resort. It has become a last resort so often now that trying to get things upstream first is just a sort of private joke amongst some people I think. I even spent a few weeks developing a way to administor iwarp only ipaddresses, but Roland didn't like that scheme for various reasons. So please don't mention that particular patch as a bad process unless you want to argue with me some more about it. Also, the chelsio iWARP driver has 100% been upstream first, then ofed. Some of us are indeed trying to do the right thing. steps off soap box OFED just needs to go away. It's been far too abused for far too long and it's mere existence is hindering upstream development. I appreciate that you attempt to do the right thing most of the time, but it really needs to be all of the time, and you need your users right there beside you in order to carry the weight you need in order to get solutions designed and accepted instead of running into the brick wall you ran into before. -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: OpenPGP digital signature ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
It doesn't even look like this patch and the mlx4 patch were ever posted to linux-rdma. Only to the EWG list. Not 100% correct. See thread from April 30. Patches to core, libibverbs and NES driver were presented there. Granted our dev process may not be documented, but I always assumed the general idea was to get changes accepted upstream, then pull into ofed. OFED is just a mechanism to make top-of-tree linux work on distro kernels. There are some exceptions, but this stuff shouldn't be an exception. We should all follow this upstream first process IMO. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
On Wed, Jun 16, 2010 at 09:09:59AM -0500, Steve Wise wrote: Granted our dev process may not be documented, but I always assumed the general idea was to get changes accepted upstream, then pull into ofed. OFED is just a mechanism to make top-of-tree linux work on distro kernels. There are some exceptions, but this stuff shouldn't be an exception. That is what many people wish for, me included, but it is not at all what generally happens :( In my observation the typical flow is: - A patch is written, it may or may not be sent to the list - 'business drivers' get it slammed into OFED right away - A patch is finally sent for proper review - It is not merged, there are comments.. - Interest in doing anything is lost because it is already in OFED and that is all that matters, right? - People complain. For instance, the iWarp thingy we were just discussing fits this process rather well. Jason ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
Jason Gunthorpe wrote: On Wed, Jun 16, 2010 at 09:09:59AM -0500, Steve Wise wrote: Granted our dev process may not be documented, but I always assumed the general idea was to get changes accepted upstream, then pull into ofed. OFED is just a mechanism to make top-of-tree linux work on distro kernels. There are some exceptions, but this stuff shouldn't be an exception. That is what many people wish for, me included, but it is not at all what generally happens :( In my observation the typical flow is: - A patch is written, it may or may not be sent to the list - 'business drivers' get it slammed into OFED right away - A patch is finally sent for proper review - It is not merged, there are comments.. - Interest in doing anything is lost because it is already in OFED and that is all that matters, right? - People complain. For instance, the iWarp thingy we were just discussing fits this process rather well. You're wrong. I started that iWARP change in 2007 on LKLM. I proposed a few ideas and show the pros/cons of each. And it was NAKed 100% by mister miller.It was then included in OFED as a last resort only because I couldn't get any help with trying to add this upstream in any form. I even spent a few weeks developing a way to administor iwarp only ipaddresses, but Roland didn't like that scheme for various reasons. So please don't mention that particular patch as a bad process unless you want to argue with me some more about it. Also, the chelsio iWARP driver has 100% been upstream first, then ofed. Some of us are indeed trying to do the right thing. steps off soap box ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
On Wed, Jun 16, 2010 at 12:12:06PM -0500, Steve Wise wrote: Granted our dev process may not be documented, but I always assumed the general idea was to get changes accepted upstream, then pull into ofed. OFED is just a mechanism to make top-of-tree linux work on distro kernels. There are some exceptions, but this stuff shouldn't be an exception. That is what many people wish for, me included, but it is not at all what generally happens :( In my observation the typical flow is: - A patch is written, it may or may not be sent to the list - 'business drivers' get it slammed into OFED right away - A patch is finally sent for proper review - It is not merged, there are comments.. - Interest in doing anything is lost because it is already in OFED and that is all that matters, right? - People complain. For instance, the iWarp thingy we were just discussing fits this process rather well. You're wrong. I started that iWARP change in 2007 on LKLM. I proposed a few ideas and show the pros/cons of each. And it was NAKed 100% by mister miller.It was then included in OFED as a last resort only because I couldn't get any help with trying to add this upstream in any form. I even spent a few weeks developing a way to administor iwarp only ipaddresses, but Roland didn't like that scheme for various reasons. So please don't mention that particular patch as a bad process unless you want to argue with me some more about it. Uhm, what you just described does fit my process outline: #1 - Patch written, sent to LKML. Check. #3 - Patch sent for proper review - in 2007. Check. #4 - Not merged. NAK by DM. Check. #2 - 'business drivers' force it into OFED - 'last resort' ie, iWarp cards can't be used without some fix. Check. #5 - Interest is lost. Yep, this was done in 2007, and it was idle till now. Check. #6 - People Complain. Hmm. Yep. Check. Don't think I'm being critical toward only you, or singling out that little iWarp patch. But it really isn't special, or different, or an exception. Pick nearly any patch in OFED and someone will rush to its defense with a 'we tried to follow the process and it failed, so we did it anyway' argument. I also didn't say this is the only way that RDMA development goes, lots and lots of stuff goes into mainline first, from everyone. Jason ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
Jason Gunthorpe wrote: On Wed, Jun 16, 2010 at 12:12:06PM -0500, Steve Wise wrote: Granted our dev process may not be documented, but I always assumed the general idea was to get changes accepted upstream, then pull into ofed. OFED is just a mechanism to make top-of-tree linux work on distro kernels. There are some exceptions, but this stuff shouldn't be an exception. That is what many people wish for, me included, but it is not at all what generally happens :( In my observation the typical flow is: - A patch is written, it may or may not be sent to the list - 'business drivers' get it slammed into OFED right away - A patch is finally sent for proper review - It is not merged, there are comments.. - Interest in doing anything is lost because it is already in OFED and that is all that matters, right? - People complain. For instance, the iWarp thingy we were just discussing fits this process rather well. You're wrong. I started that iWARP change in 2007 on LKLM. I proposed a few ideas and show the pros/cons of each. And it was NAKed 100% by mister miller.It was then included in OFED as a last resort only because I couldn't get any help with trying to add this upstream in any form. I even spent a few weeks developing a way to administor iwarp only ipaddresses, but Roland didn't like that scheme for various reasons. So please don't mention that particular patch as a bad process unless you want to argue with me some more about it. Uhm, what you just described does fit my process outline: #1 - Patch written, sent to LKML. Check. #3 - Patch sent for proper review - in 2007. Check. #4 - Not merged. NAK by DM. Check. #2 - 'business drivers' force it into OFED - 'last resort' ie, iWarp cards can't be used without some fix. Check. #5 - Interest is lost. Yep, this was done in 2007, and it was idle till now. Check. #6 - People Complain. Hmm. Yep. Check. Note the ordering is different. IE I tried very hard to get the right solution designed and agreed-upon upstream. But failed. That's my bad.I did, however help with the iWARP core code including neighbour update net events which did go in upstream before ofed. Don't think I'm being critical toward only you, or singling out that little iWarp patch. But it really isn't special, or different, or an exception. Pick nearly any patch in OFED and someone will rush to its defense with a 'we tried to follow the process and it failed, so we did it anyway' argument. I also didn't say this is the only way that RDMA development goes, lots and lots of stuff goes into mainline first, from everyone. Jason OFED maintainers should be more rigid, perhaps, with requiring that changes be accepted upstream first. One observation is that there is no OFED RDMA maintainer, aka a Roland Dreier, for the OFED code. So each driver maintainer pretty much has free reign to do the right thing or the wrong thing... Steve. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
I tested it before on the Roland tree ( iboe branch ) and it fails, because it writen in the way suitable for OFED. If adapt the patch to the Roland tree, then appling Mellanox OFED patches will fail, because it changes the same functions in the code. Here is one example: Look at __mlx4_ib_modify_qp at the Roland tree - there is no RAW_ETY support. But in the OFED version of the same function this support is present. RAW_ETH patch modify this function and looking for RAW_ETY word and without this RAW_ETH Mellanox patch will fail. Don't take this too personally -- I picked a semi-random email in this thread to reply to; this is pretty broadly targeted. rant What the hell is the thinking behind introducing IB_QPT_RAW_ETH? You're inserting an enum value before IB_QPT_RAW_ETY, so any old userspace passing in IB_QPT_RAW_ETY will silently get different behavior depending on the kernel version. And you're creating two constands that differ in a single letter (IB_QPT_RAW_ETY vs. IB_QPT_RAW_ETH). How are you going to explain that to users? How is anyone ever going to get it right? For that matter, what exactly does IB_QPT_RAW_ETH mean? This all seems to be a symptom of how broken our development process is. Yes, unfortunately I can't spend as much time reviewing and applying patches as I might like, and I apologize for that. But if we have all the RDMA developers piling up shit in their little area and then sending it on to be merged as soon as it kind of works, without thinking about design or maintainability and without ever doing any review, then I'm always going to have an expanding review backlog. And then we have OFED compounding problems -- Oh that's a nice pile of shit you've built there. We better ship it to users while it's still steaming. How about if OFED developers take a little time to think things through? /rant In other words, can someone explain the plan for this raw QP stuff to me? - R. -- Roland Dreier rola...@cisco.com || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH v4] IB Core: RAW ETH support
This patch adds support to RAW ETH QP in ib core.
diff --git a/kernel_patches/fixes/core_0560_raw_eth_common.patch
b/kernel_patches/fixes/core_0560_raw_eth_common.patch
new file mode 100644
index 000..ae43298
--- /dev/null
+++ b/kernel_patches/fixes/core_0560_raw_eth_common.patch
@@ -0,0 +1,63 @@
+ Add new RAW_ETH QP type in order to build RAW Ethernet packets
+ over iWARP and RoCEE.
+
+
+Signed-off-by: Aleksey Senin aleks...@voltaire.com
+---
+ drivers/infiniband/core/verbs.c | 13 +++--
+ include/rdma/ib_verbs.h |1 +
+ 2 files changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
+index 881850e..bb4dcd5 100644
+--- a/drivers/infiniband/core/verbs.c
b/drivers/infiniband/core/verbs.c
+@@ -382,6 +382,7 @@ static const struct {
+ [IB_QPT_UD] = (IB_QP_PKEY_INDEX
|
+ IB_QP_PORT
|
+ IB_QP_QKEY),
++ [IB_QPT_RAW_ETH] = IB_QP_PORT,
+ [IB_QPT_UC] = (IB_QP_PKEY_INDEX
|
+ IB_QP_PORT
|
+ IB_QP_ACCESS_FLAGS),
+@@ -1004,7 +1005,11 @@ int ib_attach_mcast(struct ib_qp *qp, union ib_gid
*gid, u16 lid)
+
+ switch (rdma_node_get_transport(qp-device-node_type)) {
+ case RDMA_TRANSPORT_IB:
+- if (gid-raw[0] != 0xff || qp-qp_type != IB_QPT_UD)
++ if (qp-qp_type == IB_QPT_RAW_ETH) {
++ /* In raw Etherent mgids the 63 msb's should be 0 */
++ if (gid-global.subnet_prefix cpu_to_be64(~1ULL))
++ return -EINVAL;
++ } else if (gid-raw[0] != 0xff || qp-qp_type != IB_QPT_UD)
+ return -EINVAL;
+ break;
+ case RDMA_TRANSPORT_IWARP:
+@@ -1023,7 +1028,11 @@ int ib_detach_mcast(struct ib_qp *qp, union ib_gid
*gid, u16 lid)
+
+ switch (rdma_node_get_transport(qp-device-node_type)) {
+ case RDMA_TRANSPORT_IB:
+- if (gid-raw[0] != 0xff || qp-qp_type != IB_QPT_UD)
++ if (qp-qp_type == IB_QPT_RAW_ETH) {
++ /* In raw Etherent mgids the 63 msb's should be 0 */
++ if (gid-global.subnet_prefix cpu_to_be64(~1ULL))
++ return -EINVAL;
++ } else if (gid-raw[0] != 0xff || qp-qp_type != IB_QPT_UD)
+ return -EINVAL;
+ break;
+ case RDMA_TRANSPORT_IWARP:
+diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
+index 3a5a40f..2162253 100644
+--- a/include/rdma/ib_verbs.h
b/include/rdma/ib_verbs.h
+@@ -571,6 +571,7 @@ enum ib_qp_type {
+ IB_QPT_UD,
+ IB_QPT_XRC,
+ IB_QPT_RAW_IPV6,
++ IB_QPT_RAW_ETH,
+ IB_QPT_RAW_ETY
+ };
+
+--
+1.6.5.2
+
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
Vlad,
please push to OFED.
On Mon, Jun 14, 2010 at 11:48 AM, Alekseys Senin aleks...@voltaire.com wrote:
This patch adds support to RAW ETH QP in ib core.
diff --git a/kernel_patches/fixes/core_0560_raw_eth_common.patch
b/kernel_patches/fixes/core_0560_raw_eth_common.patch
new file mode 100644
index 000..ae43298
--- /dev/null
+++ b/kernel_patches/fixes/core_0560_raw_eth_common.patch
@@ -0,0 +1,63 @@
+ Add new RAW_ETH QP type in order to build RAW Ethernet packets
+ over iWARP and RoCEE.
+
+
+Signed-off-by: Aleksey Senin aleks...@voltaire.com
+---
+ drivers/infiniband/core/verbs.c | 13 +++--
+ include/rdma/ib_verbs.h | 1 +
+ 2 files changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/infiniband/core/verbs.c
b/drivers/infiniband/core/verbs.c
+index 881850e..bb4dcd5 100644
+--- a/drivers/infiniband/core/verbs.c
b/drivers/infiniband/core/verbs.c
+@@ -382,6 +382,7 @@ static const struct {
+ [IB_QPT_UD] = (IB_QP_PKEY_INDEX
|
+ IB_QP_PORT
|
+ IB_QP_QKEY),
++ [IB_QPT_RAW_ETH] = IB_QP_PORT,
+ [IB_QPT_UC] = (IB_QP_PKEY_INDEX
|
+ IB_QP_PORT
|
+ IB_QP_ACCESS_FLAGS),
+@@ -1004,7 +1005,11 @@ int ib_attach_mcast(struct ib_qp *qp, union ib_gid
*gid, u16 lid)
+
+ switch (rdma_node_get_transport(qp-device-node_type)) {
+ case RDMA_TRANSPORT_IB:
+- if (gid-raw[0] != 0xff || qp-qp_type != IB_QPT_UD)
++ if (qp-qp_type == IB_QPT_RAW_ETH) {
++ /* In raw Etherent mgids the 63 msb's should be 0 */
++ if (gid-global.subnet_prefix cpu_to_be64(~1ULL))
++ return -EINVAL;
++ } else if (gid-raw[0] != 0xff || qp-qp_type != IB_QPT_UD)
+ return -EINVAL;
+ break;
+ case RDMA_TRANSPORT_IWARP:
+@@ -1023,7 +1028,11 @@ int ib_detach_mcast(struct ib_qp *qp, union ib_gid
*gid, u16 lid)
+
+ switch (rdma_node_get_transport(qp-device-node_type)) {
+ case RDMA_TRANSPORT_IB:
+- if (gid-raw[0] != 0xff || qp-qp_type != IB_QPT_UD)
++ if (qp-qp_type == IB_QPT_RAW_ETH) {
++ /* In raw Etherent mgids the 63 msb's should be 0 */
++ if (gid-global.subnet_prefix cpu_to_be64(~1ULL))
++ return -EINVAL;
++ } else if (gid-raw[0] != 0xff || qp-qp_type != IB_QPT_UD)
+ return -EINVAL;
+ break;
+ case RDMA_TRANSPORT_IWARP:
+diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
+index 3a5a40f..2162253 100644
+--- a/include/rdma/ib_verbs.h
b/include/rdma/ib_verbs.h
+@@ -571,6 +571,7 @@ enum ib_qp_type {
+ IB_QPT_UD,
+ IB_QPT_XRC,
+ IB_QPT_RAW_IPV6,
++ IB_QPT_RAW_ETH,
+ IB_QPT_RAW_ETY
+ };
+
+--
+1.6.5.2
+
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
Alekseys Senin wrote: This patch adds support to RAW ETH QP in ib core. are these patches applicable to the mainstream kernel code or would only apply/function over ofed? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
The patches can't be applies to upstream kernel. An attempt to do this failed about a week or 2 ago. I guess that some of RoCEE patches are still missing in kernel upstream. -Original Message- From: Or Gerlitz Sent: Monday, June 14, 2010 12:15 PM To: Aleksey Senin Cc: Vladimir Sokolovsky; v...@dev.mellanox.co.il; e...@openfabrics.org; e...@mellanox.co.il; Moni Shoua Subject: Re: [ewg] [PATCH v4] IB Core: RAW ETH support Alekseys Senin wrote: This patch adds support to RAW ETH QP in ib core. are these patches applicable to the mainstream kernel code or would only apply/function over ofed? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
Moni Shoua wrote: The patches can't be applies to upstream kernel. An attempt to do this failed. I guess that some of RoCEE patches are still missing in kernel upstream. Eli, can you elaborate on that? is there any real dependence between the RoCE patches to the raw qp ones? what is this dependence in high level, is it placement of change sets in the code or actual flows? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
I don't think there is a substantial dependence between RoCEE and raw ethernet. I don't know what Moni meant. Moni? -Original Message- From: Or Gerlitz [mailto:ogerl...@voltaire.com] Sent: Monday, June 14, 2010 1:42 PM To: Moni Shoua; Eli Cohen Cc: Aleksey Senin; Vladimir Sokolovsky; v...@dev.mellanox.co.il; e...@openfabrics.org Subject: Re: [ewg] [PATCH v4] IB Core: RAW ETH support Moni Shoua wrote: The patches can't be applies to upstream kernel. An attempt to do this failed. I guess that some of RoCEE patches are still missing in kernel upstream. Eli, can you elaborate on that? is there any real dependence between the RoCE patches to the raw qp ones? what is this dependence in high level, is it placement of change sets in the code or actual flows? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v4] IB Core: RAW ETH support
I tested it before on the Roland tree ( iboe branch ) and it fails, because it writen in the way suitable for OFED. If adapt the patch to the Roland tree, then appling Mellanox OFED patches will fail, because it changes the same functions in the code. Here is one example: Look at __mlx4_ib_modify_qp at the Roland tree - there is no RAW_ETY support. But in the OFED version of the same function this support is present. RAW_ETH patch modify this function and looking for RAW_ETY word and without this RAW_ETH Mellanox patch will fail. The similar thing happens with patch for the verbs. There is no iWARP present in the Roland tree. On Mon, 2010-06-14 at 13:50 +0300, Eli Cohen wrote: I don't think there is a substantial dependence between RoCEE and raw ethernet. I don't know what Moni meant. Moni? -Original Message- From: Or Gerlitz [mailto:ogerl...@voltaire.com] Sent: Monday, June 14, 2010 1:42 PM To: Moni Shoua; Eli Cohen Cc: Aleksey Senin; Vladimir Sokolovsky; v...@dev.mellanox.co.il; e...@openfabrics.org Subject: Re: [ewg] [PATCH v4] IB Core: RAW ETH support Moni Shoua wrote: The patches can't be applies to upstream kernel. An attempt to do this failed. I guess that some of RoCEE patches are still missing in kernel upstream. Eli, can you elaborate on that? is there any real dependence between the RoCE patches to the raw qp ones? what is this dependence in high level, is it placement of change sets in the code or actual flows? Or. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
