in_dev_get() can return NULL. If it does, iwch_query_port() will crash.
Handle the NULL case by mapping it to rdma state INIT.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb3/iwch_provider.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions
This failure, while indicating fatal problems with the device, shouldn't
kill the system.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb3/cxio_hal.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3
Or Gerlitz wrote:
Faisal Latif wrote:
when listener is destroyed for loopback connection
Does the upstream iwarp stack supports loopback connections? does it
apply to all vendors?
Or.
Loopback support is provider-specific. There is no software iwarp
loopback, if that's what your asking.
It appears the MLX4 driver does not support kernel mode memory regions.
You'll have to use dma mrs or fast_reg mrs with that device.
Steve.
lihaidong wrote:
Mr.Wise:
When using mr mode as the memory registration method, krping failed to
get memory region using ib_reg_phys_mr().Could
lihaidong wrote:
Mr.Wise
I'm actually rewritting your program in order to get familiar with
Verbs+CMA API. In order to make the procedure more clearly, I put
nearly all the stuff into two long functions, one for server, the
other for client, the cq/cma event handler are the only exception.
I
Why data transferring happened before server waked up from waiting for
CONNECTED?
This can happen. There is a race between getting the CONNECTED event
and the first incoming data completion (like a recv completion).
Could give me some tips to fix this? Since this sometimes will upset
lihaidong wrote:
Mr.Wise
||| else {
|||
||| cb-rdma_sq_wr.opcode = IB_WR_RDMA_READ;
||| if (cb-mem == FASTREG) {
||| /*
||| * Immediately follow the read with a
lihaidong wrote:
Mr.Wise
You need to start calling me Steve. You're making me feel older than I
am. ;-)
When krping setup buffers failed, ib_free_fast_reg_page_list is used;
When krping free buffers, ib_free_fast_reg_page_list is not used.
Though krping still works well, could you an
get
the DB_EMPTY event
- On DB_DROP event:
- disable db rings in the event handler
- delay-schedule a work task which rings and enables the dbs on
all active qps.
- in post_send and post_recv logic, don't ring the db if its disabled.
Signed-off-by: Steve Wise sw
Only kernel mode CQs need the sw queue memory allocated. The sw queue
for user mode CQs is allocated in user mode by libcxgb3.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb3/cxio_hal.c | 20 +++-
drivers/infiniband/hw/cxgb3
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb3/cxio_hal.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.h
b/drivers/infiniband/hw/cxgb3/cxio_hal.h
index baa2867..073373c 100644
--- a/drivers
Roland,
Sorry, this is actually v1 of this patch.
Steve.
Steve Wise wrote:
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb3/cxio_hal.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.h
b
Sean Hefty wrote:
But how can you determine _which_ rdma device should be used if and app
binds to 127.0.0.1? I think this is busted...
The code just picks the first rdma device available. To me, this is preferable
than simply disallowing the loopback device from working at all. I
Sean Hefty wrote:
At first thought, we can extend enum ib_device_cap_flags to indicate if a device
supports loopback capabilities or not. The rdma_cm could then skip over such
devices when dealing with a loopback address.
This solution would work. Will you code it up?
Stevo
--
To
Sean Hefty wrote:
Well then the rdma-cm needs to know which devices support hw loopback.
Cuz on a T3-only system, no hwloop...
The problem sounds like it's more than just whether 127.0.0.1 is usable. That
check may fix openmpi, but it sounds more like the app needs to know whether the
Roland Dreier wrote:
Hey Roland, are you ok with a device attribute to indicate hw-loopback
support?
Sigh, I guess so. Can we have the rdma-cm handle this somewhat
automagically, eg only choose devices that do handle loopback when
binding/connecting to 127.0.0.1?
That's the plan.
Or
Jeff Squyres (jsquyres) wrote:
Note that it is highly unlikely that we will release open mpi 1.4.2 in
time for ofed 1.5.1.
Jeff, there is no way to handle high priority bug fixes in the current
released stream?
Also note that trying to bind rdma cm to all interface ip addresses
was the
Sean Hefty wrote:
Also note that trying to bind rdma cm to all interface ip addresses was the way
that we were advised by openfabrics to figure out which devices are rdma-
capable.
As such, it is highly desirable to get the fix transparently in rdmacm and
preserve the old semantic. More
I agree that we should probably not allow 127.0.0.1 binds in
ofed-1.5.1 at all because it regresses OpenMPI. Even with IB systems,
if the bind to 127.0.0.1 succeeds, then OpenMPI assumes 127.0.0.1 is
bound to that rdma interface and advertises this address to its peer
as an address to-which
Sean Hefty wrote:
My concern is breaking an existing working OpenMPI in a point release
because we changed semantics of the rdma-cm in an ofed point release...
OFED can call this release a point release, but in reality, the content makes it
a major release...
BTW: Was this change
Jeff Squyres wrote:
On Feb 5, 2010, at 12:51 PM, Roland Dreier (rdreier) wrote:
But Jeff, note that if someone uses the upstream kernel and OpenMPI,
its busted...
Is the issue 6f8372b6 (RDMA/cm: fix loopback address support)? This
just went in for 2.6.33, which is still at -rc6, so if
Jeff Squyres wrote:
On Feb 5, 2010, at 4:14 PM, Jason Gunthorpe wrote:
Well, I think you are right. This kind of change seems appropriate to
me for mainline, but OFED/RHEL should carry a responsibility to manage
an identified incompatibility, either patch their kernel, patch their
OMPI, or
Sean Hefty wrote:
There is still some inconsistency here. Sean, you claimed binds to
127.0.0.1 succeed in ofed-1.4 for IB devices. If so, then folks running
IB/openmpi/rdmacm should be seeing issues. We need to dig a little more...
You can verify this by running ucmatose -b 127.0.0.1
Sean Hefty wrote:
There is still some inconsistency here. Sean, you claimed binds to
127.0.0.1 succeed in ofed-1.4 for IB devices. If so, then folks running
IB/openmpi/rdmacm should be seeing issues. We need to dig a little more...
You can verify this by running ucmatose -b 127.0.0.1
rdma/cm: disallow loopback address for iwarp devices
From: Sean Hefty sean.he...@intel.com
The current RDMA iWarp devices cannot be used to establish
connections using the loopback address. Prevent rdma_bind_addr
from associating the loopback address with an iWarp device.
This fixes an
.
Steve Wise wrote:
rdma/cm: disallow loopback address for iwarp devices
From: Sean Hefty sean.he...@intel.com
The current RDMA iWarp devices cannot be used to establish
connections using the loopback address. Prevent rdma_bind_addr
from associating the loopback address with an iWarp device
Good catch, I'll update the patch and submit for 2.6.33 on Monday.
NOTE: This doesn't solve our IB/openmpi regression for ofed-1.5.1.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More
Tziporet Koren wrote:
On 2/7/2010 3:22 AM, Steve Wise wrote:
Good catch, I'll update the patch and submit for 2.6.33 on Monday.
NOTE: This doesn't solve our IB/openmpi regression for ofed-1.5.1.
If this patch will be accepted to the kernel 2.6.33 we can take it too
If ofed
Roland Dreier wrote:
My point, though, is that even with this patch in ofed-1.5.1, we still
have an openmpi/IB/rdmacm regression. The only way to avoid this
regression without changing openmpi is to disallow _all_ rdma binds to
127.0.0.1.
Can you identify the source of the regression?
Tziporet Koren wrote:
On 2/7/2010 6:39 PM, Steve Wise wrote:
If ofed-1.5.1 is based on 2.6.33 then it will get this patch
automatically (assuming it goes upstream and makes 2.6.33). Or we can
pull it in as a kernel_patches/fixes/ patch.
OFED 1.5.1 is not based on 2.6.33, but on 2.6.30, so
This patch doesn't solve the openmpi/IB regression. So for OFED, IMO,
we need a different patch...
Tziporet Koren wrote:
On 2/8/2010 8:02 AM, Sean Hefty wrote:
Since iWarp devices are not guaranteed to support loopback connections,
prevent rdma_bind_addr from associating the loopback
Jason Gunthorpe wrote:
On Mon, Feb 08, 2010 at 08:52:10AM -0800, Roland Dreier wrote:
This patch doesn't solve the openmpi/IB regression. So for OFED,
IMO, we need a different patch...
If this doesn't solve the regression the we should have a different
patch for upstream too. The
address, we can
re-enable this functionality.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/core/cma.c | 16 ++--
1 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index
Sean Hefty wrote:
IMO 127.0.0.1 should be for SW loopback, not HW RDMA loopback.
I disagree, but what does it matter? So, we add a 'software' loopback that uses
127.0.0.1. Openmpi still wouldn't work.
I guess that's true.
I will commit to get the fix in openmpi asap.
If
openmpi is fixed to
correctly ignore 127.0.0.1 as a valid external rdma address, we can
re-enable this functionality.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/core/cma.c | 16 ++--
1 files changed, 2 insertions(+), 14 deletions(-)
diff --git
Sean, can you try openmpi? It fails for me, and yet ucmatose succeeds.
I don't understand the difference yet...
Sean Hefty wrote:
On my OFED 1.4.1 RHEL4u6 systems, rdma_bind_addr() fails when attempting to
bind to 127.0.0.1 per the email I sent Friday:
This patch works. It also backports cleanly to ofed-1.5.1/RH5.3.
Acked-by: Steve Wise sw...@opengridcomputing.com
Steve.
Sean Hefty wrote:
Revert the following change from commit
6f8372b69c3198e06cecb1df2cb9682d0c55e657:
The defined behavior of rdma_bind_addr is to associate an RDMA
Roland Dreier wrote:
OK, I'm planning on sending this upstream later today. Looks very small
and simple, and then we can figure our what if anything we want to do
for 2.6.34.
Make sense for everyone?
- R.
Yes.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
mark the device with CXIO_ERROR_FATAL when removing.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb3/iwch.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch.c
b/drivers/infiniband/hw/cxgb3/iwch.c
During a hot-plug LLD removal event or an EEH error event, iw_cxgb3
must ensure that any/all threads that might be in a cxgb3 exported function
concurrently must return from the function before iw_cxgb3 returns from
its event processing. Do this by calling synchronize_net().
Signed-off-by: Steve
lihaidong wrote:
Sorry.
sge[1]= {vec1_addr, vec1_length, dma_lkey};
should be
sge[1]= {vec2_addr, vec2_length, dma_lkey};
Hi, Steve.
I have the following questions.
1)FRMR
I want transfer the data in vec1 and vec2 in node A to the two vecs
with the same size in node B. Vecs' size is lower
I try getting a summary. Give some comments on the following
sentences,please.
For local side(A), where data to be transferred is placed.
send or RDMA Read/Write operations.
the sge array in one send wr pointed by sgl_list should have the same
[lr]key.
a) one send wr could send two
lihaidong wrote:
If I use send/recv operations to send the two arbitrary regions form A
to B.How about the data order?
I mean
for side A
sge[0] = {A_vec1_addr,A_vec1_len, A_lkey}
sge[1] = {A_vec2_addr,A_vec2_len, A_lkey}
ib_send_wr.sg_list = sge;
for side B
sge[0] =
Hello rdma wizards,
I'm trying to understand how IB UD service works with the rdmacm in
linux. According to the IBTA specification, I should be able to create
a single UD QP and exchange messages with any number of peers as long as
I know their qkeys. Yet when I look at udaddy.c (and even
Sean Hefty wrote:
I'm trying to understand how IB UD service works with the rdmacm in
linux. According to the IBTA specification, I should be able to create
a single UD QP and exchange messages with any number of peers as long as
I know their qkeys. Yet when I look at udaddy.c (and even
Without more info, I cannot help much. Are you calling it in a save
context? You probably cannot call it from an interrupt context. Was
there a stack trace?
lihaidong wrote:
Hi, Steve
Could you help me with this case.
The server has 16GB memory,linux-2.6.29, OFED-1.5
When using
Hey Roland and RDMA experts,
I'd like to raise an issue with the the architecture of the Linux RDMA
subsystem regarding device removal and RDMA provider deregistration:
IBM/PPC and probably other vendors/platforms have virtual or logical
partitions running Linux and they want to be able to
Sean Hefty wrote:
4) rdma_ucm gets this event and dutifully posts it for the use app to
reap. But since the app doesn't reap this event and exit or at least
destroy the cm id, nothing else happens.
For the rdma_ucm, it should post the event, but destroy the underlying
rdma_cm_id
Tung, Chien Tin wrote:
[...]
They also want
to be able to reset a failed device (EEH events
[...]
1) device A event happens causing the device to unregister itself with
the RDMA core. This could be an EEH event requiring full device reset,
or a OS hot-plug removal event.
Tung, Chien Tin wrote:
In other words, I think we want the ucma context to stay around until
the application destroys it (via explicit means or via exit). But the
rdma_cm_id gets destroyed immediately upon receiving a DEVICE_REMOVE event.
How do we take care of evil applications that
Roland Dreier wrote:
In other words, I think we want the ucma context to stay around until
the application destroys it (via explicit means or via exit). But
the rdma_cm_id gets destroyed immediately upon receiving a
DEVICE_REMOVE event.
Yes. The RDMA CM is somewhat easier, but I
Steve Wise wrote:
But to Roland's point, how will we ummap resources?
If an application won't respond to device removal event and clean up
properly,
perhaps it is okay to let it crash. Alternatively, what about a
RDMA_CM_EVENT_DEVICE_REMOVAL_PENDING and RDMA_CM_EVENT_DEVICE_REMOVED
scheme
Roland Dreier wrote:
We need a way to revoke that
mmap and have it point at a dummy page until userspace releases it --
and last I looked I wasn't sure how to do that.
do_mremap()?
Not exported to modules, is it?
no. :(
--
To unsubscribe from this list: send the line
Hey Sean,
I'm trying NFSRDMA on net-next and the server side fails when
registering the rdma transport. I think its due to the INET6 support
added to the rdma-cm. I'm still debugging though.
In fs/nfsd/nfsctl.c:__write_ports_addxprt(), it tries to create a new
svc transport for PF_INET,
Actually, this looks like a recent nfs change that now creates an INET
and INET6 transport when you add one via the /proc/fs/nfsd/portlist
file. Looking at 2.6.30, which works, the nfsctl.c code is very
different and only creates an INET transport...
Steve Wise wrote:
Hey Sean,
I'm
Sean Hefty wrote:
The rdma_cm might be able to support this if the port space were separated based
on the address family, depending on how PS IB ends up.
I think separate port spaces is the correct solution.
Steve.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
Looks good.
Tom Tucker wrote:
If this looks right to everyone, I'll post this to linux-nfs.
Tom
nfsd: Make INET6 transport creation failure an informational message
The write_ports code will fail both the IENT4 and INET6 transport
creation if
the transport returns an error when PF_INET6 is
The following series adds the iw_cxgb4 rdma driver for Chelsio's new
1G and 10G T4 adapters. Please review and provide comments, and
I'll repost an updated patch series as I incorporate your feedback.
This series depends on the cxgb4 driver recently merged into:
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/device.c | 520 ++
1 files changed, 520 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/device.c
diff --git a/drivers/infiniband/hw/cxgb4/device.c
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/provider.c | 521
1 files changed, 521 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/provider.c
diff --git a/drivers/infiniband/hw/cxgb4
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/cq.c | 885 ++
1 files changed, 885 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/cq.c
diff --git a/drivers/infiniband/hw/cxgb4/cq.c b
The low level cxgb3 driver can return NET_XMIT_CN and friends.
The iw_cxgb3 driver should _not_ treat these as errors.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb3/iwch_cm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Roland Dreier wrote:
Is this a regression fix for 2.6.34, or just something to queue for 2.6.35?
--
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
Roland Dreier wrote:
+unsigned qib_debug;
+module_param_named(debug, qib_debug, uint, S_IWUSR | S_IRUGO);
+MODULE_PARM_DESC(debug, mask for debug prints);
Did you look at using trace events for this stuff? That gives you
extremely low overhead when tracing is turned off (dynamic patching
Sean Hefty wrote:
+static inline int
+rdma_get_send_comp(struct rdma_cm_id *id, struct ibv_wc *wc)
+{
+ struct ibv_cq *cq;
+ void *context;
+ int ret;
+
+ ret = ibv_poll_cq(id-send_cq, 1, wc);
+ if (ret)
+ return ret;
+
+ ret =
Roland Dreier wrote:
+int peer2peer = 0;
+module_param(peer2peer, int, 0644);
+MODULE_PARM_DESC(peer2peer, Support peer2peer ULPs (default=0));
If you build iw_cxgb3 and iw_cxgb4 into the kernel, the peer2peer symbol
names clash. (Same problem occurs if you try to load cxgb3 and cxgb4
Roland Dreier wrote:
You have:
+struct fw_ri_send_wr {
...
+ __be16 wrid;
+struct fw_ri_recv_wr {
...
+ __be16 wrid;
But also:
+static inline void init_wr_hdr(union t4_wr *wqe, u16 wrid,
+enum fw_wr_opcodes opcode, u8 flags, u8 len16)
...
+
Sean Hefty wrote:
I think it's possible for the function to return without having filled in a
wc.
So its busted? Or is this intended behavior?
Depends on the point of view, I guess. :) It would be nice to avoid that
situation.
Is rdma_get_send_completion() supposed to
Hey Roland,
Is QP type IB_QPT_RAW_ETY intended to provide a raw Ethernet service for
sending/receiving Ethernet frames?
Steve.
--
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
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/device.c | 520 ++
1 files changed, 520 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/device.c
diff --git a/drivers/infiniband/hw/cxgb4/device.c
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/provider.c | 518
1 files changed, 518 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/provider.c
diff --git a/drivers/infiniband/hw/cxgb4
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/mem.c | 811 +
1 files changed, 811 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/mem.c
diff --git a/drivers/infiniband/hw/cxgb4/mem.c
b
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/cq.c | 882 ++
1 files changed, 882 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/cq.c
diff --git a/drivers/infiniband/hw/cxgb4/cq.c b
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/qp.c | 1542 ++
1 files changed, 1542 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/qp.c
diff --git a/drivers/infiniband/hw/cxgb4/qp.c b
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/resource.c | 417
1 files changed, 417 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/resource.c
diff --git a/drivers/infiniband/hw/cxgb4
Tung, Chien Tin wrote:
NE020 supports 4 SGEs. I don't know enough about SDP to know why it is
using this calculation for # of send_sge:
#define SDP_MAX_RECV_SKB_FRAGS (PAGE_SIZE 0x8000 ? 1 : 0x8000 / PAGE_SIZE)
Chien, does the NE020 support FMRs? I looked at the nes ofed-1.5 code
Hey Amir,
I don't think this helps because sdp_add_device() will not add rdma
devices that fail to create fmr pools.
So I guess you could key off of fmr pool failures and set
sdp_zcopy_thresh to 0 and allow the device to be used?
But what we really need is sdp support for fastreg_mrs as
The libcxgb4 package is a userspace driver for the new Chelsio T4 iWARP
RNICs. It is a plug-in module for libibverbs that allows programs to
use Chelsio RDMA T4 hardware directly from userspace.
The initial release of this library is now available at:
Changes since version 2 of this series:
- termination fixes
- peer2peer fixes
--
The following series adds the iw_cxgb4 rdma driver for Chelsio's new
1G and 10G T4 adapters. Please review and provide comments, and
I'll repost an updated patch series as I incorporate your feedback.
This
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/Kconfig |1 +
drivers/infiniband/Makefile |1 +
drivers/infiniband/hw/cxgb4/Kconfig | 19 +++
drivers/infiniband/hw/cxgb4/Makefile |5 +
4 files changed, 26
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/device.c | 520 ++
1 files changed, 520 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/device.c
diff --git a/drivers/infiniband/hw/cxgb4/device.c
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/provider.c | 518
1 files changed, 518 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/provider.c
diff --git a/drivers/infiniband/hw/cxgb4
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/cq.c | 882 ++
1 files changed, 882 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/cq.c
diff --git a/drivers/infiniband/hw/cxgb4/cq.c b
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/qp.c | 1575 ++
1 files changed, 1575 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/qp.c
diff --git a/drivers/infiniband/hw/cxgb4/qp.c b
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/ev.c | 193 ++
1 files changed, 193 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/ev.c
diff --git a/drivers/infiniband/hw/cxgb4/ev.c b
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/resource.c | 417
1 files changed, 417 insertions(+), 0 deletions(-)
create mode 100644 drivers/infiniband/hw/cxgb4/resource.c
diff --git a/drivers/infiniband/hw/cxgb4
Hey Roland,
I'll be off line next week, returning on 4/26. I'll address any
comments/issues when I return.
Thanks!
Steve.
Steve Wise wrote:
Changes since version 2 of this series:
- termination fixes
- peer2peer fixes
--
The following series adds the iw_cxgb4 rdma driver
Amir Vadai wrote:
I have a fix for 2027 (number of SGE's issue) read.
I'm busy with other things - but hopefully will succeed testing it and
pushing it today.
As to 2028 (No FMR support) - I need pushed a fix to only disable ZCopy
when no FMR facility.
I don't have time right now to add
Looks ok to me. Functionally it doesn't change anything I guess.
Roland Dreier wrote:
Hey Steve,
What do you think about this for the next merge window? I think it
arguably makes the source cleaner, and it definitely makes the compiled
code better:
add/remove: 0/1 grow/shrink: 4/3
Roland Dreier wrote:
Looks ok to me. Functionally it doesn't change anything I guess.
That's the hope at least...
If you push this into your for-next branch, I'll regression test it.
Steve.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message
BTW: I agree with the core changes proposed in this series as well as
the patch adding the RAW_ETY QP type for user mode.
Steve.
Mirek Walukiewicz wrote:
This patch series implements iWarp multicast acceleration over raw eth QP type.
In ibv_attach_mcast and ibv_detach_mcast, new case is
I see here some misunderstanding. Let me explain better how our tramsmit path works.
In our implementation we use normal memory registration path using ibv_reg_mr
and we use ibv_post_send() with lkey/vaddr/len.
The implementation of ibv_post_send (nes_post_send in libnes) for RAW QP passes
Until I implement the MPA extensions Internet Draft, make the ord/ird
max values for T4 match those of T3 (8). Also add a module option to
allow upping the value for pure T4 environments.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/cm.c | 13
From: root r...@t4.ogc.int
Schedule the workq handler to process timed out endpoints rather than
try and process them on the timeout interrupt.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/cm.c | 112 +---
drivers
From: root r...@t4.ogc.int
Calls from post_qp_event() are in the interrupt context, so use GFP_ATOMIC
as necessary.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/ev.c |2 +-
drivers/infiniband/hw/cxgb4/qp.c | 24
2 files
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/cm.c |2 +-
drivers/infiniband/hw/cxgb4/ev.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw/cxgb4/cm.c
index d146639
There are 2 limits that need to be taken into account when arming the CQ.
1) the GTS register limits the delta idx to = 0xfff.
2) T4 HW limits it to cq size.
Update t4_arm_cq() to account for these limits.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4
CQ overflow detection needs to read the gen bit and the timestamp in
one read operation. Otherwise false overflows can result.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/hw/cxgb4/t4.h |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git
For iWARP rdma_cm ids, the route information is the L2 src and
next hop addresses.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
---
drivers/infiniband/core/ucma.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/core/ucma.c b
Hey Roland,
Do you have thoughts on this change? It is useful along with the
IBV_QPT_RAW_ETY type added to libibverbs for cxgb devices too.
Steve.
miroslaw.walukiew...@intel.com wrote:
The patch enables usage of attach_mcast()/detach_mcast driver
specific verbs for iWARP devices.
IB path
1 - 100 of 833 matches
Mail list logo
