Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs

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 issued RO

Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs

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

Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs

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

Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs

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

Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs

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

Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs

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

Re: [PATCH rdma-next 02/10] RDMA/core: Enable Relaxed Ordering in __ib_alloc_pd()

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:

Re: [PATCH rdma-next 00/10] Enable relaxed ordering for ULPs

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

Re: [Linux-cifsd-devel] [PATCH] cifsd: use kfree to free memory allocated by kzalloc

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

Re: [PATCH v3] cifs: Silently ignore unknown oplock break handle

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

Re: [PATCH v2] cifs: Silently ignore unknown oplock break handle

eview"? 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 samba-techn

Re: [PATCH v2] cifs: Silently ignore unknown oplock break handle

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,

Re: [PATCH] CIFS: Prevent error log on spurious oplock break

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: [PATCH] RDMA/hw/hfi1/tid_rdma: remove unnecessary conversion to bool

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

Re: [PATCH v4 1/1] mm: introduce put_user_page*(), placeholder versions

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

Re: [PATCH v4 1/1] mm: introduce put_user_page*(), placeholder versions

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,

Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA

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

Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA

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

Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA

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

Re: [PATCH 0/6] RFC v2: mm: gup/dma tracking

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

Re: [PATCH 0/6] RFC v2: mm: gup/dma tracking

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: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

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

Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

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

Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

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

Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages

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

Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages

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

Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages

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

Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages

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

Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages

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

Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages

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

RE: [Patch v4 2/3] CIFS: Add support for direct I/O write

> -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

RE: [Patch v4 2/3] CIFS: Add support for direct I/O write

> -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

Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages

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 to go

Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages

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 to go

Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages

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 *intended

Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages

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 *intended

Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages

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 to get

Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages

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 to get

Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages

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

Re: [PATCH v2 0/6] RFC: gup+dma: tracking dma-pinned pages

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

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

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

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

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

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

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); +   

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

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); +   

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

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

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

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

Re: [Patch v2 02/15] CIFS: Add support for direct pages in rdata

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

Re: [Patch v2 02/15] CIFS: Add support for direct pages in rdata

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

Re: [Patch v2 14/15] CIFS: Add support for direct I/O write

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:

Re: [Patch v2 14/15] CIFS: Add support for direct I/O write

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:

Re: [Patch v2 06/15] CIFS: Introduce helper function to get page offset and length in smb_rqst

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

Re: [Patch v2 06/15] CIFS: Introduce helper function to get page offset and length in smb_rqst

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

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: Long Li --- fs/cifs/cifsfs.h | 1 + fs/cifs/file.c | 165

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: Long Li --- fs/cifs/cifsfs.h | 1 + fs/cifs/file.c | 165

Re: [Patch v2 13/15] CIFS: Add support for direct I/O read

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

Re: [Patch v2 13/15] CIFS: Add support for direct I/O read

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

Re: [Patch v2 12/15] CIFS: Pass page offset for encrypting

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

Re: [Patch v2 12/15] CIFS: Pass page offset for encrypting

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

Re: [Patch v2 11/15] CIFS: Pass page offset for calculating signature

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

Re: [Patch v2 11/15] CIFS: Pass page offset for calculating signature

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

Re: [Patch v2 10/15] CIFS: SMBD: Support page offset in memory registration

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 +++--

Re: [Patch v2 10/15] CIFS: SMBD: Support page offset in memory registration

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 +++--

Re: [Patch v2 09/15] CIFS: SMBD: Support page offset in RDMA recv

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

Re: [Patch v2 09/15] CIFS: SMBD: Support page offset in RDMA recv

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

Re: [Patch v2 08/15] CIFS: SMBD: Support page offset in RDMA send

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(-)

Re: [Patch v2 08/15] CIFS: SMBD: Support page offset in RDMA send

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(-)

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 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 |

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 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 |

Re: [Patch v2 05/15] CIFS: Calculate the correct request length based on page offset and tail size

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

Re: [Patch v2 05/15] CIFS: Calculate the correct request length based on page offset and tail size

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

Re: [Patch v2 04/15] CIFS: Add support for direct pages in wdata

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

Re: [Patch v2 04/15] CIFS: Add support for direct pages in wdata

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

Re: [Patch v2 03/15] CIFS: Use offset when reading pages

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

Re: [Patch v2 03/15] CIFS: Use offset when reading pages

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

Re: [Patch v2 02/15] CIFS: Add support for direct pages in rdata

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"

Re: [Patch v2 02/15] CIFS: Add support for direct pages in rdata

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"

Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option

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

Re: [RFC PATCH 09/09] Introduce cache=rdma moutning option

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

Re: [RFC PATCH 05/09] Change RDMA send to regonize page offset in the 1st page

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

Re: [RFC PATCH 05/09] Change RDMA send to regonize page offset in the 1st page

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"

Re: [RFC PATCH 00/09] Implement direct user I/O interfaces for RDMA

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

Re: [RFC PATCH 00/09] Implement direct user I/O interfaces for RDMA

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

Re: [RFC PATCH 02/09] Change wdata alloc to support direct pages

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.

Re: [RFC PATCH 02/09] Change wdata alloc to support direct pages

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

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 user-space to kernel-space for security reasons. With this patchset, a new mounting option is

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 user-space to kernel-space for security reasons. With this patchset, a new mounting option is introduced to have

RE: [PATCH v5] cifs: Allocate validate negotiation request through kmalloc

> > Fix this by allocating the request on the heap in smb3_validate_negotiate. > Looks good. Reviewed-By: Tom Talpey <ttal...@microsoft.com>

RE: [PATCH v5] cifs: Allocate validate negotiation request through kmalloc

e, 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

Re: [Patch v4] cifs: Allocate validate negotiation request through kmalloc

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

Re: [Patch v4] cifs: Allocate validate negotiation request through kmalloc

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,

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_dma_map_page will return an invalid DMA address for a buffer on stack. Even worse, this incorrect

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_dma_map_page will return an invalid DMA address for a buffer on stack. Even worse, this incorrect address can't be detected

Re: [Patch v3 2/6] cifs: Allocate validate negotiation request through kmalloc

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

Re: [Patch v3 2/6] cifs: Allocate validate negotiation request through kmalloc

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

Re: [Patch v3 2/6] cifs: Allocate validate negotiation request through kmalloc

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 <lon...@microsoft.

Re: [Patch v3 2/6] cifs: Allocate validate negotiation request through kmalloc

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

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 <lon...@microsoft.com> The data buffer allocated on the stack can't be DMA'ed, and hence can't send through RDMA via SMB Direct. This c

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 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

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 Direct. This comment is confusing. Any registered memory can be DMA'd, need to state the reason for the

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 Direct. This comment is confusing. Any registered memory can be DMA'd, need to state the reason for the choice here more

  1   2   >