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/
This is a preparation step for T10-PI offload support. We prefer to push
the desicion of which mkey to use (global or fastreg) to iser_fast_reg_mr.
We choose to do this since it in T10-PI we may need to register for
protection buffers and in this case we wish to simplify iser_fast_reg_mr
instead of
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/i
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
---
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/iser_verb
From: Alex Tabachnik
Use modparams to activate protection information support.
pi_enable bool: Based on this parameter iSER will know
if it should support T10-PI. We don't want to do this by
default as it requires to allocate and initiatlize extra
resources. In case pi_enable=N, iSER won't publi
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/ulp
Add logic to initialize protection information entities.
Upon each iSCSI task, we keep the scsi_cmnd in order to
query the scsi protection operations and reference to
protection buffers.
Modify iser_fast_reg_mr to receive indication weather it
is registering the data or protection buffers.
In add
iSCSI needs to be at least aware that a task involves protection
information. In case it does, after the transaction completed
libiscsi will ask the transport to check the protection status
of the transaction.
Unlike transport errors, DIF errors should not prevent successful
completion of the tran
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 +++
Hey Roland, Nic and Co
This patchset adds T10 protection information offload support over
RDMA signature verbs API. This set, along with the iSER target set,
allow end-to-end protection information passthrough and validation.
The patchset was tested against Linux SCSI target with iSER DIF
support
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 -
drivers/infin
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/infiniba
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.
Signed-off-by: Sagi Grimber
On 2/24/2014 5:24 PM, Bart Van Assche wrote:
On 02/24/14 15:30, Sagi Grimberg wrote:
When unmapping request data, it is unsafe automatically
decrement req->nfmr regardless of it's value. This may
happen since IO and reconnect flow may run concurrently
resulting in req->nfmr = -1 and falsely call
On 2/24/2014 5:38 PM, Bart Van Assche wrote:
On 02/24/14 15:30, Sagi Grimberg wrote:
From: Vu Pham
srp_reconnect_rport() serializes calls of srp_rport_reconnect()
with srp_queuecommand(), srp_abort(), srp_reset_device(),
srp_reset_host() via rport->mutex and also blocks srp_queuecommand();
how
From: Ilya Nelkenbaum
Signed-off-by: Ilya Nelkenbaum
---
opensm/osm_sw_info_rcv.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/opensm/osm_sw_info_rcv.c b/opensm/osm_sw_info_rcv.c
index 77c5be7..ce747a9 100644
--- a/opensm/osm_sw_info_rcv.c
+++ b/opensm/osm_sw_info_
From: Eli Dorfman
calculate number of port masks according to number of switch ports
and allocate MFT accordingly
Signed-off-by: Eli Dorfman
Signed-off-by: Alex Netes
---
ibsim/sim.h |5 ++---
ibsim/sim_mad.c |5 +++--
ibsim/sim_net.c |5 +++--
3 files changed, 8 insertions(+)
On 02/27/14 06:48, David Dillow wrote:
> I don't see where the block level is printing messages about the failed
> requests -- but maybe I'm missing it. I see scsi_done() ->
> blk_complete_request() -> blk_done_softirq() -> scsi_softirq_done() ->
> scsi_finish_command() -> scsi_io_completion()
>
>
On 02/27/14 12:51, Sagi Grimberg wrote:
> Regarding in_scsi_eh, can you end-up still posting a send if you are in
> an interrupt context?
> it's just that we have a *very* rare case (not easy to reproduce) in
> RH6.5 where we end-up posting on a just destroyed QP
> (race right in between destroy_qp
>
> > -static int allow_db_fc_on_t5;
> > -module_param(allow_db_fc_on_t5, int, 0644);
> > -MODULE_PARM_DESC(allow_db_fc_on_t5,
> > -"Allow DB Flow Control on T5 (default = 0)");
> > -
> > -static int allow_db_coalescing_on_t5;
> > -module_param(allow_db_coalescing_on_t5, int, 0644);
>
Hey Arlin, I'm trying to clean up the dapl/iwarp/cxgb4 issues, and I'm
seeing something strange. Each time I run a transaction test, I see
that listening endpoints are leaked or left around by the dapltest
server.
Q: after a completed test, should the dapltest server process have
destroyed all of
From: "Steve Wise"
Date: Thu, 27 Feb 2014 11:11:49 -0600
>>
>> > -static int allow_db_fc_on_t5;
>> > -module_param(allow_db_fc_on_t5, int, 0644);
>> > -MODULE_PARM_DESC(allow_db_fc_on_t5,
>> > - "Allow DB Flow Control on T5 (default = 0)");
>> > -
>> > -static int allow_db_coalescing_o
> -Original Message-
> From: Steve Wise [mailto:sw...@opengridcomputing.com]
> Sent: Thursday, February 27, 2014 11:36 AM
> To: 'arlin.r.da...@intel.com'
> Cc: 'linux-rdma@vger.kernel.org'
> Subject: dapltest and listening endpoints.
>
> Hey Arlin, I'm trying to clean up the dapl/iwarp/cx
On Thu, 27 Feb 2014 13:05:44 -0500 (EST)
David Miller wrote:
> From: "Steve Wise"
> Date: Thu, 27 Feb 2014 11:11:49 -0600
>
> >>
> >> > -static int allow_db_fc_on_t5;
> >> > -module_param(allow_db_fc_on_t5, int, 0644);
> >> > -MODULE_PARM_DESC(allow_db_fc_on_t5,
> >> > - "Allow
I was looking to understand the mlx4 driver for the Mellanox adapter.
I just had a query which I was not able to resolve on my own.
Can anyone please help me understand that:
does the HCR(HCA Configuration Register) reside in the Config Space or
MMIO space?
I guess the kernel uses ioremap for a
26 matches
Mail list logo
