+ IB_WC_SEND = IB_UVERBS_WC_SEND,
+ IB_WC_RDMA_WRITE= IB_UVERBS_WC_RDMA_WRITE,
+ IB_WC_RDMA_READ = IB_UVERBS_WC_RDMA_READ,
+ IB_WC_COMP_SWAP = IB_UVERBS_WC_COMP_SWAP,
+ IB_WC_FETCH_ADD = IB_UVERBS_WC_FETCH_ADD,
+ IB
+enum ib_uverbs_wc_flags {
+ IB_UVERBS_WC_GRH= (1 << 0),
+ IB_UVERBS_WC_WITH_IMM = (1 << 1),
+ IB_UVERBS_WC_WITH_INVALIDATE= (1 << 2),
+ IB_UVERBS_WC_IP_CSUM_OK = (1 << 3),
+ IB_UVERBS_WC_WITH_SMA
From: Leon Romanovsky
The create_cq() can receive creation flags which were used
differently by two following commits [1] and [2]. The current
code caused to not accept any flags at all.
We can skip referencing the linux-rdma mailing list.
This patch unifies the check into one function and
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
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
But now the first I/O(s) could be lost if no other I/O comes in,
right? I suspect that we need to keep this loop to protect against
such corner cases.
It can happen theoretically, but why do we even bother? Why not just
post the recv buffer after we moved in to CH_LIVE? This why we let the
R
But now the first I/O(s) could be lost if no other I/O comes in,
right? I suspect that we need to keep this loop to protect against
such corner cases.
It can happen theoretically, but why do we even bother? Why not just
post the recv buffer after we moved in to CH_LIVE? This why we let the
RC
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
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
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
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
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
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
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
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
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
suggestion though, otherwise
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
Avoid that srpt_close_session() waits if it doesn't have to wait.
Can you explain when it doesn't have to wait? is it possible that
srpt_release_channel_work() was already triggered? isn't that a problem?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a
On 05/01/2016 16:25, Bart Van Assche wrote:
The target core function that should be called if target_submit_cmd()
fails is target_put_sess_cmd(). Additionally, change the return type
of srpt_handle_cmd() from int into void.
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
---
drivers/i
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
On 05/01/2016 16:26, Bart Van Assche wrote:
The Last WQE Reached event is only generated after one or more work
requests have been queued on the QP associated with a session. Since
session shutdown can start before any work requests have been queued,
use a zero-length RDMA write to wait until a
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
Keep the ib_srpt session as long as srpt_close_session() may
access it.
Makes sense,
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.
On 06/01/2016 16:34, Bart Van Assche wrote:
On 01/06/2016 03:21 PM, Sagi Grimberg wrote:
Avoid that srpt_close_session() waits if it doesn't have to wait.
Can you explain when it doesn't have to wait? is it possible that
srpt_release_channel_work() was already triggered? is
ULPs are *already* using the same registrations for both local and
remote access.
Where? Out of tree?
I haven't found anything in-tree for sure.
We have that in iSER.
iSCSI allows a FirstBurst functionality and iSER as an iSCSI
transport is required to support that.
The FirstBurst is div
FYI, the only conflict as reported in linux-next last week is with nfsd
tree and "IB: merge struct ib_device_attr into struct ib_device" here:
http://marc.info/?l=linux-next&m=145155049101826&w=2
It looks like there is ongoing discussion this morning wrt rdma + nfsd
trees..
Do you still want
This patch introduces an implementation of a back-end that works with
RVT to make RoCE Verbs transport over any Ethernet network device.
Example:
After loading ib_rxe_net.ko
echo eth1 > /sys/module/ib_rxe_net/parameters/add
will create rvt0 IB device in RVT with Ethernet link layer
---
On 3/3/2014 6:41 AM, Mike Christie wrote:
On 02/27/2014 05:13 AM, Sagi Grimberg wrote:
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 4046241..a58a6bb 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -395,6 +395,10 @@ static int iscsi_prep_scsi_cmd_pdu
On 3/3/2014 6:44 AM, Mike Christie wrote:
On 02/27/2014 05:13 AM, Sagi Grimberg wrote:
diff --git a/drivers/infiniband/ulp/iser/iser_initiator.c
b/drivers/infiniband/ulp/iser/iser_initiator.c
index 58e14c7..7fd95fe 100644
--- a/drivers/infiniband/ulp/iser/iser_initiator.c
+++ b/drivers
On 3/4/2014 9:49 AM, Or Gerlitz wrote:
On 04/03/2014 02:01, Nicholas A. Bellinger wrote:
This is necessary because even though IB_SEND_SIGNALED is
not set for RDMA WRITEs + READs, during a QP failure event
the work requests will be returned with exception status
from the TX completion queue.
I
On 3/4/2014 11:38 AM, Or Gerlitz wrote:
On 03/03/2014 06:44, Mike Christie wrote:
The xmit_task callout does handle failures like EINVAL. If the above map
calls fail then you would get infinite retries. You would currently want
to do the mapping in the init_task callout instead.
If it makes it
On 3/4/2014 1:25 PM, Or Gerlitz wrote:
On 04/03/2014 11:59, Sagi Grimberg wrote:
On 3/4/2014 11:38 AM, Or Gerlitz wrote:
On 03/03/2014 06:44, Mike Christie wrote:
The xmit_task callout does handle failures like EINVAL. If the
above map
calls fail then you would get infinite retries. You would
even though IB_SEND_SIGNALED is not
set for either work request, during a QP failure event the work
requests will be returned with exception status from the TX
completion queue.
Cc: Sagi Grimberg
Cc: Or Gerlitz
Signed-off-by: Nicholas Bellinger
---
drivers/infiniband/ulp/isert/ib_isert.c |8
On 3/4/2014 2:00 AM, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger
Hi Or & Sagi,
This series addresses a number of active I/O shutdown related issues
in iser-target code that have come up recently during stress testing.
Note there is still a seperate iser-target network portal shutdow
On 3/4/2014 6:16 PM, Or Gerlitz wrote:
On 04/03/2014 16:44, Sagi Grimberg wrote:
@@ -1707,10 +1707,17 @@ int iscsi_queuecommand(struct Scsi_Host
*host, struct scsi_cmnd *sc)
goto prepd_fault;
}
}
- if
On 3/5/2014 2:06 AM, Nicholas A. Bellinger wrote:
On Tue, 2014-03-04 at 17:17 +0200, Sagi Grimberg wrote:
On 3/4/2014 2:00 AM, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger
Hi Or & Sagi,
This series addresses a number of active I/O shutdown related issues
in iser-target code
Unaligned SG-lists may also happen for protection
information. Genrelize bounce buffer routine to handle
any iser_data_buf which may be data and/or protection.
This patch does not change any functionality.
Signed-off-by: Sagi Grimberg
---
drivers/infiniband/ulp/iser/iser_memory.c | 53
when the block layer merges bios.
- Don't fail connections on devices without DIF support - warn and continue
without DIF.
- reword FR -> FastReg
Alex Tabachnik (2):
IB/iser: Introduce pi_enable, pi_guard module parameters
IB/iser: Initialize T10-PI resources
Sagi Grimberg (11):
IB/
addition Introduce iser_reg_sig_mr which performs fast
registration work-request for a signature enabled memory region
(IB_WR_REG_SIG_MR). In this routine we set all the protection
relevants for the device to offload protection data-transfer
and verification.
Signed-off-by: Sagi Grimberg
Signed-off
Once the iSCSI transaction is completed we must
imeplement check_protection in order to notify
on DIF errors that may have occured.
The routine boils down to calling ib_check_mr_status
to get the signature status of the transaction.
Signed-off-by: Sagi Grimberg
Signed-off-by: Alex Tabachnik
In T10-PI support we will have memory keys for protection
buffers and signature transactions. We prefer to compact
indicators rather than keeping multiple bools.
This commit does not change any functionality.
Signed-off-by: Sagi Grimberg
Signed-off-by: Alex Tabachnik
---
drivers/infiniband
FRWR stands for "fast registration work request". We
want to avoid calling the fastreg pool with that name,
instead we name it fastreg which stands for "fast registration".
This pool will include more elements in the future, so
it is a good idea to generalize the name.
of repeating the logic of which key to use.
This patch does not change any functionality.
Signed-off-by: Sagi Grimberg
Signed-off-by: Alex Tabachnik
---
drivers/infiniband/ulp/iser/iser_memory.c | 101 +
1 files changed, 59 insertions(+), 42 deletions(-)
diff --git
: APPTAG_CHECK_FAILED
- 0x3: REFTAG_CHECK_FAILED
Signed-off-by: Sagi Grimberg
Signed-off-by: Alex Tabachnik
---
drivers/scsi/libiscsi.c | 32
include/scsi/libiscsi.h |4
include/scsi/scsi_transport_iscsi.h |1 +
3 files
From: Alex Tabachnik
During connection establishment we also initiatlize
T10-PI resources (QP, PI contexts) in order to support
SCSI's protection operations.
Signed-off-by: Alex Tabachnik
Signed-off-by: Sagi Grimberg
---
drivers/infiniband/ulp/iser/iscsi_iser.h | 21 -
dr
fastreg descriptor will include protection information context.
In order to place the logic in one place we introduce
iser_create_fr_desc function.
This patch does not change any functionality.
Signed-off-by: Sagi Grimberg
Signed-off-by: Alex Tabachnik
---
drivers/infiniband/ulp/iser
For T10-PI offload support, we will need to know the
device signature offload capability upon every connection
establishment.
This patch does not change any functionality.
Signed-off-by: Sagi Grimberg
Signed-off-by: Alex Tabachnik
---
drivers/infiniband/ulp/iser/iscsi_iser.h |1 +
drivers
After allocating a scsi_host we set protection types
and guard type supported.
Signed-off-by: Sagi Grimberg
Signed-off-by: Alex Tabachnik
---
drivers/infiniband/ulp/iser/iscsi_iser.c | 23 ++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/drivers
This routines operates on data buffers and may also work with
protection infomation buffers. So we generalize them to handle
an iser_data_buf which can be the command data or command protection
information.
This patch does not change any functionality.
Signed-off-by: Sagi Grimberg
---
drivers
nly CRC is allowed.
In the next phase, it is worth considering passing these
parameters from iscsid via nlmsg. This will allow these
parameters to be connection based rather than global.
Signed-off-by: Alex Tabachnik
Signed-off-by: Sagi Grimberg
---
drivers/infiniband/ulp/iser/iscsi_ise
On 3/6/2014 12:04 AM, Nicholas A. Bellinger wrote:
On Wed, 2014-03-05 at 14:12 +0200, Sagi Grimberg wrote:
On 3/5/2014 2:06 AM, Nicholas A. Bellinger wrote:
On Tue, 2014-03-04 at 17:17 +0200, Sagi Grimberg wrote:
On 3/4/2014 2:00 AM, Nicholas A. Bellinger wrote:
From: Nicholas Bellinger
On 3/6/2014 11:10 AM, Bart Van Assche wrote:
On 02/27/14 12:32, Sagi Grimberg wrote:
As I recall (need to re-confirm this), the problem was that in unstable
ports condition srp_abort is
called invoking srp_free_req (unmap call #1) and reconnect process (or
reset_device or terminate_io
On 3/6/2014 5:32 PM, sagi grimberg wrote:
On 3/6/2014 11:10 AM, Bart Van Assche wrote:
On 02/27/14 12:32, Sagi Grimberg wrote:
As I recall (need to re-confirm this), the problem was that in
unstable
ports condition srp_abort is
called invoking srp_free_req (unmap call #1) and reconnect
On 3/7/2014 9:43 PM, Roland Dreier wrote:
So I went ahead and applied this for 3.15,
Hey Roland,
Thanks for taking the time to take a look and pick this up.
although I suspect the
verbs API is probably the wrong one.
I will be more than happy to here your concerns, share our approach and
On 3/11/2014 12:00 AM, Nicholas A. Bellinger wrote:
On Thu, 2014-03-06 at 16:05 +0200, sagi grimberg wrote:
On 3/6/2014 12:04 AM, Nicholas A. Bellinger wrote:
On Wed, 2014-03-05 at 14:12 +0200, Sagi Grimberg wrote:
On 3/5/2014 2:06 AM, Nicholas A. Bellinger wrote:
On Tue, 2014-03-04 at 17:17
On 3/7/2014 10:13 AM, Bart Van Assche wrote:
On 03/06/14 17:10, Sagi Grimberg wrote:
So I took Roland latest 3.14-rc1 and tried to reproduce this issue using
HCA with no FMRs support and was *NOT* able to reproduce this issue. This
issue reproduced for me on RH6 backported srp and I can't
On 3/11/2014 3:51 PM, Bart Van Assche wrote:
On 03/11/14 14:38, Sagi Grimberg wrote:
And before the SCSI host lock push-down the SCSI host lock was
held around the srp_queuecommand() invocation. In other words, holding a
spin lock around the srp_post_send() call in srp_queuecommand() is
neither
On 3/11/2014 4:29 PM, Bart Van Assche wrote:
On 03/11/14 15:07, Sagi Grimberg wrote:
On 3/11/2014 3:51 PM, Bart Van Assche wrote:
On 03/11/14 14:38, Sagi Grimberg wrote:
I see... will assigning scmnd = NULL only if srp_post_send will fail,
and restore the assignment as before help?
Sorry but
On 3/11/2014 5:00 PM, Bart Van Assche wrote:
On 03/11/14 15:48, Sagi Grimberg wrote:
But I think this lock can be taken conditionally. I mean in the
sunny-day scenario we don't expect
srp_terminate_io to race with srp_post_send. That can happen only when
rport state transitions
to FAIL
On 3/12/2014 3:16 PM, Bart Van Assche wrote:
On 03/11/14 16:30, Sagi Grimberg wrote:
State FAIL_FAST must come *after* stated BLOCKED. Do you think that
taking the lock
once the rport transitions to state BLOCKED suffices? I'm aiming to
avoid this lock in
the sunny-day flow. Taking this
On 3/13/2014 8:15 PM, Nicholas A. Bellinger wrote:
Hey Sagi,
On Wed, 2014-02-19 at 17:50 +0200, Sagi Grimberg wrote:
In case the Target core passed transport T10 protection
operation:
1. Register data buffer (data memory region)
2. Register protection buffer if exsists (prot memory region)
3
On 3/13/2014 8:59 PM, Nicholas A. Bellinger wrote:
On Thu, 2014-03-13 at 20:57 +0200, Sagi Grimberg wrote:
On 3/13/2014 8:15 PM, Nicholas A. Bellinger wrote:
Hey Sagi,
On Wed, 2014-02-19 at 17:50 +0200, Sagi Grimberg wrote:
In case the Target core passed transport T10 protection
operation
On 3/17/2014 6:59 PM, Mike Christie wrote:
This patch is ok, but happened to the patch for the xmit task path?
Hey Mike, Thanks for your Ack on this.
The xmit_task fix was posted as a separate patch since it is
not specific to this set (relevant also for existing data dma_mapping in
xmit_t
On 3/29/2014 1:30 AM, Chuck Lever wrote:
On Mar 28, 2014, at 2:42 AM, Senn Klemens wrote:
Hi Chuck,
On 03/27/2014 04:59 PM, Chuck Lever wrote:
Hi-
On Mar 27, 2014, at 12:53 AM, Reiter Rafael wrote:
On 03/26/2014 07:15 PM, Chuck Lever wrote:
Hi Rafael-
I’ll take a look. Can you report
On 3/29/2014 3:05 AM, Chuck Lever wrote:
On Mar 28, 2014, at 4:06 PM, sagi grimberg wrote:
On 3/29/2014 1:30 AM, Chuck Lever wrote:
On Mar 28, 2014, at 2:42 AM, Senn Klemens wrote:
Hi Chuck,
On 03/27/2014 04:59 PM, Chuck Lever wrote:
Hi-
On Mar 27, 2014, at 12:53 AM, Reiter Rafael
On 4/15/2014 1:23 AM, Chuck Lever wrote:
The current CQ handler uses the ib_wc.opcode field to distinguish
between event types. However, the contents of that field are not
reliable if the completion status is not IB_WC_SUCCESS.
When an error completion occurs on a send event, the CQ handler
sche
On 4/16/2014 4:30 PM, Steve Wise wrote:
On 4/16/2014 7:48 AM, Sagi Grimberg wrote:
On 4/15/2014 1:23 AM, Chuck Lever wrote:
The current CQ handler uses the ib_wc.opcode field to distinguish
between event types. However, the contents of that field are not
reliable if the completion status is
On 4/16/2014 5:25 PM, Steve Wise wrote:
-Original Message-
From: Sagi Grimberg [mailto:sa...@dev.mellanox.co.il]
Sent: Wednesday, April 16, 2014 9:13 AM
To: Steve Wise; Chuck Lever; linux-...@vger.kernel.org;
linux-rdma@vger.kernel.org
Subject: Re: [PATCH 7/8] xprtrdma: Split the
On 4/16/2014 5:43 PM, Steve Wise wrote:
Hmm, But if either FASTREG or LINV failed the QP will go to error state
and you *will* get the error wc (with a rain of FLUSH errors).
AFAICT it is safe to assume that it succeeded as long as you don't get
error completions.
But if an unsignaled FASTREG is
On 4/16/2014 6:08 PM, Chuck Lever wrote:
Hi Sagi-
Thanks for the review! In-line replies below.
2. If I understood correctly, I see that the CQs are loop-polled in an
interrupt context.
This may become problematic in stress workload where the CQ simply never
drains (imagine
some s
On 4/16/2014 9:21 PM, Chuck Lever wrote:
Passing a small array to ip_poll_cq() is actually easy to do, and is
exactly equivalent to a poll budget. The struct ib_wc should be taken
off the stack anyway, IMO.
The only other example I see in 3.15 right now is IPoIB, which seems
to do exactly this.
On 4/17/2014 4:55 PM, Chuck Lever wrote:
On Apr 17, 2014, at 3:06 AM, Sagi Grimberg wrote:
On 4/16/2014 9:21 PM, Chuck Lever wrote:
Passing a small array to ip_poll_cq() is actually easy to do, and is
exactly equivalent to a poll budget. The struct ib_wc should be taken
off the stack anyway
On 4/17/2014 5:34 PM, Steve Wise wrote:
You could use a small array combined with a loop and a budget count. So the
code would
grab, say, 4 at a time, and keep looping polling up to 4 until the CQ is empty
or the
desired budget is reached...
Bingo... couldn't agree more.
Poll Arrays are a
On 4/19/2014 7:31 PM, Chuck Lever wrote:
Hi Sagi-
On Apr 17, 2014, at 3:11 PM, Sagi Grimberg wrote:
On 4/17/2014 5:34 PM, Steve Wise wrote:
You could use a small array combined with a loop and a budget count. So the
code would
grab, say, 4 at a time, and keep looping polling up to 4
On 4/22/2014 1:03 AM, Chuck Lever wrote:
Sagi Grimberg points out that a steady
stream of CQ events could starve other work because of the boundless
loop pooling in rpcrdma_{send,recv}_poll().
Instead of a (potentially infinite) while loop, return after
collecting a budgeted number of
On 4/22/2014 9:23 AM, Christoph Hellwig wrote:
On Mon, Apr 21, 2014 at 06:02:14PM -0400, Chuck Lever wrote:
ALLPHYSICAL is not a safe memory registration mode because it
permits NFS servers to write anywhere in a client's memory. NFS
server bugs could result in client memory being overwritten.
On 4/24/2014 2:30 AM, Devesh Sharma wrote:
Hi Chuck
Following is the complete call trace of a typical NFS-RDMA transaction while
mounting a share.
It is unavoidable to stop calling post-send in case it is not created.
Therefore, applying checks to the connection state is a must
While registeri
On 4/24/2014 6:01 PM, Chuck Lever wrote:
On Apr 24, 2014, at 3:12 AM, Sagi Grimberg wrote:
On 4/24/2014 2:30 AM, Devesh Sharma wrote:
Hi Chuck
Following is the complete call trace of a typical NFS-RDMA transaction while
mounting a share.
It is unavoidable to stop calling post-send in case
On 4/27/2014 3:37 PM, Chuck Lever wrote:
Why not first create a new id+qp and assign them - and then destroy the old
id+qp?
see SRP related section: ib_srp.x:srp_create_target_ib()
Anyway it is indeed important to guarantee that no xmit flows happens
concurrently to that,
and cleanups are p
On 5/6/2014 3:50 PM, Bart Van Assche wrote:
Avoid that the kernel-doc tool warns about missing argument descriptions
for the ib_srp.[ch] source files.
Signed-off-by: Bart Van Assche
Cc: Roland Dreier
Cc: David Dillow
Cc: Sagi Grimberg
Cc: Vu Pham
Cc: Sebastian Parschauer
---
drivers
On 5/6/2014 3:51 PM, Bart Van Assche wrote:
This patch does not change any functionality.
Signed-off-by: Bart Van Assche
Cc: Roland Dreier
Cc: David Dillow
Cc: Sagi Grimberg
Cc: Vu Pham
Cc: Sebastian Parschauer
---
drivers/infiniband/ulp/srp/ib_srp.c | 9 -
1 file changed, 4
Cc: David Dillow
Cc: Sagi Grimberg
Cc: Vu Pham
Cc: Sebastian Parschauer
---
drivers/infiniband/ulp/srp/ib_srp.c | 56 ++---
1 file changed, 33 insertions(+), 23 deletions(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
in
On 5/6/2014 3:53 PM, Bart Van Assche wrote:
This patch does not change any functionality.
Signed-off-by: Bart Van Assche
Cc: Roland Dreier
Cc: David Dillow
Cc: Sagi Grimberg
Cc: Vu Pham
Cc: Sebastian Parschauer
---
drivers/infiniband/ulp/srp/ib_srp.c | 77
On 5/6/2014 3:53 PM, Bart Van Assche wrote:
This patch does not change any functionality.
Signed-off-by: Bart Van Assche
Cc: Roland Dreier
Cc: David Dillow
Cc: Sagi Grimberg
Cc: Vu Pham
Cc: Sebastian Parschauer
---
drivers/infiniband/ulp/srp/ib_srp.c | 37
On 5/6/2014 3:54 PM, Bart Van Assche wrote:
This patch is needed by the patch that adds fast registration support.
Signed-off-by: Bart Van Assche
Cc: Roland Dreier
Cc: David Dillow
Cc: Sagi Grimberg
Cc: Vu Pham
Cc: Sebastian Parschauer
---
drivers/infiniband/ulp/srp/ib_srp.c | 41
.
Signed-off-by: Bart Van Assche
Cc: Roland Dreier
Cc: David Dillow
Cc: Sagi Grimberg
Cc: Vu Pham
Cc: Sebastian Parschauer
---
drivers/infiniband/ulp/srp/ib_srp.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b
On 5/6/2014 3:56 PM, Bart Van Assche wrote:
Certain HCA types (e.g. Connect-IB) and certain configurations (e.g.
ConnectX VF) support FR but not FMR. Hence add FR support.
Signed-off-by: Bart Van Assche
Cc: Roland Dreier
Cc: David Dillow
Cc: Sagi Grimberg
Cc: Vu Pham
Cc: Sebastian
On 5/7/2014 4:52 PM, Bart Van Assche wrote:
On 05/07/14 12:37, Sagi Grimberg wrote:
On 5/6/2014 3:51 PM, Bart Van Assche wrote:
This patch does not change any functionality.
Signed-off-by: Bart Van Assche
Cc: Roland Dreier
Cc: David Dillow
Cc: Sagi Grimberg
Cc: Vu Pham
Cc: Sebastian
On 5/7/2014 5:11 PM, Bart Van Assche wrote:
On 05/07/14 12:50, Sagi Grimberg wrote:
On 5/6/2014 3:54 PM, Bart Van Assche wrote:
-static void srp_free_req_data(struct srp_target_port *target)
+static void srp_free_req_data(struct srp_target_port *target,
+ struct srp_request
On 5/7/2014 5:59 PM, Bart Van Assche wrote:
On 05/07/14 13:34, Sagi Grimberg wrote:
+module_param(prefer_fr, bool, 0444);
+MODULE_PARM_DESC(prefer_fr,
+ "Whether to use FR if both FMR and FR are supported");
Will it be better to make it a per-target attribute?
Hello Sagi,
On 5/8/2014 3:38 PM, Bart Van Assche wrote:
On 05/07/14 19:19, Sagi Grimberg wrote:
On 5/7/2014 5:59 PM, Bart Van Assche wrote:
On 05/07/14 13:34, Sagi Grimberg wrote:
+pool = srp_create_fr_pool(dev->dev, dev->pd,
+ SRP_MDESC_PER_POOL, max_pages_per_mr);
On 5/8/2014 7:00 PM, Bart Van Assche wrote:
On 05/08/14 17:16, Sagi Grimberg wrote:
On 5/8/2014 3:38 PM, Bart Van Assche wrote:
On 05/07/14 19:19, Sagi Grimberg wrote:
On 5/7/2014 5:59 PM, Bart Van Assche wrote:
On 05/07/14 13:34, Sagi Grimberg wrote:
+pool = srp_create_fr_pool(dev
()
handles completions correctly that arrive after srp_finish_req()
has been invoked.
Signed-off-by: Bart Van Assche
Cc: Roland Dreier
Cc: David Dillow
Cc: Sagi Grimberg
Cc: Vu Pham
Cc: Sebastian Parschauer
---
drivers/infiniband/ulp/srp/ib_srp.c | 457
On 5/13/2014 5:38 PM, Bart Van Assche wrote:
Changes compared to v1:
- Modified the FMR code such that one FMR pool is allocated per
connection instead of one pool per HCA.
- Dropped the patch "Make srp_alloc_req_data() reallocate request data".
- Moved introduction of the register_always kern
On 5/14/2014 10:05 AM, Bart Van Assche wrote:
On 05/13/14 18:48, Sagi Grimberg wrote:
On 5/13/2014 5:44 PM, Bart Van Assche wrote:
static int srp_create_target_ib(struct srp_target_port *target)
{
struct srp_device *dev = target->srp_host->srp_dev;
@@ -318,6 +449,8 @@ stat
On 5/14/2014 11:51 AM, Bart Van Assche wrote:
On 05/14/14 10:18, Sagi Grimberg wrote:
On 5/14/2014 10:05 AM, Bart Van Assche wrote:
On 05/13/14 18:48, Sagi Grimberg wrote:
On 5/13/2014 5:44 PM, Bart Van Assche wrote:
+memcpy(desc->frpl->page_list, state->pages,
+ siz
l-per-SRP-connection.patch
0008-IB-srp-Rename-FMR-related-variables.patch
0009-IB-srp-Add-fast-registration-support.patch
The series looks good to me.
Reviewed-by: Sagi Grimberg
Sagi.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a messa
implementations.
Sagi Grimberg (3):
mlx5: Fix signature handover operation for interleaved buffers
mlx5: Simplify signature handover wqe for interleaved buffers
mlx5: Copy DIF fields only when input and output space values match
drivers/infiniband/hw/mlx5/qp.c | 38
ming de-interleaving and re-interleaving
of the protection data in the PT stage. Regardless, signature verbs support
this mode.
Signed-off-by: Sagi Grimberg
---
drivers/infiniband/hw/mlx5/qp.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/qp
Some DIF implementations (SCSI initiator/target) may want to
use different input/output values for application tag and/or
reference tag. So in case memory/wire domain values don't
match HW must not copy them.
Signed-off-by: Sagi Grimberg
---
drivers/infiniband/hw/mlx5/qp.c |9 ++-
901 - 1000 of 1318 matches
Mail list logo
