On 4/21/15 2:39 AM, Michael Wang wrote:
On 04/20/2015 05:51 PM, Tom Tucker wrote:
[snip]
int ib_query_gid(struct ib_device *device,
u8 port_num, int index, union ib_gid *gid);
iWARP devices _must_ support the IWCM so cap_iw_cm() is not really useful.
Sean suggested
On 4/20/15 11:19 AM, Jason Gunthorpe wrote:
On Mon, Apr 20, 2015 at 10:51:58AM -0500, Tom Tucker wrote:
On 4/20/15 10:16 AM, Michael Wang wrote:
On 04/20/2015 04:00 PM, Steve Wise wrote:
On 4/20/2015 3:40 AM, Michael Wang wrote:
[snip]
diff --git a/include/rdma/ib_verbs.h b/include/rdma
On 4/20/15 10:16 AM, Michael Wang wrote:
On 04/20/2015 04:00 PM, Steve Wise wrote:
On 4/20/2015 3:40 AM, Michael Wang wrote:
[snip]
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 6805e3e..e4999f6 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@
On 4/16/15 8:45 AM, Michael Wang wrote:
On 04/16/2015 03:42 PM, Hal Rosenstock wrote:
On 4/16/2015 9:41 AM, Michael Wang wrote:
On 04/16/2015 03:36 PM, Hal Rosenstock wrote:
[snip]
-EXPORT_SYMBOL(rdma_node_get_transport);
-
enum rdma_link_layer rdma_port_get_link_layer(struct ib_device
: Tom Tucker t...@opengridcomputing.com
Cc: Steve Wise sw...@opengridcomputing.com
Cc: linux-rdma@vger.kernel.org
---
drivers/scsi/fnic/vnic_dev.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/fnic/vnic_dev.c b/drivers/scsi/fnic/vnic_dev.c
index 9795d6f
Hi Trond,
I think this patch is still 'off-by-one'. We'll take a look at this today.
Thanks,
Tom
On 3/12/14 9:05 AM, Trond Myklebust wrote:
On Mar 12, 2014, at 9:33, Jeff Layton jlay...@redhat.com wrote:
On Sat, 08 Mar 2014 14:13:44 -0600
Steve Wise sw...@opengridcomputing.com wrote:
On
Hi Chuck,
I have a patch for the server side that simplifies the memory registration
and fixes a bug where the server ignores the FRMR hardware limits. This
bug is actually upstream now.
I have been sitting on it because it's a big patch and will require a lot
of testing/review to get it
and therefore, the only way to recover what the opcode was is
through the wr_id you used when submitting the WR.
Is my reading of the code correct?
Thanks,
Tom
On 5/20/13 9:53 AM, Jack Morgenstein wrote:
On Saturday 18 May 2013 00:37, Roland Dreier wrote:
On Fri, May 17, 2013 at 12:25 PM, Tom Tucker t
On 5/20/13 2:58 PM, Hefty, Sean wrote:
My reading of the code (i.e. hw/mlx4/cq.c) is that the hardware cqe
owner_sr_opcode field contains MLX4_CQE_OPCODE_ERROR when there is an
error and therefore, the only way to recover what the opcode was is
through the wr_id you used when submitting the WR.
Hi Roland,
I'm looking at the Linux MLX4 net driver and found something that confuses
me mightily. In particular in the file net/ethernet/mellanox/mlx4/cq.c,
the mlx4_ib_completion function does not take any kind of lock when
looking up the SW CQ in the radix tree, however, the mlx4_cq_event
On 4/30/13 9:38 AM, Yan Burman wrote:
-Original Message-
From: Tom Talpey [mailto:t...@talpey.com]
Sent: Tuesday, April 30, 2013 17:20
To: Yan Burman
Cc: J. Bruce Fields; Wendy Cheng; Atchley, Scott; Tom Tucker; linux-
r...@vger.kernel.org; linux-...@vger.kernel.org; Or Gerlitz
Subject
On 4/29/13 7:16 AM, Yan Burman wrote:
-Original Message-
From: Wendy Cheng [mailto:s.wendy.ch...@gmail.com]
Sent: Monday, April 29, 2013 08:35
To: J. Bruce Fields
Cc: Yan Burman; Atchley, Scott; Tom Tucker; linux-rdma@vger.kernel.org;
linux-...@vger.kernel.org; Or Gerlitz
Subject: Re
On 4/29/13 8:05 AM, Tom Tucker wrote:
On 4/29/13 7:16 AM, Yan Burman wrote:
-Original Message-
From: Wendy Cheng [mailto:s.wendy.ch...@gmail.com]
Sent: Monday, April 29, 2013 08:35
To: J. Bruce Fields
Cc: Yan Burman; Atchley, Scott; Tom Tucker; linux-rdma@vger.kernel.org;
linux
is a smoking, flaming gun though. Maybe Tom Tucker
has some ideas on the srv rdma code, but it could also be in the sunrpc
or infiniband driver layers, can't really tell without the call stacks.
The Mellanox driver uses red-black trees extensively for resource
management, e.g. QP ID, CQ ID, etc
On 2/6/13 3:28 PM, Steve Wise wrote:
On 2/6/2013 4:24 PM, J. Bruce Fields wrote:
On Wed, Feb 06, 2013 at 05:48:15PM +0200, Yan Burman wrote:
When killing mount command that got stuck:
---
BUG: unable to handle kernel paging request at 880324dc7ff8
, are independent and do not rely on each other. I have tested
them indepently and together on 64b with both Infiniband and iWARP. They have
been
compile tested on 32b.
---
Tom Tucker (2):
RPCRDMA: Fix FRMR registration/invalidate handling.
RPCRDMA: Fix to XDR page base interpretation
. For
the other modes, it would result in silent data corruption. This bug is
most easily reproduced by writing more data than the filesystem
has space for.
This fix corrects the page_base assumption and otherwise simplifies
the iov mapping logic.
Signed-off-by: Tom Tucker t...@ogc.us
---
net/sunrpc
is prepended, re-syncing the FRMR state and avoiding the connection loss.
Signed-off-by: Tom Tucker t...@ogc.us
---
net/sunrpc/xprtrdma/verbs.c | 52 +--
net/sunrpc/xprtrdma/xprt_rdma.h |1 +
2 files changed, 45 insertions(+), 8 deletions(-)
diff
catastrophic, but still broken behavior you see now.
Unfortunately I can only support this part-time, but I'll keep you
updated on the progress.
Thanks for finding this and helping to debug,
Tom
Thanks for your help
S.
On 12/07/2010 05:12 PM, Tom Tucker wrote:
Status update...
I have reproduced
:59 AM, Tom Tucker wrote:
Spelic,
I have seen this problem before, but have not been able to reliably
reproduce it. When I saw the problem, there were no transport errors
and it appeared as if the I/O had actually completed, but that the
waiter was not being awoken. I was not able
system monitoring applications (e.g. vmstats) at zero overhead to the
monitored host.
---
Tom Tucker (2):
IB/uverbs: Add support for user registration of mmap memory
IB/uverbs: Add memory type to ib_umem structure
drivers/infiniband/core/umem.c | 272
that exports the VM_PFNMAP memory is hot removed?
Bus Address Error.
Can the device reference count be incremented to prevent that?
I don't think that would go in this code, it would go in the driver that
gave the user the address in the first place.
On Thu, 2010-12-02 at 11:02 -0800, Tom Tucker
Hi Spelic,
Can you reproduce this with an nfsv3 mount?
On 12/1/10 5:13 PM, Spelic wrote:
Hello all
First of all: I have tried to send this message to the list at least 3
times but it doesn't seem to get through (and I'm given no error back).
It was very long with 2 attachments... is is
Spelic,
I have seen this problem before, but have not been able to reliably
reproduce it. When I saw the problem, there were no transport errors and
it appeared as if the I/O had actually completed, but that the waiter was
not being awoken. I was not able to reliably reproduce the problem and
On 11/30/10 9:24 AM, Alan Cook wrote:
Tom Tuckert...@... writes:
Yes. I removed the new verb and followed Jason's recommendation of adding
this support to the core reg_mr support. I used the type bits in the vma
struct to determine the type of memory being registered and just did the
right
On 11/29/10 11:10 AM, Steve Wise wrote:
On 11/24/2010 11:42 AM, Jason Gunthorpe wrote:
The last time this came up I said that the kernel side of ibv_reg_mr
should do the right thing for all types of memory that are mmap'd into
a process and I still think that is true. RDMA to device memory
On 11/16/10 1:39 PM, Or Gerlitz wrote:
Tom Tuckert...@ogc.us wrote:
This patch changes the bus mapping logic to avoid page_address() where necessary
Hi Tom,
Does when necessary comes to say that invocations of page_address
which remained in the code after this patch was applied are safe
Hi Bruce,
These fixes are ready for 2.6.37. They fix two bugs in the server-side
NFSRDMA transport.
Thanks,
Tom
---
Tom Tucker (2):
svcrdma: Cleanup DMA unmapping in error paths.
svcrdma: Change DMA mapping logic to avoid the page_address kernel API
net/sunrpc/xprtrdma
() where
necessary and converts all calls from ib_dma_map_single to ib_dma_map_page
in order to keep the map/unmap calls symmetric.
Signed-off-by: Tom Tucker t...@ogc.us
---
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 18 ---
net/sunrpc/xprtrdma/svc_rdma_sendto.c| 80
There are several error paths in the code that do not unmap DMA. This
patch adds calls to svc_rdma_unmap_dma to free these DMA contexts.
Signed-off-by: Tom Tucker t...@opengridcomputing.com
---
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c |1 +
net/sunrpc/xprtrdma/svc_rdma_sendto.c|2
Tziporet Koren wrote:
Hi Tom,
What is the purpose of this?
Is there a reason you did it only for mthca and not mlx4?
Tziporet
Hi Tziporet,
I just picked mthca arbitrarily to demonstrate how to do it. If people
like the verb, then I'll do it for all the devices, but I didn't want to
do
security policy would be implemented.
The ib_iomem_get service requires that any address provided by the service
be in a VMA owned by the process. This precludes providing 'random' addresses
to the service to acquire access to arbitrary memory locations.
---
Tom Tucker (4):
mthca: Add
From: Tom Tucker t...@opengridcomputing.com
Add a function pointer for the provider's reg_io_mr
method.
Signed-off-by: Tom Tucker t...@ogc.us
---
include/rdma/ib_verbs.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/rdma/ib_verbs.h b/include/rdma
From: Tom Tucker t...@opengridcomputing.com
Add the ibv_reg_io_mr and ibv_dereg_io_mr verbs.
Signed-off-by: Tom Tucker t...@ogc.us
---
include/infiniband/driver.h |6 ++
include/infiniband/verbs.h | 14 ++
src/verbs.c | 35
This patchset adds support for the new I/O memory registration verbs to
libmthca.
---
Tom Tucker (1):
libmthca: Add support for the reg_io_mr verb.
src/mthca-abi.h |4
src/mthca.c |2 ++
src/mthca.h |4
src/verbs.c | 50
From: Tom Tucker t...@opengridcomputing.com
Added support for the ibv_reg_io_mr and ibv_unreg_io_mr
verbs to the mthca ilbrary.
Signed-off-by: Tom Tucker t...@ogc.us
---
src/mthca-abi.h |4
src/mthca.c |2 ++
src/mthca.h |4
src/verbs.c | 50
On 7/29/10 1:22 PM, Ralph Campbell wrote:
On Thu, 2010-07-29 at 09:25 -0700, Tom Tucker wrote:
From: Tom Tuckert...@opengridcomputing.com
Add an ib_iomem_get service that converts a vma to an array of
physical addresses. This makes it easier for each device driver to
add support
is inappropriate in this regard.
On Thu, 2010-07-29 at 09:32 -0700, Tom Tucker wrote:
From: Tom Tuckert...@opengridcomputing.com
Add the ibv_reg_io_mr and ibv_dereg_io_mr verbs.
Signed-off-by: Tom Tuckert...@ogc.us
---
include/infiniband/driver.h |6 ++
include/infiniband/verbs.h | 14
On 7/29/10 3:41 PM, Jason Gunthorpe wrote:
On Thu, Jul 29, 2010 at 03:29:37PM -0500, Tom Tucker wrote:
Also, I'd like to see a strong defence of this new user space API
particularly:
1) Why can't this be done with the existing ibv_reg_mr, like huge
pages
On 7/29/10 11:25 AM, Tom Tucker wrote:
From: Tom Tuckert...@opengridcomputing.com
Add an ib_iomem_get service that converts a vma to an array of
physical addresses. This makes it easier for each device driver to
add support for the reg_io_mr provider method.
Signed-off-by: Tom Tuckert
On 7/29/10 5:57 PM, Jason Gunthorpe wrote:
You would need to modify ib_umem_get() to check for the VM_PFNMAP
flag and build the struct ib_umem similar to the proposed
ib_iomem_get(). However, the page reference counting/sharing issue
would need to be solved. I think there are kernel level
J. Bruce Fields wrote:
On Mon, Apr 05, 2010 at 10:55:12AM -0400, Chuck Lever wrote:
On 04/03/2010 09:27 AM, Tom Tucker wrote:
RPC6 requires that it be possible to create endpoints that listen
exclusively for IPv4 or IPv6 connection requests. This is not currently
supported by the RDMA
J. Bruce Fields wrote:
On Mon, Apr 05, 2010 at 12:16:18PM -0400, J. Bruce Fields wrote:
On Mon, Apr 05, 2010 at 10:50:16AM -0500, Tom Tucker wrote:
J. Bruce Fields wrote:
On Mon, Apr 05, 2010 at 10:55:12AM -0400, Chuck Lever wrote:
On 04/03/2010 09:27 AM, Tom
Roland Dreier wrote:
The write_ports code will fail both the INET4 and INET6 transport
creation if
the transport returns an error when PF_INET6 is specified. Some transports
that do not support INET6 return an error other than EAFNOSUPPORT.
That's the real bug. Any reason the
Sean Hefty wrote:
Sean, will you add this to the rdma_cm?
Not immediately because I lack the time to do it.
It would be really nice to share the kernel's port space code and remove the
port code in the rdma_cm.
LOL. Yes...yes it would. There is of course a Dragon to be slain.
that do not support INET6 return an error other than EAFNOSUPPORT. We should
allow communication on INET4 even if INET6 is not yet supported or fails
for some reason.
Signed-off-by: Tom Tucker t...@opengridcomputing.com
---
fs/nfsd/nfsctl.c |6 --
1 files changed, 4 insertions(+), 2 deletions
that do not support INET6 return an error other than EAFNOSUPPORT. We should
allow communication on INET4 even if INET6 is not yet supported or fails
for some reason.
Signed-off-by: Tom Tucker t...@opengridcomputing.com
---
fs/nfsd/nfsctl.c |6 --
1 files changed, 4 insertions(+), 2
David J. Wilder wrote:
Tom
I have been chasing an rnfs related Oops in svc_process(). I have found
the source of the Oops but I am not sure of my fix. I am seeing the
problem on ppc64, kernel 2.6.32, I have not tried other arch yet.
The source of the problem is in rdma_read_complete(), I am
Roland Dreier wrote:
Someone please make sure that a final patch with a full description gets
sent to the NFS guys for merging. Tom, are you going to handle this?
Yes, and I have several more in queue.
Tom
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body
Vu Pham wrote:
-Original Message-
From: Tom Tucker [mailto:t...@opengridcomputing.com]
Sent: Saturday, February 27, 2010 8:23 PM
To: Vu Pham
Cc: Roland Dreier; linux-rdma@vger.kernel.org; Mahesh Siddheshwar;
e...@lists.openfabrics.org
Subject: Re: [ewg] nfsrdma fails to write big file
Hi David:
That looks like a bug to me and it looks like what you propose is the
correct fix. My only reservation is that if you are correct then how did
this work at all without data corruption for large writes on x86_64?
I'm on the road right now, so I can't dig too deep until Wednesday,
Roland Dreier wrote:
+ /*
+* Add room for frmr register and invalidate WRs
+* Requests sometimes have two chunks, each chunk
+* requires to have different frmr. The safest
+* WRs required are max_send_wr *
...@lists.openfabrics.org [mailto:ewg-
boun...@lists.openfabrics.org] On Behalf Of Vu Pham
Sent: Monday, February 22, 2010 12:23 PM
To: Tom Tucker
Cc: linux-rdma@vger.kernel.org; Mahesh Siddheshwar;
e...@lists.openfabrics.org
Subject: Re: [ewg] nfsrdma fails to write big file,
Tom,
Some more info
: Monday, February 22, 2010 12:23 PM
To: Tom Tucker
Cc: linux-rdma@vger.kernel.org; Mahesh Siddheshwar;
e...@lists.openfabrics.org
Subject: Re: [ewg] nfsrdma fails to write big file,
Tom,
Some more info on the problem:
1. Running with memreg=4 (FMR) I can not reproduce the problem
2. I also see different
think the max was 6?
Thanks,
Tom
Tom Tucker wrote:
Vu,
Are you changing any of the default settings? For example rsize/wsize,
etc... I'd like to reproduce this problem if I can.
Thanks,
Tom
Vu Pham wrote:
Tom,
Did you make any change to have bonnie++, dd of a 10G file and vdbench
solution might be a different credit system,
however, I think that's a much more substantial change than we can
tackle at this point.
Tom
Tom Tucker wrote:
Vu,
Based on the mapping code, it looks to me like the worst case is
RPCRDMA_MAX_SEGS * 2 + 1 as the multiplier.
However, I think
Vu Pham wrote:
Setup:
1. linux nfsrdma client/server with OFED-1.5.1-20100217-0600, ConnectX2
QDR HCAs fw 2.7.8-6, RHEL 5.2.
2. Solaris nfsrdma server svn 130, ConnectX QDR HCA.
Running vdbench on 10g file or *dd if=/dev/zero of=10g_file bs=1M
count=1*, operation fail, connection get
vendor_err 244 byte_len 0 qp
81002a13ec00 ex src_qp wc_flags, 0 pkey_index
Any thoughts?
Tom
Tom Tucker wrote:
Tom Tucker wrote:
Tziporet Koren wrote:
On 2/15/2010 10:24 PM, Tom Tucker wrote:
Hello,
I am seeing some very strange behavior on my MLX4 adapters running 2.7
Tziporet Koren wrote:
On 2/15/2010 10:24 PM, Tom Tucker wrote:
Hello,
I am seeing some very strange behavior on my MLX4 adapters running 2.7
firmware and the latest OFED 1.5.1. Two systems are involved and each
have dual ported MTHCA DDR adapter and MLX4 adapters.
The scenario starts
Tziporet Koren wrote:
On 2/15/2010 10:24 PM, Tom Tucker wrote:
Hello,
I am seeing some very strange behavior on my MLX4 adapters running 2.7
firmware and the latest OFED 1.5.1. Two systems are involved and each
have dual ported MTHCA DDR adapter and MLX4 adapters.
The scenario starts
Tom Tucker wrote:
Tziporet Koren wrote:
On 2/15/2010 10:24 PM, Tom Tucker wrote:
Hello,
I am seeing some very strange behavior on my MLX4 adapters running 2.7
firmware and the latest OFED 1.5.1. Two systems are involved and each
have dual ported MTHCA DDR adapter and MLX4 adapters
see if there was traffic on the wire?
Tom
Tom Tucker wrote:
Tom Tucker wrote:
Tziporet Koren wrote:
On 2/15/2010 10:24 PM, Tom Tucker wrote:
Hello,
I am seeing some very strange behavior on my MLX4 adapters running 2.7
firmware and the latest OFED 1.5.1. Two systems are involved and each
62 matches
Mail list logo
