On 4/12/2021 6:48 PM, Jason Gunthorpe wrote:
On Mon, Apr 12, 2021 at 04:20:47PM -0400, Tom Talpey wrote:
So the issue is only in testing all the providers and platforms,
to be sure this new behavior isn't tickling anything that went
unnoticed all along, because no RDMA provider ever issu
On 4/12/2021 2:32 PM, Haakon Bugge wrote:
On 10 Apr 2021, at 15:30, David Laight wrote:
From: Tom Talpey
Sent: 09 April 2021 18:49
On 4/9/2021 12:27 PM, Haakon Bugge wrote:
On 9 Apr 2021, at 17:32, Tom Talpey wrote:
On 4/9/2021 10:45 AM, Chuck Lever III wrote:
On Apr 9, 2021, at 10
On 4/9/2021 12:27 PM, Haakon Bugge wrote:
On 9 Apr 2021, at 17:32, Tom Talpey wrote:
On 4/9/2021 10:45 AM, Chuck Lever III wrote:
On Apr 9, 2021, at 10:26 AM, Tom Talpey wrote:
On 4/6/2021 7:49 AM, Jason Gunthorpe wrote:
On Mon, Apr 05, 2021 at 11:42:31PM +, Chuck Lever III wrote
On 4/9/2021 12:40 PM, Jason Gunthorpe wrote:
On Fri, Apr 09, 2021 at 10:26:21AM -0400, Tom Talpey wrote:
My belief is that the biggest risk is from situations where completions
are batched, and therefore polling is used to detect them without
interrupts (which explicitly).
We don't do
On 4/9/2021 10:45 AM, Chuck Lever III wrote:
On Apr 9, 2021, at 10:26 AM, Tom Talpey wrote:
On 4/6/2021 7:49 AM, Jason Gunthorpe wrote:
On Mon, Apr 05, 2021 at 11:42:31PM +, Chuck Lever III wrote:
We need to get a better idea what correctness testing has been done,
and whether
On 4/6/2021 7:49 AM, Jason Gunthorpe wrote:
On Mon, Apr 05, 2021 at 11:42:31PM +, Chuck Lever III wrote:
We need to get a better idea what correctness testing has been done,
and whether positive correctness testing results can be replicated
on a variety of platforms.
RO has been rolling
On 4/5/2021 1:23 AM, Leon Romanovsky wrote:
From: Avihai Horon
Enable Relaxed Ordering in __ib_alloc_pd() allocation of the
local_dma_lkey.
This will take effect only for devices that don't pre-allocate the lkey
but allocate it per PD allocation.
Signed-off-by: Avihai Horon
Reviewed-by: Mich
On 4/5/2021 10:08 AM, Leon Romanovsky wrote:
On Mon, Apr 05, 2021 at 03:41:15PM +0200, Christoph Hellwig wrote:
On Mon, Apr 05, 2021 at 08:23:54AM +0300, Leon Romanovsky wrote:
From: Leon Romanovsky
>From Avihai,
Relaxed Ordering is a PCIe mechanism that relaxes the strict ordering
imposed o
On 4/1/2021 9:36 AM, Namjae Jeon wrote:
2021-04-01 22:14 GMT+09:00, Ralph Boehme :
Am 4/1/21 um 2:59 PM schrieb Namjae Jeon:
2021-04-01 21:50 GMT+09:00, Ralph Boehme :
fwiw, while at it what about renaming everything that still references
"cifs" to "smb" ? This is not the 90's... :)
It is als
LGTM feel free to add
Reviewed-By: Tom Talpey
On 3/19/2021 9:57 AM, Vincent Whitchurch wrote:
Make SMB2 not print out an error when an oplock break is received for an
unknown handle, similar to SMB1. The debug message which is printed for
these unknown handles may also be misleading, so fix
;in review"? Both threads are active on the
mailing list. If you or others have something to discuss, please
post it and don't leave us out of the discussion.
Tom.
Regards,
Rohith
On Tue, Mar 16, 2021 at 9:33 PM Tom Talpey wrote:
On 3/16/2021 8:48 AM, Vincent Whitchurch via s
On 3/16/2021 8:48 AM, Vincent Whitchurch via samba-technical wrote:
Make SMB2 not print out an error when an oplock break is received for an
unknown handle, similar to SMB1. The SMB2 lease break path is not
affected by this patch.
Without this, a program which writes to a file from one thread,
On 3/12/2021 6:49 AM, Vincent Whitchurch wrote:
On Tue, Mar 09, 2021 at 04:29:14PM +0100, Steve French wrote:
On Tue, Mar 9, 2021, 07:42 Vincent Whitchurch via samba-technical
mailto:samba-techni...@lists.samba.org>> wrote:
Thank you for the suggestions. In my case, I've only received some
re
On 2/25/2021 4:26 AM, Jiapeng Chong wrote:
Fix the following coccicheck warnings:
./drivers/infiniband/hw/hfi1/tid_rdma.c:1118:36-41: WARNING: conversion
to bool not needed here.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/infiniband/hw/hfi1/tid_rdma.c | 2 +-
1 file
On 3/19/2019 3:45 PM, Jerome Glisse wrote:
On Tue, Mar 19, 2019 at 03:43:44PM -0500, Tom Talpey wrote:
On 3/19/2019 4:03 AM, Ira Weiny wrote:
On Tue, Mar 19, 2019 at 04:36:44PM +0100, Jan Kara wrote:
On Tue 19-03-19 17:29:18, Kirill A. Shutemov wrote:
On Tue, Mar 19, 2019 at 10:14:16AM -0400
On 3/19/2019 4:03 AM, Ira Weiny wrote:
On Tue, Mar 19, 2019 at 04:36:44PM +0100, Jan Kara wrote:
On Tue 19-03-19 17:29:18, Kirill A. Shutemov wrote:
On Tue, Mar 19, 2019 at 10:14:16AM -0400, Jerome Glisse wrote:
On Tue, Mar 19, 2019 at 09:47:24AM -0400, Jerome Glisse wrote:
On Tue, Mar 19, 20
On 2/7/2019 11:57 AM, Ira Weiny wrote:
On Thu, Feb 07, 2019 at 10:28:05AM -0500, Tom Talpey wrote:
On 2/7/2019 10:04 AM, Chuck Lever wrote:
On Feb 7, 2019, at 12:23 AM, Jason Gunthorpe wrote:
On Thu, Feb 07, 2019 at 02:52:58PM +1100, Dave Chinner wrote:
Requiring ODP capable hardware
On 2/7/2019 10:37 AM, Doug Ledford wrote:
On Thu, 2019-02-07 at 10:28 -0500, Tom Talpey wrote:
On 2/7/2019 10:04 AM, Chuck Lever wrote:
On Feb 7, 2019, at 12:23 AM, Jason Gunthorpe wrote:
On Thu, Feb 07, 2019 at 02:52:58PM +1100, Dave Chinner wrote:
Requiring ODP capable hardware and
On 2/7/2019 10:04 AM, Chuck Lever wrote:
On Feb 7, 2019, at 12:23 AM, Jason Gunthorpe wrote:
On Thu, Feb 07, 2019 at 02:52:58PM +1100, Dave Chinner wrote:
Requiring ODP capable hardware and applications that control RDMA
access to use file leases and be able to cancel/recall client side
de
On 2/5/2019 3:22 AM, John Hubbard wrote:
On 2/4/19 5:41 PM, Tom Talpey wrote:
On 2/4/2019 12:21 AM, john.hubb...@gmail.com wrote:
From: John Hubbard
Performance: here is an fio run on an NVMe drive, using this for the fio
configuration file:
[reader]
direct=1
ioengine=libaio
On 2/4/2019 12:21 AM, john.hubb...@gmail.com wrote:
From: John Hubbard
Performance: here is an fio run on an NVMe drive, using this for the fio
configuration file:
[reader]
direct=1
ioengine=libaio
blocksize=4096
size=1g
numjobs=1
rw=read
iodepth=64
re
On 12/13/2018 10:18 AM, Jerome Glisse wrote:
On Thu, Dec 13, 2018 at 09:51:18AM -0500, Tom Talpey wrote:
On 12/13/2018 9:18 AM, Jerome Glisse wrote:
On Thu, Dec 13, 2018 at 08:40:49AM -0500, Tom Talpey wrote:
On 12/13/2018 7:43 AM, Jerome Glisse wrote:
On Wed, Dec 12, 2018 at 08:20:43PM
On 12/13/2018 9:18 AM, Jerome Glisse wrote:
On Thu, Dec 13, 2018 at 08:40:49AM -0500, Tom Talpey wrote:
On 12/13/2018 7:43 AM, Jerome Glisse wrote:
On Wed, Dec 12, 2018 at 08:20:43PM -0700, Jason Gunthorpe wrote:
On Wed, Dec 12, 2018 at 07:01:09PM -0500, Jerome Glisse wrote:
On Wed, Dec 12
On 12/13/2018 7:43 AM, Jerome Glisse wrote:
On Wed, Dec 12, 2018 at 08:20:43PM -0700, Jason Gunthorpe wrote:
On Wed, Dec 12, 2018 at 07:01:09PM -0500, Jerome Glisse wrote:
On Wed, Dec 12, 2018 at 04:37:03PM -0700, Jason Gunthorpe wrote:
On Wed, Dec 12, 2018 at 04:53:49PM -0500, Jerome Glisse w
On 11/29/2018 10:00 PM, John Hubbard wrote:
On 11/29/18 6:30 PM, Tom Talpey wrote:
On 11/29/2018 9:21 PM, John Hubbard wrote:
On 11/29/18 6:18 PM, Tom Talpey wrote:
On 11/29/2018 8:39 PM, John Hubbard wrote:
On 11/28/18 5:59 AM, Tom Talpey wrote:
On 11/27/2018 9:52 PM, John Hubbard wrote
On 11/29/2018 9:21 PM, John Hubbard wrote:
On 11/29/18 6:18 PM, Tom Talpey wrote:
On 11/29/2018 8:39 PM, John Hubbard wrote:
On 11/28/18 5:59 AM, Tom Talpey wrote:
On 11/27/2018 9:52 PM, John Hubbard wrote:
On 11/27/18 5:21 PM, Tom Talpey wrote:
On 11/21/2018 5:06 PM, John Hubbard wrote
On 11/29/2018 8:39 PM, John Hubbard wrote:
On 11/28/18 5:59 AM, Tom Talpey wrote:
On 11/27/2018 9:52 PM, John Hubbard wrote:
On 11/27/18 5:21 PM, Tom Talpey wrote:
On 11/21/2018 5:06 PM, John Hubbard wrote:
On 11/21/18 8:49 AM, Tom Talpey wrote:
On 11/21/2018 1:09 AM, John Hubbard wrote
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org On
> Behalf Of Long Li
> Sent: Thursday, November 29, 2018 4:30 PM
> To: Pavel Shilovsky
> Cc: Steve French ; linux-cifs ;
> samba-technical ; Kernel Mailing List
>
> Subject: RE: [Patch v4 2/3] CIFS: Add support for direct I/
On 11/27/2018 9:52 PM, John Hubbard wrote:
On 11/27/18 5:21 PM, Tom Talpey wrote:
On 11/21/2018 5:06 PM, John Hubbard wrote:
On 11/21/18 8:49 AM, Tom Talpey wrote:
On 11/21/2018 1:09 AM, John Hubbard wrote:
On 11/19/18 10:57 AM, Tom Talpey wrote:
[...]
What I'd really like to see is
On 11/21/2018 5:06 PM, John Hubbard wrote:
On 11/21/18 8:49 AM, Tom Talpey wrote:
On 11/21/2018 1:09 AM, John Hubbard wrote:
On 11/19/18 10:57 AM, Tom Talpey wrote:
~14000 4KB read IOPS is really, really low for an NVMe disk.
Yes, but Jan Kara's original config file for fio is *intende
On 11/21/2018 1:09 AM, John Hubbard wrote:
On 11/19/18 10:57 AM, Tom Talpey wrote:
~14000 4KB read IOPS is really, really low for an NVMe disk.
Yes, but Jan Kara's original config file for fio is *intended* to highlight
the get_user_pages/put_user_pages changes. It was *not* intended t
John, thanks for the discussion at LPC. One of the concerns we
raised however was the performance test. The numbers below are
rather obviously tainted. I think we need to get a better baseline
before concluding anything...
Here's my main concern:
On 11/10/2018 3:50 AM, john.hubb...@gmail.com wro
On 9/23/2018 2:24 PM, Stefan Metzmacher wrote:
Hi Tom,
I just tested that setting:
mr->iova &= (PAGE_SIZE - 1);
mr->iova |= 0x;
after the ib_map_mr_sg() and before doing the IB_WR_REG_MR, seems to
work.
Good! As you know, we were concerned about it after seeing that
the ib_d
On 9/21/2018 8:56 PM, Stefan Metzmacher wrote:
Hi,
+ req->Channel = SMB2_CHANNEL_RDMA_V1_INVALIDATE;
+ if (need_invalidate)
+ req->Channel = SMB2_CHANNEL_RDMA_V1;
+ req->ReadChannelInfoOffset =
+ offsetof(struct smb2_read_plain_req, Buffer);
+ r
Replying to a very old message, but it's something we
discussed today at the IOLab event so to capture it:
On 11/7/2017 12:55 AM, Long Li wrote:
From: Long Li
---
fs/cifs/file.c| 17 +++--
fs/cifs/smb2pdu.c | 45 -
2 files changed
On 6/25/2018 5:01 PM, Jason Gunthorpe wrote:
On Sat, Jun 23, 2018 at 09:50:20PM -0400, Tom Talpey wrote:
On 5/30/2018 3:47 PM, Long Li wrote:
From: Long Li
Add a function to allocate rdata without allocating pages for data
transfer. This gives the caller an option to pass a number of pages
On 6/26/2018 12:39 AM, Long Li wrote:
Subject: Re: [Patch v2 14/15] CIFS: Add support for direct I/O write
On 5/30/2018 3:48 PM, Long Li wrote:
From: Long Li
Implement the function for direct I/O write. It doesn't support AIO,
which will be implemented in a follow up patch.
Signed-off-by: Lo
On 6/25/2018 5:14 PM, Long Li wrote:
Subject: Re: [Patch v2 06/15] CIFS: Introduce helper function to get page
offset and length in smb_rqst
On 5/30/2018 3:47 PM, Long Li wrote:
From: Long Li
Introduce a function rqst_page_get_length to return the page offset
and length for a given page in sm
On 5/30/2018 3:48 PM, Long Li wrote:
From: Long Li
Implement the function for direct I/O write. It doesn't support AIO, which
will be implemented in a follow up patch.
Signed-off-by: Long Li
---
fs/cifs/cifsfs.h | 1 +
fs/cifs/file.c | 165 ++
On 5/30/2018 3:48 PM, Long Li wrote:
From: Long Li
Implement the function for direct I/O read. It doesn't support AIO, which
will be implemented in a follow up patch.
Signed-off-by: Long Li
---
fs/cifs/cifsfs.h | 1 +
fs/cifs/file.c | 149
On 5/30/2018 3:48 PM, Long Li wrote:
From: Long Li
Encryption function needs to read data starting page offset from input
buffer.
This doesn't affect decryption path since it allocates its own page
buffers.
Signed-off-by: Long Li
---
fs/cifs/smb2ops.c | 20 +---
1 file cha
On 5/30/2018 3:48 PM, Long Li wrote:
From: Long Li
When calculating signature for the packet, it needs to read into the
correct page offset for the data.
Signed-off-by: Long Li
---
fs/cifs/cifsencrypt.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/cifs/ci
On 5/30/2018 3:48 PM, Long Li wrote:
From: Long Li
Change code to pass the correct page offset during memory registration for
RDMA read/write.
Signed-off-by: Long Li
---
fs/cifs/smb2pdu.c | 18 -
fs/cifs/smbdirect.c | 76 +++--
On 5/30/2018 3:48 PM, Long Li wrote:
From: Long Li
RDMA recv function needs to place data to the correct place starting at
page offset.
Signed-off-by: Long Li
---
fs/cifs/smbdirect.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/fs/cifs/smbdirect.c
On 5/30/2018 3:48 PM, Long Li wrote:
From: Long Li
The RDMA send function needs to look at offset in the request pages, and
send data starting from there.
Signed-off-by: Long Li
---
fs/cifs/smbdirect.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff
On 5/30/2018 3:47 PM, Long Li wrote:
From: Long Li
Introduce a function rqst_page_get_length to return the page offset and
length for a given page in smb_rqst. This function is to be used by
following patches.
Signed-off-by: Long Li
---
fs/cifs/cifsproto.h | 3 +++
fs/cifs/misc.c | 1
On 5/30/2018 3:47 PM, Long Li wrote:
From: Long Li
It's possible that the page offset is non-zero in the pages in a request,
change the function to calculate the correct data buffer length.
Signed-off-by: Long Li
---
fs/cifs/transport.c | 20 +---
1 file changed, 17 inserti
On 5/30/2018 3:47 PM, Long Li wrote:
From: Long Li
Add a function to allocate wdata without allocating pages for data
transfer. This gives the caller an option to pass a number of pages that
point to the data buffer to write to.
wdata is reponsible for free those pages after it's done.
Same
On 5/30/2018 3:47 PM, Long Li wrote:
From: Long Li
With offset defined in rdata, transport functions need to look at this
offset when reading data into the correct places in pages.
Signed-off-by: Long Li
---
fs/cifs/cifsproto.h | 4 +++-
fs/cifs/connect.c | 5 +++--
fs/cifs/file.c
On 5/30/2018 3:47 PM, Long Li wrote:
From: Long Li
Add a function to allocate rdata without allocating pages for data
transfer. This gives the caller an option to pass a number of pages
that point to the data buffer.
rdata is still reponsible for free those pages after it's done.
"Caller" is
On 5/18/2018 1:58 PM, Long Li wrote:
Subject: Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option
On Fri, May 18, 2018 at 12:00 PM, Long Li via samba-technical wrote:
Subject: Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option
On Thu, May 17, 2018 at 05:22:14PM -0700, Long Li w
On 5/17/2018 5:22 PM, Long Li wrote:
From: Long Li
There's a typo "recognize" in the patch title
When doing RDMA send, the offset needs to be checked as data may start in an
offset
in the 1st page.
Doesn't this patch alter the generic smb2pdu.c code too? I think this
should note "any" se
On 5/17/2018 11:03 PM, Long Li wrote:
Subject: Re: [RFC PATCH 00/09] Implement direct user I/O interfaces for
RDMA
On 5/17/2018 8:22 PM, Long Li wrote:
From: Long Li
This patchset implements direct user I/O through RDMA.
In normal code path (even with cache=none), CIFS copies I/O data from
u
On 5/17/2018 5:22 PM, Long Li wrote:
From: Long Li
When using direct pages from user space, there is no need to allocate pages.
Just ping those user pages for RDMA.
Did you mean "pin" those user pages? If so, where does that pinning
occur, it's not in this patch.
Perhaps this should just sa
On 5/17/2018 8:22 PM, Long Li wrote:
From: Long Li
This patchset implements direct user I/O through RDMA.
In normal code path (even with cache=none), CIFS copies I/O data from
user-space to kernel-space for security reasons.
With this patchset, a new mounting option is introduced to have CIFS
en worse, this
> incorrect address can't be detected by ib_dma_mapping_error. Sending data
> from this address to hardware will not fail, but the remote peer will get
> junk data.
>
> Fix this by allocating the request on the heap in smb3_validate_negotiate.
>
Looks good.
Reviewed-By: Tom Talpey
On 4/20/2018 2:41 PM, Long Li wrote:
Subject: Re: [Patch v4] cifs: Allocate validate negotiation request through
kmalloc
Looks good, but I have two possibly style-related comments.
On 4/19/2018 5:38 PM, Long Li wrote:
From: Long Li
The data buffer allocated on the stack can't be DMA'ed,
ib_d
Looks good, but I have two possibly style-related comments.
On 4/19/2018 5:38 PM, Long Li wrote:
From: Long Li
The data buffer allocated on the stack can't be DMA'ed, ib_dma_map_page will
return an invalid DMA address for a buffer on stack. Even worse, this
incorrect address can't be detected
On 4/18/2018 1:16 PM, Long Li wrote:
Subject: Re: [Patch v3 2/6] cifs: Allocate validate negotiation request through
kmalloc
Two comments.
On 4/17/2018 8:33 PM, Long Li wrote:
From: Long Li
The data buffer allocated on the stack can't be DMA'ed, and hence
can't send through RDMA via SMB Dire
On 4/18/2018 1:11 PM, Long Li wrote:
Subject: Re: [Patch v3 2/6] cifs: Allocate validate negotiation request through
kmalloc
On 4/18/2018 9:08 AM, David Laight wrote:
From: Tom Talpey
Sent: 18 April 2018 12:32
...
On 4/17/2018 8:33 PM, Long Li wrote:
From: Long Li
The data buffer
On 4/18/2018 9:08 AM, David Laight wrote:
From: Tom Talpey
Sent: 18 April 2018 12:32
...
On 4/17/2018 8:33 PM, Long Li wrote:
From: Long Li
The data buffer allocated on the stack can't be DMA'ed, and hence can't send
through RDMA via SMB Direct.
This comment is confusing.
Two comments.
On 4/17/2018 8:33 PM, Long Li wrote:
From: Long Li
The data buffer allocated on the stack can't be DMA'ed, and hence can't send
through RDMA via SMB Direct.
This comment is confusing. Any registered memory can be DMA'd, need to
state the reason for the choice here more clearly.
teve French
> > > >
> > > > Subject: RE: [Patch v5 08/21] CIFS: SMBD: Upper layer reconnects to
> > > > SMB Direct session
> > > >
> > > > > -Original Message-
> > > > > From: Matthew Wilcox
> > >
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Monday, August 14, 2017 7:30 PM
> To: Tom Talpey ; Steve French ;
> linux-c...@vger.kernel.org; samba-techni...@lists.samba
> -Original Message-
> From: Long Li
> Sent: Monday, August 14, 2017 7:25 PM
> To: Tom Talpey ; Steve French ;
> linux-c...@vger.kernel.org; samba-techni...@lists.samba.org; linux-
> ker...@vger.kernel.org
> Subject: RE: [[PATCH v1] 21/37] [CIFS] SMBD: Implement A
> -Original Message-
> From: Long Li
> Sent: Monday, August 14, 2017 6:51 PM
> To: Tom Talpey ; Christoph Hellwig
>
> Cc: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Subject: RE: [[PATCH v1] 16/37]
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:11 PM
> To: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: L
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:11 PM
> To: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: L
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:11 PM
> To: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: L
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:11 PM
> To: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: L
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:11 PM
> To: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: L
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:11 PM
> To: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: L
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:11 PM
> To: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: L
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:11 PM
> To: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: L
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:10 PM
> To: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: L
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:10 PM
> To: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: L
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:10 PM
> To: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: L
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:10 PM
> To: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: L
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:10 PM
> To: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: L
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Christoph Hellwig
> Sent: Sunday, August 13, 2017 6:12 AM
> To: Long Li
> Cc: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Wednesday, August 2, 2017 4:10 PM
> To: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@vger.kernel.org
> Cc: L
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Long Li
> Sent: Monday, August 14, 2017 2:20 PM
> To: Christoph Hellwig
> Cc: Steve French ; linux-c...@vger.kernel.org; samba-
> techni...@lists.samba.org; linux-kernel@
On 11/24/2015 2:03 AM, Jason Gunthorpe wrote:
On Mon, Nov 23, 2015 at 06:35:28PM -0800, Caitlin Bestler wrote:
Are there actual HCAs that make this mistake?
All IB HCAs have this behavior and require apps to see a send CQ
completion before making any statements about the state of the send Q
or
On 11/23/2015 7:00 PM, Jason Gunthorpe wrote:
On Mon, Nov 23, 2015 at 03:30:42PM -0800, Caitlin Bestler wrote:
The receive completion can be safely assumed to indicate transmit
completion over a reliable connection unless your peer has gone
completely bonkers and is replying to a com
On 4/27/2015 6:24 PM, Doug Ledford wrote:
On Mon, 2015-04-27 at 17:53 -0700, Tom Talpey wrote:
On 4/27/2015 5:36 PM, Doug Ledford wrote:
On Mon, 2015-04-27 at 17:16 -0700, Tom Talpey wrote:
On 4/27/2015 2:52 PM, ira.weiny wrote:
On Mon, Apr 27, 2015 at 09:39:05AM +0200, Michael Wang wrote
On 4/27/2015 5:36 PM, Doug Ledford wrote:
On Mon, 2015-04-27 at 17:16 -0700, Tom Talpey wrote:
On 4/27/2015 2:52 PM, ira.weiny wrote:
On Mon, Apr 27, 2015 at 09:39:05AM +0200, Michael Wang wrote:
On 04/24/2015 05:12 PM, Liran Liss wrote:
[snip]
Like:
enum rdma_protocol
On 4/27/2015 2:52 PM, ira.weiny wrote:
On Mon, Apr 27, 2015 at 09:39:05AM +0200, Michael Wang wrote:
On 04/24/2015 05:12 PM, Liran Liss wrote:
From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
[snip]
a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h index
65994a1..d54f91e 100644
On 4/24/2015 10:35 AM, Michael Wang wrote:
On 04/24/2015 04:29 PM, Tom Talpey wrote:
On 4/24/2015 8:23 AM, Michael Wang wrote:
[snip]
+static enum rdma_transport_type
+mlx5_ib_query_transport(struct ib_device *device, u8 port_num)
+{
+return RDMA_TRANSPORT_IB;
+}
+
Just noticed that
On 4/24/2015 8:23 AM, Michael Wang wrote:
Add new callback query_transport() and implement for each HW.
Mapping List:
node-type link-layer old-transport new-transport
...
mlx4IB_CA IB/ETH IB IB/IBOE
mlx5IB_CA
On 4/16/2015 11:22 AM, Michael Wang wrote:
On 04/16/2015 04:31 PM, Hefty, Sean wrote:
This is equivalent to today where the checks are per node rather than
per port.
Should all checks here be port 1 based or only certain ones like listen
? For example, in connect/reject/disconnect, don't we a
On 4/10/2015 5:06 PM, ira.weiny wrote:
On Fri, Apr 10, 2015 at 01:17:23PM -0600, Jason Gunthorpe wrote:
...
So trying to sum up.
Have we settled on the following "capabilities"? Helper function names aside.
/* legacy to communicate to userspace */
RDMA_LINK_LAYER_IB = 0x0001,
On 4/8/2015 4:10 PM, Jason Gunthorpe wrote:
On Wed, Apr 08, 2015 at 02:29:46PM -0400, Doug Ledford wrote:
...
rdma_port_get_read_sge(dev, port)
{
if (rdma_transport_is_iwarp)
return 1;
return dev->port[port]->max_sge;
}
Hum, that is nice, but it doesn't quite
On 4/7/2015 8:25 AM, Michael Wang wrote:
Mapping List:
node-type link-layer old-transport new-transport
nes RNICETH IWARP IWARP
amso1100RNICETH IWARP IWARP
cxgb3 RNIC
On 4/7/2015 8:34 AM, Michael Wang wrote:
/**
+ * cap_read_multi_sge - Check if the port of device has the capability
+ * RDMA Read Multiple Scatter-Gather Entries.
+ *
+ * @device: Device to be checked
+ * @port_num: Port number of the device
+ *
+ * Return 0 when port of the device don't suppo
On 3/31/2015 7:41 AM, Michael Wang wrote:
Hi, Tom
Thanks for the comments :-)
On 03/31/2015 01:19 PM, Tom Talpey wrote:
[oops - repeating my reply with full cc's]
[snip]
Actually I'm thinking about Doug's idea to use rdma_transport_is_XX()
instead of the current basic h
On 3/31/2015 3:39 AM, Michael Wang wrote:
On 03/31/2015 12:35 AM, Jason Gunthorpe wrote:
On Mon, Mar 30, 2015 at 05:10:12PM +0200, Michael Wang wrote:
I found that actually we don't have to touch this one which
only used by HW driver currently.
I'm having a hard time understanding this, the co
> -Original Message-
> From: samba-technical-boun...@lists.samba.org [mailto:samba-technical-
> boun...@lists.samba.org] On Behalf Of Stefan (metze) Metzmacher
> Sent: Wednesday, February 27, 2013 7:16 PM
> To: Jeff Layton
> Cc: Steve French; Dave Chiluk; samba-techni...@lists.samba.org; li
> -Original Message-
> From: linux-cifs-ow...@vger.kernel.org [mailto:linux-cifs-
> ow...@vger.kernel.org] On Behalf Of Dave Chiluk
> Sent: Wednesday, February 27, 2013 5:44 PM
> To: Steve French
> Cc: Jeff Layton; Stefan (metze) Metzmacher; Dave Chiluk; Steve French;
> linux-c...@vger.kern
> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Tuesday, January 8, 2013 1:10 PM
> To: J. Bruce Fields
> Cc: Trond Myklebust; David S. Miller; linux-...@vger.kernel.org;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; Tom Tucker;
> s
99 matches
Mail list logo
