On 10/30/2013 5:55 PM, Or Gerlitz wrote:
On 30/10/2013 17:20, Hefty, Sean wrote:
The team here enhanced krping to fully cover (and test...) the proposed
>API and driver implementation, its (free) under
>git://beany.openfabrics.org/~sgrimberg/krping.git
>
>We'd like to see this landing in 3.13 such that the development of the
>upper layers can run for 3.14 and and later kernels. Sagi will postV2
>with the two minor changes that came up in Sean's review of V1,
thoughts?
If the upper layers won't be ready until 3.14, why can't these
changes go in then?
I explained, we want to see this landing in sooner rather than later
to avoid triple/quadruple way merge, e.g merge
of code from multiple kernel sub-components in one kernel cycle which
is complex.
My biggest issue is that the kernel verbs API is becoming more and
more unwieldy, and I have heard requests that even the kernel
interfaces need to be easier to use. The main work request structure
used to send a message is around 84 bytes long. This patch bumps
that up another 24 bytes or so. That's over 100 bytes of control
data just to send a message!
Hey Sean,
You are raising a good point, I noticed that too.
I can modify the sig_handover wr extension not to increase structure size.
I'll use ib_sges instead of {mr, va, len}. data ib_sge will be passed in
the existing wr->sg_list, and the protection ib_sge will be passed in
sig_handover extension.
I'll fix & send v2 today.
Maybe we should rethink the approach of exposing low-level hardware
constructs to every distinct feature of every vendor's latest
hardware directly to the kernel ULPs.
T10 DIF is industry standard, and it used in advanced commercial
production storage systems, the feature here is T10 DIF acceleration
for layers (e.g iser/srp/fcoe initiator/targets) that use RDMA. This
feature is supported by some FC cards too, so we want RDMA to be
competitive. We made great effort to expose API which is not tied to
specific HW/Firmware API.
Or.
--
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
