On Tue, Oct 13, 2015 at 08:32:25AM +0300, Moni Shoua wrote:
We initially thought to implement a shared library that contains the
transport logic.
However, it seems that a SW Verbs transport driver would allow better
code sharing.
In fact, the VT driver would need only a single user-space driver for
all "backends". Any direct HW access from user-space should be exposed
by the corresponding backend driver and accessed by a different
library (e.g., psm).
I assume by user-space driver we are talking about libverbs? We have
separate libraries for ipath/qib and hfi. We should probably coalesce these
into a single library but that is a separate issue. PSM is also unrelated to
the work here since PSM is not verbs.
At a high-level, it seems that we should do as follows:
- Decide on an initial code base for VT (rxe/hfi/qib), clone it, and
rename to VT
- Split the code to VT and backend and create the initial backend APIs, e.g.:
We have been planning a bit of a different approach. My thoughts are we make
VT a completely new kmod. It will start out life lettings verbs calls from
the core go into the drivers to do their thing, but will contain a bunch of
the duplicated code that we have in hfi1/qib/ipath. The next step is to move
piece by piece the rest of the verbs code.
-- Send packet
-- Deliver packet (receive)
-- Attach multicast
-- Packet buffer allocation
-- Notify when more send space is available
- In parallel, prepare the backends of other drivers while enhancing
VT as needed.
Yes, we need to come up with an API, I'm not fully sure what that should
look like yet, it is a work in progress.
Do you have any preferences to the initial code base?
Do you already have some code that we can look at?
We'll be starting out with making changes to hfi1 and qib to follow shortly
behind. No code just yet, but I should have something to post as an RFC very
soon (in the next two weeks).
Thanks
-Denny
--
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
