On 11/2/2013 11:59 PM, Bart Van Assche wrote:
On 2/11/2013 12:21, Or Gerlitz wrote:
On Fri, Nov 1, 2013 at 10:37 PM, Bart Van Assche <[email protected]>
wrote:
On 31/10/2013 5:24, Sagi Grimberg wrote:
This patch implements IB_WR_REG_SIG_MR posted by the user.
Baisically this WR involvs 3 WQEs in order to prepare and properly
register the signature layout:
1. post UMR WR to register the sig_mr in one of two possible ways:
* In case the user registered a single MR for data so the UMR
data
segment
consists of:
- single klm (data MR) passed by the user
- BSF with signature attributes requested by the user.
* In case the user registered 2 MRs, one for data and one for
protection,
the UMR consists of:
- strided block format which includes data and protection
MRs and
their repetitive block format.
- BSF with signature attributes requested by the user.
2. post SET_PSV in order to set the for the memory domain initial
signature parameters passed by the user.
3. post SET_PSV in order to set the for the wire domain initial
signature parameters passed by the user.
This patch also introduces some helper functions to set the BSF
correctly
and determining the signature format selectors.
Has it already been explained somewhere what the abbreviations KLM,
BSF and
PSV stand for ?
Bart, these are all HW T10 related objects/concepts, we made an effort
to keep them contained within the mlx5 driver such that they don't
show up on the IB core layer. If this helps for the review, Sagi can
spare few words on each, sure.
Hello Or,
I would certainly appreciate it if these abbreviations could be
clarified further. That would allow me to understand what has been
explained in the above patch description :-)
Bart.
Hey Bart,
As Or said, these concepts are vendor specific and not exposed to IB
core layer And their naming is also pure Mellanox.
This is also might change in future generation HCAs.
In general the sig_mr (signature enabled) is a memory region that can
register other memory regions (hint: data MR and protection MR) and is
attached to (mlx5) signature objects.
KLM: A tuple {key, addr, len} that is used for indirect registration.
BSF: this is the object that describes the wire and memory layouts. we
call it a byte-stream format.
PSV: this is the signature variable that is computing the guards - used
for generation and/or validation. exists for each domain.
So We constructed REG_SIG_MR operation as a 3-way operation:
- Online registration for sig_mr: Register in an indirect manner for
data and protection (if exists).
If no protection exists in memory domain the sig_mr registers the
data buffer (KLM).
If protection exists in memory domain (DIX) the sig_mr registers data
and protections buffers (KLMs)
In the DIX case, order to transfer DIF every pi_interval the
registration also defines the strided format of the execution
(pi_interval of data followed by 8byte of protection in a repetitive
manner).
- Define signature format of wire/memory domains (BSF object)
tell the HW how to treat the signature layout in each domain
(signature type, pi_interval etc...)
- Set the signature variables for each domain (memory, wire)
Here we place the seeds that the HW starts signature computation (In
the DIF case, Initial CRC, Initial ref_tag, initial app_tag).
Sagi.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
