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
---
d
>
> 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
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
> 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 fro
> 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 d
> 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 a
>
> 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&m=144968107508268&w=2
Your answer to the send() issue is first an agreement with the comment
and later says that it can't be done b
> 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 y
>
>
> 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.
>> http://marc.info/?l=linux-rdma&m
>
>
> 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 somethi
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 follo
> 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 cor
> 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, y
gt; 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: Add wra
> 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 ens
>>
>> 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 indica
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 implementation.
>
> Rdmavt is basica
On Mon, Dec 7, 2015 at 8:48 PM, Jason Gunthorpe
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 desiging this rocev2 stuff, th
> 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(
>
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 body of a message to majord...
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
On Mon, Dec 7, 2015 at 8:48 PM, Jason Gunthorpe
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 desiging this rocev2 stuff, th
On Mon, Dec 7, 2015 at 8:19 PM, 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.
>
> Adding an extra fiel
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
wrote:
> On Mon, Dec 07, 2015 at 08:37:41AM +0200, Moni Shoua wrote:
>> On Mon, Dec 7, 2015 a
On Mon, Dec 7, 2015 at 8:34 AM, Jason Gunthorpe
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 WQE. This is not enough to
>> de
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 receive WQE. This is not enough t
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
RoCE but it only foll
On Tue, Nov 24, 2015 at 8:15 PM, Jason Gunthorpe
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
>> wrote:
>> > On Thu, Oct 15, 2015 at 07:07:12PM +0300, Matan Barak wrote:
>> >> diff --
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 @@ struct ib_sa_mcmember_rec {
>>
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 updates to a GitHub repo [2] which
>
Thanks, we'll look into it today
On Fri, Oct 23, 2015 at 11:49 PM, Dennis Dalessandro
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
>>> take
>>
> 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 whic
>
> 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 on
On Thu, Oct 15, 2015 at 4:07 PM, Dennis Dalessandro
wrote:
> On Thu, Oct 15, 2015 at 08:40:25AM +0300, Moni Shoua wrote:
>>>
>>> I assume by user-space driver we are talking about libverbs? We have
>>> separate libraries for ipath/qib and hfi. We should probably
>
>
> I assume by user-space driver we are talking about libverbs? We have
> separate libraries for ipath/qib and hfi. We should probably coalesce these
> into a single library but that is a separate issue. PSM is also unrelated to
> the work here since PSM is not verbs.
>
Not libibverbs but lib (e
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 us
On Thu, Jun 11, 2015 at 9:31 AM, Jason Gunthorpe
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 we get compile
> warnin
ff-by: Moni Shoua
---
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
--- a/drivers/infiniband
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
---
include/rdma/ib_verbs.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 7d78794
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
---
include/rdma/ib_verbs.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/rdma
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 b/dr
On Wed, Apr 15, 2015 at 7:08 PM, Hefty, Sean 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
>> infrastructure for RoCEv2
On Wed, Apr 8, 2015 at 2:30 AM, Hefty, Sean 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 populating th
> 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
On Thu, Dec 25, 2014 at 2:59 AM, Somnath Kotur wrote:
> From: Somnath kotur
>
> 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 and Type.
> 3. Choose sgid_index from all the
>
> 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 t
On Tue, Dec 2, 2014 at 7:35 AM, Somnath Kotur 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 all the
>> addr
> 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
On Thu, Nov 27, 2014 at 2:56 AM, Somnath Kotur 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 +-
> drivers/
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 +01
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_
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 so
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/
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
+ Shani@Mellanox
-Original Message-
From: Or Gerlitz [mailto:or.gerl...@gmail.com]
Sent: Monday, February 18, 2013 6:48 PM
To: Roland Dreier
Cc: linux-rdma; Haggai Eran; Moni Shoua; sha...@mellano.com
Subject: Re: [PATCH for-next 00/10] mlx4: Add Memory Windows support
On Wed, Feb 6
-by: Moni Shoua
---
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/core/cma.c
From: Moni Shoua
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 is illegal over
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
From: Moni Shoua
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.
Signed-off-by: Moni
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 wit
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: via
> 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
(ib_
> Good catch, although, I think we can simplify the fix to the patch below
> (completely untested). Please let me know if this solves the issue for you.
>
> drivers/infiniband/core/cm.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/infiniband/core/cm.c b/d
Sorry. The patch is to the CM. Subject was changed
On Wed, Mar 2, 2011 at 5:45 PM, Moni Shoua 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
This patch adds another variable to hold the lap mad.
Signed-off-by: Moni Shoua
Signed-off-by: Amir Vadai
--
drivers/infiniband/core/cm.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/
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+Busy&l=linux-rdma@vger.kernel.org
>
> The most recent version of the patch is here:
>
> http://www.mail-archive.com/linux
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 Sho
@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
Signed-off-by: Moni Shoua
--
drivers/infiniband/ulp/ipoib/ipoib.h |8 +++-
drivers
If I understand you right this time then you ask what about will happen
if user calls create_qp() from user space with qp_type=6. Right?
I guess that this should be handled in code like with any other illegal
value.
---
Moni Shoua| +972-54-5567934
Along with the patches to the kernel we will send a patch to libibverbs
to expose the new values
---
Moni Shoua| +972-54-5567934
-Original Message-
From: Hefty, Sean [mailto:sean.he...@intel.com]
Sent: Friday, July 02, 2010 3:34 AM
To: Moni
Hi,
This message follows a discussion about names for a new QP type (see
http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg04512.html) and
precedes a patch set for RAW QP that we intend to send.
The patch requires changes in enum ib_qp_type
1. Rename IB_QPT_RAW_ETY to IB_QPT_RAW_ETHERTYP
AQ
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 Coh
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
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
>
>
> 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 as
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 di
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
> maybe your'e looking for this one
> http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commit;h=32a806c194ea112cfab00f558482dd97bee5e44e
This is the link to the related patch of course but it also tells you which
tree to clone
--
To unsubscribe from this list: send the line "un
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 l
> 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
>
> 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
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'
> 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
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 app
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 to
port in the carrier_task before
calling netif_carrier_on().
Signed-off-by: Moni Shoua
---
drivers/infiniband/ulp/ipoib/ipoib_multicast.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
Roland Dreier wrote:
> And by the way, this current patch has a deadlock I think:
>
> > @@ -724,6 +724,8 @@ int ipoib_ib_dev_down(struct net_device *dev, int
> flush)
> >ipoib_dbg(priv, "downing ib_dev\n");
> >
> >clear_bit(IPOIB_FLAG_OPER_UP, &priv->flags);
> > + cancel_delayed_w
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))
> > + queu
the IB port in the carrier_task before
calling netif_carrier_on().
Signed-off-by: Moni Shoua
---
drivers/infiniband/ulp/ipoib/ipoib.h |2 +-
drivers/infiniband/ulp/ipoib/ipoib_ib.c|2 ++
drivers/infiniband/ulp/ipoib/ipoib_main.c |2 +-
drivers/infiniband/ulp
89 matches
Mail list logo
