[PATCH] RXE: A Soft RoCE back-end for the RVT

This patch introduces an implementation of a back-end that works with RVT to make RoCE Verbs transport over any Ethernet network device. Example: After loading ib_rxe_net.ko echo eth1 > /sys/module/ib_rxe_net/parameters/add will create rvt0 IB device in RVT with Ethernet link layer ---

Re: [PATCH for-next 5/7] IB/mlx4: Enable send of RoCE QP1 packets with IP/UDP headers

> > The last hunk that you removed had a role and was by no means > dead-code, right? so... (1) why it's correct to remove it? (2) if you > want to introduce different way to implement what was done here, why > in this patch? maybe add pre-patch for that In a way you are right. This hunk does not

Re: [RFC] Generic InfiniBand transport done in software

I think that my point is missed. See my answers inline > This is incorrect. This isn't some public API that we are exporting to > user space. Nor is it an API that out of tree drivers are using. This > is a purely kernel internal API for use by a limited number of drivers. > As such, it need

Re: [RFC] Generic InfiniBand transport done in software

> it's never going to fit any possible future driver. Dennis and folks > have done great work to move code outside the drivers into a shared > library. So far it's been driven just by the Intel drivers as that's > the only thing they were interested in. > If it's not going to be a solution for

Re: [PATCH v2 00/36] Add rdma verbs transport library

> Changes since v1: > Removed driver specific version > Fixed license text to remove copyright and put on top > Return 0 in rvt_map_sg instead of BAD_DMA_AGGRESS > Remove #include of dma.h from dma.c > Update comment about protection domain limit > Remove comment on alternative design for private

Re: [RFC] Generic InfiniBand transport done in software

> No. PIO and SDMA is driver specific and lives in the driver. Rdmavt has no > concept of this. I'm agreeing that the send will be generic and have no hw > specific stuff. > I understand that PIO/SDMA are not a concept of RVT. However, making the send from RVT to driver exactly as the interface

Re: [RFC] Generic InfiniBand transport done in software

> > Point is others have looked at the code. No issues have been called out to > date as to why what is there won't work for everyone. > http://marc.info/?l=linux-rdma=144968107508268=2 Your answer to the send() issue is first an agreement with the comment and later says that it can't be done

Re: [RFC] Generic InfiniBand transport done in software

> > > There were discussions, and Mellanox even contributed code to the effort. > See Kamal's patches in the patch set I provided. > As far as I see it discussions were shallow and never produced an agreement. Kamal's patches should not be considered as as such. >>

Re: [RFC] Generic InfiniBand transport done in software

> I'm not sure I understand what you mean. Denny has posted several high level > emails similar to this one and has asked for public feedback. We have been > addressing all the feedback as it has come in and we continue to work toward > this common layer. > > To that end we have been asking for

Re: [RFC] Generic InfiniBand transport done in software

> > > This makes no mention of the already posted work which aims to consolidate > the qib and hfi1 drivers verbs implementation. However it does seem to be > mostly in line with what we have already presented for rdmavt and the > direction the next set of patches is going in. Have you seen

[RFC] Generic InfiniBand transport done in software

Hi, In the past months the need for a kernel module that implements the InfiniBand transport in software and unify all the InfiniBand software drivers has been raised. Since then, nobody has submitted any design proposal that satisfy the initial thoughts and can serve various back-ends. The

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

> No, not true. You are implementing RoCEv2 support, which is an entirely > new feature. So this feature can't have had a security hole since > forever as it has never been in the kernel before now. The objections > are arising because of the ordering of events. Specifically, we added > the

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

> The part that bothers me about this is that this statement makes sense > when just thinking about the spec, as you say. However, once you > consider namespaces, security implications make this statement spec > compliant, but still unacceptable. The spec itself is silent on > namespaces. But,

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

ibute > IB/cm: Use the source GID index type > IB/core: Add gid attributes to sysfs > IB/core: Add ROCE_UDP_ENCAP (RoCE V2) type > IB/core: Move rdma_is_upper_dev_rcu to header file > IB/core: Validate route in ib_init_ah_from_wc and ib_init_ah_from_path > IB/rdma_cm:

Re: [PATCH for-next V2 05/11] IB/core: Add rdma_network_type to wc

> No, I am defining an API that *make sense* and doesn't leak useless > details. Of course that doesn't force code duplication or anyhting > like that, just implement it smartly. > > I think mlx made a big mistake returning network_type instead of gid > index, and I don't want to see that error

Re: [PATCH for-next V2 05/11] IB/core: Add rdma_network_type to wc

> Eh? I think you've missed the point, there is no net device when > looking at a wc. > > Look, here is a concrete direction: > > Replace all the crap in > ib_init_ah_from_wc/get_sgid_index_from_eth/rdma_addr_find_dmac_by_grh > > with a straightforward > >rdma_dgid_index_from_wc( >

Re: [PATCH for-next V2 05/11] IB/core: Add rdma_network_type to wc

On Mon, Dec 7, 2015 at 8:48 PM, Jason Gunthorpe <jguntho...@obsidianresearch.com> wrote: > On Mon, Dec 07, 2015 at 08:34:43PM +0200, Moni Shoua wrote: >> Well, just tell me how you want to discover gid_index when you poll >> the WC out of the CQ. > > Hey, I'm not

Re: [PATCH 00/37] Add rdma verbs transport library

On Mon, Dec 7, 2015 at 10:42 PM, Dennis Dalessandro wrote: > The following series implements rdmavt. This is the rdma verbs transport > software library which will help to solve the problem of code duplication > between hardware drivers when it comes to a verbs

Re: [PATCH for-next V2 05/11] IB/core: Add rdma_network_type to wc

>> >> A17.4.5.1 UD COMPLETION QUEUE ENTRIES (CQES) >> For UD, the Completion Queue Entry (CQE) includes remote address >> information (InfiniBand Specification Vol. 1 Rev 1.2.1 Section >> 11.4.2.1). For RoCEv2, the remote address information comprises the >> source L2 Address and a flag that

Re: [PATCH 20/37] IB/rdamvt: Add post send and recv stubs

Fix typo in the subject: IB/rdam --> IB/rdma -- 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 03/10] IB/qib: Use rdmavt protection domain

On Mon, Dec 7, 2015 at 10:49 PM, Dennis Dalessandro wrote: > Remove protection domain datastructure from qib and use rdmavts version. > I failed to apply this patch tried with rc3 and rc4 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the

Re: [PATCH for-next V2 05/11] IB/core: Add rdma_network_type to wc

On Mon, Dec 7, 2015 at 8:48 PM, Jason Gunthorpe <jguntho...@obsidianresearch.com> wrote: > On Mon, Dec 07, 2015 at 08:34:43PM +0200, Moni Shoua wrote: >> Well, just tell me how you want to discover gid_index when you poll >> the WC out of the CQ. > > Hey, I'm not

Re: [PATCH for-next V2 05/11] IB/core: Add rdma_network_type to wc

On Mon, Dec 7, 2015 at 8:19 PM, <c...@asomi.com> wrote: > Moni Shoua asked: > > > >> but how? all you have in hand is the sgid which can appear several > >> times in the GID table in different indices. > > > Step back and review the context. > >

Re: [PATCH for-next V2 05/11] IB/core: Add rdma_network_type to wc

same gid value can be present in multiple entries you need an extra parameter to get distinguish between them - that would be the netwrok_type On Mon, Dec 7, 2015 at 7:12 PM, Jason Gunthorpe <jguntho...@obsidianresearch.com> wrote: > On Mon, Dec 07, 2015 at 08:37:41AM +0200, Moni Sh

Re: [PATCH for-next V2 05/11] IB/core: Add rdma_network_type to wc

On Sun, Dec 6, 2015 at 4:03 PM, Christoph Hellwig wrote: > The ULPs couldn't really care less about the network type. The problem In WC, ULPs care about network type as much as they care for dgid or port_num So, network_type is indeed an information that is relevant only to

Re: [PATCH for-next V2 05/11] IB/core: Add rdma_network_type to wc

On Mon, Dec 7, 2015 at 8:34 AM, Jason Gunthorpe <jguntho...@obsidianresearch.com> wrote: > On Mon, Dec 07, 2015 at 08:15:40AM +0200, Moni Shoua wrote: > >> What you have though is the sgid taken from the GRH that is scattered >> to the first 40/20 bytes of the receive

Re: [PATCH for-next V2 05/11] IB/core: Add rdma_network_type to wc

On Mon, Dec 7, 2015 at 8:02 AM, Jason Gunthorpe wrote: > Why? The sgid index must tell you the network type. struct ib_wc doesn't have sgid or sgid_index field. What you have though is the sgid taken from the GRH that is scattered to the first 40/20 bytes of the

Re: [PATCH for-next V1 9/9] IB/cma: Join and leave multicast groups with IGMP

On Tue, Nov 24, 2015 at 8:15 PM, Jason Gunthorpe <jguntho...@obsidianresearch.com> wrote: > On Tue, Nov 24, 2015 at 11:41:10AM +0200, Moni Shoua wrote: >> On Mon, Nov 23, 2015 at 11:25 PM, Jason Gunthorpe >> <jguntho...@obsidianresearch.com> wrote: >> > On T

Re: [PATCH for-next V1 9/9] IB/cma: Join and leave multicast groups with IGMP

On Mon, Nov 23, 2015 at 11:25 PM, Jason Gunthorpe wrote: > On Thu, Oct 15, 2015 at 07:07:12PM +0300, Matan Barak wrote: >> diff --git a/include/rdma/ib_sa.h b/include/rdma/ib_sa.h >> index 0a40ed2..5bea0e8 100644 >> +++ b/include/rdma/ib_sa.h >> @@ -206,6 +206,9

Re: [RFC] RDMA verbs transport design notes

On Thu, Oct 29, 2015 at 9:41 PM, Dennis Dalessandro wrote: > Hi Folks, > > I had previously posted a notice about the very beginnings of the rdmavt > driver which is the software verbs consolidation for multiple drivers [1]. > I have now pushed another set of

Re: Create a common verbs transport library

Thanks, we'll look into it today On Fri, Oct 23, 2015 at 11:49 PM, Dennis Dalessandro <dennis.dalessan...@intel.com> wrote: > On Thu, Oct 15, 2015 at 05:15:38PM +0300, Moni Shoua wrote: >>> >>> I'm thinking perhaps we'll post some stuff to GitHub and you folks can >

Re: [PATCH 00/23] Update driver to 0.9-294

> Understood, however, unlike SoftRoCE, qib and hfi currently share a lot of > code > to drive the hardware. > > The underlying reason for the TODO item "Remove software processing of IB > protocol..." is because we have a large amount of duplicated code between > these > drivers. _Some_ of

Re: [PATCH 00/23] Update driver to 0.9-294

> > Perhaps I did not chose my words carefully enough. > > The largest issue on the TODO list is the refactoring of the code to be > shared between the hfi1 and qib driver. While the hardware between hfi1 and > qib is similar and thus the initial code looked similar, our performance > tuning

Re: Create a common verbs transport library

Hi Denny, We initially thought to implement a shared library that contains the transport logic. However, it seems that a SW Verbs transport driver would allow better code sharing. In fact, the VT driver would need only a single user-space driver for all "backends". Any direct HW access from

Re: [PATCH for-next V5 10/12] IB/mlx4: Implement ib_device callbacks

On Thu, Jun 11, 2015 at 9:31 AM, Jason Gunthorpe jguntho...@obsidianresearch.com wrote: On Mon, Jun 08, 2015 at 05:12:13PM +0300, Matan Barak wrote: +static struct net_device *mlx4_ib_get_netdev(struct ib_device *device, u8 port_num) +{ This function is never referenced in this patch, so

[PATCH] IB/core: Don't warn on no SA support in event handler

-by: Moni Shoua mo...@mellanox.com --- drivers/infiniband/core/multicast.c | 2 +- drivers/infiniband/core/sa_query.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/core/multicast.c b/drivers/infiniband/core/multicast.c index 605f20a..1244f02 100644

[PATCH] IB/core: Don't advertise SA in RoCE port capabilities

The Subnet Administrator (SA) is not a component of the RoCE spec. Therefore, it should not be a capability of a RoCE port. Signed-off-by: Moni Shoua mo...@mellanox.com --- include/rdma/ib_verbs.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/rdma/ib_verbs.h b/include/rdma

[PATCH] IB/core: Don't advertise SA in RoCE port capabilities

The Subnet Administrator (SA) is not a component of the RoCE spec. Therefore, it should not be a capability of a RoCE port. Change-Id: Iadfaa56bdc9f6e28f46d009064c2d15969293cf7 Signed-off-by: Moni Shoua mo...@mellanox.com --- include/rdma/ib_verbs.h | 1 - 1 file changed, 1 deletion(-) diff

[PATCH] IB/CMA: Fix condition to search for InfiniBand route

The flag RDMA_CORE_CAP_IB_SA is set when link layer is InfiniBand but also when link layer is Ethernet. Therefore, link layer is not implied by this flag. --- drivers/infiniband/core/cma.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/infiniband/core/cma.c

Re: [PATCH v3 for-next 01/33] IB/core: Add RoCE GID cache

On Wed, Apr 15, 2015 at 7:08 PM, Hefty, Sean sean.he...@intel.com wrote: It does not break every app, the choice of which GID type to use is made by the RDMA-CM based on network topology hint obtained from the IP stack. Please refer to patch 15/33: IB/Core: Changes to the IB Core

Re: [PATCH v3 for-next 01/33] IB/core: Add RoCE GID cache

On Wed, Apr 8, 2015 at 2:30 AM, Hefty, Sean sean.he...@intel.com wrote: In order to manage multiple types, vlans and MACs per GID, we need to store them along the GID itself. We store the net device as well, as sometimes GIDs should be handled according to the net device they came from. Since

Re: [PATCH 1/6] IB/Core: Changes to the IB Core infrastructure for RoCEv2 support

Although you follow the spec here, 3 types of RDMA_NETWORK are not really required. Maybe we can get rid of this Maybe we can get rid of this duplication [SOM]: Not sure i understood the duplication here or why it's not required? We now have a new 'network/L3' layer on top of L2 - that was

Re: [PATCH 1/6] IB/Core: Changes to the IB Core infrastructure for RoCEv2 support

On Thu, Dec 25, 2014 at 2:59 AM, Somnath Kotur somnath.ko...@emulex.com wrote: From: Somnath kotur somnath.ko...@emulex.com 1. Associate gid_index with a Type (as per V2 SPEC) in GID Table and GID Cache. 2. Modify GID Cache helper functions to search for gid_index based on GID Value

Re: [PATCH 0/2] Adding support for RoCE V2 specification

Agree with all your points above , except for point# 2. That IMHO would be more of a code refactoring/cleanup patch that can be taken up later once the baseline version is checked in as it's not really related to this patch ? Also, if we do that , then we also have to take care of the IB

Re: [PATCH 0/2] Adding support for RoCE V2 specification

On Tue, Dec 2, 2014 at 7:35 AM, Somnath Kotur somnath.ko...@emulex.com wrote: HI Moni, Thank you for your comments , please find my response inline. The overarching goal behind this patch is to keep RDMA-CM as the central entity that decides the protocol (ROCEV2 /ROCEV1) and hides

Re: [PATCH 0/2] Adding support for RoCE V2 specification

Yes, that is correct. The overarching goal behind this patch is to keep RDMA-CM as the central entity that decides the protocol (ROCEV2 /ROCEV1) and hides all the address resolution details from applications. I agree but with one comment. RDMA-CM, although preferred, is not mandatory to

Re: [PATCH 0/2] Adding support for RoCE V2 specification

On Thu, Nov 27, 2014 at 2:56 AM, Somnath Kotur somnath.ko...@emulex.com wrote: Please apply. Somnath Kotur (2): IB/Core: Changes to the IB Core infrastructure for RoCE V2. IB/ocrdma: Changes to comply with RoCEv2 Specification changes drivers/infiniband/core/addr.c | 13

Re: IB/mlx4: Build the port IBoE GID table properly under bonding

On 3/12/2014 12:17 PM, Bart Van Assche wrote: On 02/18/14 15:32, Moni Shoua wrote: Ha ha. Take another look. That's what I was just explaining about! :) On line 1743 when curr_master is non-NULL then Smatch doesn't complain because it understands about the relationship between curr_master

Re: [PATCH] IB/core: Suppress a sparse warning

On 3/12/2014 12:15 PM, Bart Van Assche wrote: On 03/10/14 17:08, Paul E. McKenney wrote: On Mon, Mar 10, 2014 at 04:02:13PM +0100, Yann Droneaud wrote: Hi, Le lundi 10 mars 2014 à 15:26 +0100, Bart Van Assche a écrit : On 03/10/14 14:33, Yann Droneaud wrote: Le lundi 10 mars 2014 à 13:22

Re: IB/mlx4: Build the port IBoE GID table properly under bonding

On 2/17/2014 1:52 PM, Dan Carpenter wrote: Hello Moni Shoua, This is a semi-automatic email about new static checker warnings. The patch ad4885d279b6: IB/mlx4: Build the port IBoE GID table properly under bonding from Feb 5, 2014, leads to the following Smatch complaint: drivers/infiniband/hw

Re: IB/mlx4: Build the port IBoE GID table properly under bonding

Ha ha. Take another look. That's what I was just explaining about! :) On line 1743 when curr_master is non-NULL then Smatch doesn't complain because it understands about the relationship between curr_master and curr_netdev. But here it is complaining about line 1749 where curr_master is NULL

RE: [PATCH V1 libibverbs 2/3] Use neighbour lookup for RoCE UD QPs Eth L2 resolution

We don't really care if the UDP packet is sent or not. All we want is to trigger ARP. - Moni S. -Original Message- From: Yann Droneaud [mailto:ydrone...@opteya.com] Sent: Tuesday, February 11, 2014 5:20 PM To: Or Gerlitz Cc: rol...@kernel.org; linux-rdma@vger.kernel.org; Moni Shoua

[PATCH v3] IB/CMA: Invalidate connections in port space IPoIB over Ethernet link layer

-by: Moni Shoua mo...@mellanox.co.il --- drivers/infiniband/core/cma.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c index b6a33b3..4530eb8 100644 --- a/drivers/infiniband/core/cma.c +++ b/drivers/infiniband

[PATCH v2] IB/CMA: Invalidate connections in port space IPoIB over Ethernet link layer

From: Moni Shoua mo...@mellanox.com This patch fixes a kernel crash in cma_set_qkey(). When link layer is ETHERNET it is wrong to use IPoIB port space since no IPoIB interface is available. Specifically, setting qkey when port space is RDMA_PS_IPOIB, requires mgid calculation and SA query which

Re: [PATCH] IB/CMA: fail qkey setting for RDMA_PS_IPOIB and IB_LINK_LAYER_ETHERNET

Yes, the kernel crashed after watchdog detected a lockup. This happened while running udaddy -p 0x2 with RoCE. The crash isn't 100% reproducible but I have a pair of nodes where that used to crash with probability of 50%. The fix you suggest seems to detect the mismatch between port space and link

[PATCH] IB/CMA: fail qkey setting for RDMA_PS_IPOIB and IB_LINK_LAYER_ETHERNET

From: Moni Shoua mo...@mellanox.com In general, when link layer is ETHERNET it is wrong to use IPoIB port space since no IPoIB interface is available. Specifically, setting qkey when port space is RDMA_PS_IPOIB, requires SA query which is impossible when link layer is IB_LINK_LAYER_ETHERNET

RE: HA mode bonding for IB over SDP

Thanks a lot for providing me such useful details. Besides the APM functionality one thing I don't understand is that why is the IB-bonding not working with SDP, as SDP also uses IPoIB for addressing. Can you please describe about the problem which doesn't allow the fail-over to take place

Re: HA mode bonding for IB over SDP

If you want a reference code that works you can browse cmpost (get from git clone git://git.openfabrics.org/~shefty/rdma-dev.git - chechout branch test-apps). There are several design issues that you need to resolve before you start to implement. Examples: 1. Where to add the code to - SDP:

Re: [PATCH] ib/cm: Cancel pending LAP message when exiting IB_CM_ESTABLISH state

Moni, I don't have a good way to test that this really fixes your problem, but it looks like it should. I considered merging the cm state and lap states together, but I wasn't convinced that that made things any simpler. Sean, I have a test that can verify the first hunk of the patch

[PATCH] IB/rdma_cm: cancel pending lap message when destroying an ID

adds another variable to hold the lap mad. Signed-off-by: Moni Shoua mo...@mellanox.com Signed-off-by: Amir Vadai am...@mellanox.com -- drivers/infiniband/core/cm.c | 25 ++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/core/cm.c b

Re: [PATCH] IB/CM: cancel pending lap message when destroying an ID

Sorry. The patch is to the CM. Subject was changed On Wed, Mar 2, 2011 at 5:45 PM, Moni Shoua mo...@voltaire.com wrote: When destroying a cm_id from a context of a work queue and if the lap_state of this cm_id is IB_CM_LAP_SENT, we need to release the reference of this id that was taken upon

Re: [ewg] [PATCH] IB/core: Control number of retries for SA to leave an MCG

Mike Heinz wrote: Wouldn't the BUSY patch I proposed last year deal with this situation? Can you please send a link to this patch? -Original Message- From: ewg-boun...@lists.openfabrics.org [mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Moni Shoua Sent: Wednesday

Re: [ewg] [PATCH] IB/core: Control number of retries for SA to leave an MCG

Mike Heinz wrote: It was discussed in the Linux-RDMA list for many months. You can find a list of the archived messages here: http://www.mail-archive.com/search?q=SA+Busyl=linux-rdma@vger.kernel.org The most recent version of the patch is here:

[PATCH V2] IB/ipoib: Leave stale send-only multicast groups

@lists.openfabrics.org/msg18928.html Changes from V1: - Add a module parameter to control the amount of time that an idle send-only group is allowed to stay joined. Signed-off-by: Yossi Etigin yos...@voltaire.com Signed-off-by: Moni Shoua mo...@voltaire.com -- drivers/infiniband/ulp/ipoib

RE: [ewg] [PATCH v4] IB Core: RAW ETH support

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

Name for a new type of QP

Hi, This message follows a discussion in the EWG mailing list. We want to promote a patch that enables use of a new QP type. This QP type lets the user post_send() data to its SQ and treat it as the entire packet, including headers. An example of use with this QP is sending Ethernet packets from

Re: [PATCH] librdmacm/mcraw: Add a new test application for user-space IBV_QPT_RAW_ETH QP type

Walukiewicz, Miroslaw wrote: No, no more changes are necessary. It is a standalone application. Mirek Are you sure? AFAIK, patches to kernel and libibverbs are required which were not accepted yet. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a

Re: [ewg] [PATCH v4] IB Core: RAW ETH support

Hi Roland, 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

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

RE: are IB port counters functioning over --IB-- with the RDMAoE patch set?

Did you try OFED-1.5.1 or even better, OFED-1.5.2? I know patches for counters with RoCEE were submitted since OFED-1.5 and I saw it working. -Original Message- From: Or Gerlitz Sent: Thursday, June 03, 2010 14:49 To: Eli Cohen; Vladimir Sokolovsky; Eli Cohen Cc: Linux RDMA list; Moni

Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses

Could you send a link to the git tree where I can find this commit and the related fixes? -- 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 See

Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses

Eli Cohen wrote: On Tue, Mar 23, 2010 at 12:34:13PM +0200, Or Gerlitz wrote: basically, as the subject line suggests, it should be in Dave's net-next tree I just need to clone this tree and need the url. Can you give it to me from .git/config? Thanks. -- To unsubscribe from this list: send

Re: Unicast, no dst warning from IPoIB

Why did we get this? It could happen since the IPoIB neighbour that the specific instance of IPoIB CM is pointing to might have SKBs in its queue. When REP arrives for this connection, it will re-queue all the queued SKBs again but there may be no dst for them anymore. Do you mean that it

Re: IPoIB issues

Eli Cohen wrote: I just posted a patch which might fix your problem. Please try it and let us know if it fixed anything. Hi Eli Although Josh already reported that the patch seems to fix the issue I have a question though. post_send failed prints were during work in datagram mode. I don't

Re: [ANNOUNCE] OFED 1.5 rc4 release is available

Limitations: - SLES10 SP3 on IA64 is not supported yet In what way is it unsupported? Our QA say that OFED-1.5 can be compiled on this platform. -- To unsubscribe from this list: send the line unsubscribe linux-rdma in the body of a message to majord...@vger.kernel.org More

Re: [PATCH] IB/ipoib: Do not turn on carrier to a non active port

Roland Dreier wrote: + if (ib_query_port(priv-ca, priv-port, attr) || + attr.state != IB_PORT_ACTIVE) { + ipoib_dbg(priv, wait with carrier until IB port is active\n); + if (test_bit(IPOIB_FLAG_OPER_UP, priv-flags)) +

How to handle illegal multicast addresses in IPoIB?

Hi, The problem in short: Illegal multicast addresses can be passed to ib_ipoib which will add them to the queue of multicast addresses it needs to join. From this point on ib_ipoib will get stuck in the attempt to join an illegal multicast group and without a giving a chance for other groups

Re: How to handle illegal multicast addresses in IPoIB?

Or Gerlitz wrote: Moni Shoua wrote: One patch (http://lists.openfabrics.org/pipermail/general/2009-August/061663.html) checks each multicast address for validity before it lets it get into the queue. isn't it the below commit which appears in Linus tree? Or. commit