Re: IB/core: Use GID table in AH creation and dmac resolution

2015-11-03 Thread Somnath Kotur
Thanks Dan and Matan. We will take a look and revert on this Thanks Som On Wed, Nov 4, 2015 at 9:31 AM, Somnath Kotur wrote: > Thanks Dan and Matan. > > We will take a look and revert on this > > Thanks > Som > > On Tue, Nov 3, 2015 at 7:14 PM, Matan Barak wrote: >> >> >> >> On 11/3/2015 3:11

Re: [PATCH 4/7] IB/srp: Fix a potential queue overflow in an error path

2015-11-03 Thread Christoph Hellwig
On Tue, Nov 03, 2015 at 12:50:59PM -0800, Bart Van Assche wrote: > Such a check wouldn't be that simple because the only way to perform such a > check is either by doubling the number of ib_map_mr_sg() calls or by > performing additional memory allocations. The other option woud be to disallow gap

Re: [PATCH 4/7] IB/srp: Fix a potential queue overflow in an error path

2015-11-03 Thread Bart Van Assche
On 11/03/2015 12:13 PM, Sagi Grimberg wrote: Sorry but I strongly prefer not to introduce new contention points in the SRP initiator driver. Yea... Me neither. What if you just have a simple check on the SG list and reserve the required descriptors up front? Would that work? Such a check wou

Re: [PATCH 4/7] IB/srp: Fix a potential queue overflow in an error path

2015-11-03 Thread Sagi Grimberg
Hello Sagi, Sorry but I strongly prefer not to introduce new contention points in the SRP initiator driver. Yea... Me neither. What if you just have a simple check on the SG list and reserve the required descriptors up front? Would that work? -- To unsubscribe from this list: send the line "

Re: [PATCH] svcrdma: Do not send XDR roundup bytes for a write chunk

2015-11-03 Thread Chuck Lever
> On Oct 16, 2015, at 9:30 AM, Chuck Lever wrote: > > Minor optimization: when dealing with write chunk XDR roundup, do > not post a Write WR for the zero bytes in the pad. Simply update > the write segment in the RPC-over-RDMA header to reflect the extra > pad bytes. > > The Reply chunk is als

Re: [PATCH 4/7] IB/srp: Fix a potential queue overflow in an error path

2015-11-03 Thread Bart Van Assche
On 11/03/2015 11:56 AM, Sagi Grimberg wrote: On 03/11/2015 21:04, Bart Van Assche wrote: On 11/03/2015 09:36 AM, Sagi Grimberg wrote: On 28/10/2015 00:02, Bart Van Assche wrote: Wait until memory registration has finished in the srp_queuecommand() error path before invalidating memory regions

Re: [PATCH 4/7] IB/srp: Fix a potential queue overflow in an error path

2015-11-03 Thread Sagi Grimberg
On 03/11/2015 21:04, Bart Van Assche wrote: On 11/03/2015 09:36 AM, Sagi Grimberg wrote: On 28/10/2015 00:02, Bart Van Assche wrote: Wait until memory registration has finished in the srp_queuecommand() error path before invalidating memory regions to avoid a send queue overflow. This looks

Re: [PATCH 7/7] IB/srp: Avoid that mapping failure triggers an infinite loop

2015-11-03 Thread Sagi Grimberg
Hello Sagi, Since the ret == -ENOMEM test is redundant in the above code that test can be left out. Would that make this patch more clear to you ? It will. Thanks, Sagi. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel

Re: [PATCH 7/7] IB/srp: Avoid that mapping failure triggers an infinite loop

2015-11-03 Thread Bart Van Assche
On 11/03/2015 10:59 AM, Sagi Grimberg wrote: On 03/11/2015 20:56, Bart Van Assche wrote: On 11/03/2015 09:44 AM, Sagi Grimberg wrote: Can you spare a few words on this change in the change log? Signed-off-by: Bart Van Assche Cc: Sagi Grimberg Cc: Sebastian Parschauer --- drivers/infin

Re: RFC rdma cgroup

2015-11-03 Thread Parav Pandit
>> Resource are defined as index and as match_table_t. >> >> enum rdma_resource_type { >> RDMA_VERB_RESOURCE_UCTX, >> RDMA_VERB_RESOURCE_AH, >> RDMA_VERB_RESOURCE_PD, >> RDMA_VERB_RESOURCE_CQ, >> RDMA_VERB_RESOURCE_MR, >> RDMA_VERB_RESOURCE_MW, >>

Re: [PATCH 4/7] IB/srp: Fix a potential queue overflow in an error path

2015-11-03 Thread Bart Van Assche
On 11/03/2015 09:36 AM, Sagi Grimberg wrote: On 28/10/2015 00:02, Bart Van Assche wrote: Wait until memory registration has finished in the srp_queuecommand() error path before invalidating memory regions to avoid a send queue overflow. This looks backwards to me... Why do we even post anythin

Re: [PATCH 7/7] IB/srp: Avoid that mapping failure triggers an infinite loop

2015-11-03 Thread Sagi Grimberg
On 03/11/2015 20:56, Bart Van Assche wrote: On 11/03/2015 09:44 AM, Sagi Grimberg wrote: Can you spare a few words on this change in the change log? Signed-off-by: Bart Van Assche Cc: Sagi Grimberg Cc: Sebastian Parschauer --- drivers/infiniband/ulp/srp/ib_srp.c | 2 ++ 1 file chang

Re: [PATCH 7/7] IB/srp: Avoid that mapping failure triggers an infinite loop

2015-11-03 Thread Bart Van Assche
On 11/03/2015 09:44 AM, Sagi Grimberg wrote: Can you spare a few words on this change in the change log? Signed-off-by: Bart Van Assche Cc: Sagi Grimberg Cc: Sebastian Parschauer --- drivers/infiniband/ulp/srp/ib_srp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/infin

Re: [PATCH] IB/srp: Fix possible send queue overflow

2015-11-03 Thread Sagi Grimberg
On 15/10/2015 12:26, Sagi Grimberg wrote: When using work request based memory registration (fast_reg) we must reserve SQ entries for registration and invalidation in addition to send operations. Each IO consumes 3 SQ entries (registration, send, invalidation) so we need to allocate 3x larger se

Re: [PATCH 7/7] IB/srp: Avoid that mapping failure triggers an infinite loop

2015-11-03 Thread Sagi Grimberg
Can you spare a few words on this change in the change log? Signed-off-by: Bart Van Assche Cc: Sagi Grimberg Cc: Sebastian Parschauer --- drivers/infiniband/ulp/srp/ib_srp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/infiniband/ulp/srp/ib_srp.c b/drivers/infiniband/ulp

Re: shrink struct ib_send_wr V4

2015-11-03 Thread Greg Kroah-Hartman
On Tue, Nov 03, 2015 at 11:59:02AM -0500, Chuck Lever wrote: > > > On Nov 2, 2015, at 6:37 PM, Greg Kroah-Hartman > > wrote: > > > > On Mon, Nov 02, 2015 at 06:20:40PM -0500, Doug Ledford wrote: > >> 1) Aging, but working, drivers that will be removed in the future. > >> Since we no longer have

Re: [PATCH 6/7] IB/srp: Introduce target->mr_pool_size

2015-11-03 Thread Sagi Grimberg
Looks good, Reviewed-by: Sagi Grimberg -- 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

Re: [PATCH 4/7] IB/srp: Fix a potential queue overflow in an error path

2015-11-03 Thread Sagi Grimberg
On 28/10/2015 00:02, Bart Van Assche wrote: Wait until memory registration has finished in the srp_queuecommand() error path before invalidating memory regions to avoid a send queue overflow. This looks backwards to me... Why do we even post anything on our queue-pair to begin with if we got

Re: [PATCH 2/7] IB/srp: Document srp_map_data() return value

2015-11-03 Thread Sagi Grimberg
Looks good, Reviewed-by: Sagi Grimberg -- 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

Re: [PATCH 3/7] IB/srp: Rename work request ID labels

2015-11-03 Thread Sagi Grimberg
Looks good, Reviewed-by: Sagi Grimberg -- 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

Re: [PATCH 1/7] IB/srp: Fix a spelling error

2015-11-03 Thread Sagi Grimberg
Looks good, Reviewed-by: Sagi Grimberg -- 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

Re: shrink struct ib_send_wr V4

2015-11-03 Thread Chuck Lever
> On Nov 2, 2015, at 6:37 PM, Greg Kroah-Hartman > wrote: > > On Mon, Nov 02, 2015 at 06:20:40PM -0500, Doug Ledford wrote: >> 1) Aging, but working, drivers that will be removed in the future. >> Since we no longer have a deprecation mechanism, I was informed that the >> normal procedure now i

Re: IB/core: Use GID table in AH creation and dmac resolution

2015-11-03 Thread Matan Barak
On 11/3/2015 3:11 PM, Dan Carpenter wrote: Hello Matan Barak, This is a semi-automatic email about new static checker warnings. The patch dbf727de7440: "IB/core: Use GID table in AH creation and dmac resolution" from Oct 15, 2015, leads to the following Smatch complaint: drivers/infiniband/h

re: IB/core: Use GID table in AH creation and dmac resolution

2015-11-03 Thread Dan Carpenter
Hello Matan Barak, This is a semi-automatic email about new static checker warnings. The patch dbf727de7440: "IB/core: Use GID table in AH creation and dmac resolution" from Oct 15, 2015, leads to the following Smatch complaint: drivers/infiniband/hw/ocrdma/ocrdma_ah.c:157 ocrdma_create_ah()