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!
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
