<html><body>
<p>I am sure the developers in both of these communities have strong opinions in one way or<br>
the other about the use of common interface and whatever it is but ultimately we need to<br>
find a best possible way to move forward in order to support IB, RNICs and other future <br>
RDMA fabrics. :)<br>
<br>
Absolutely, we would like to see a common mid layer with RDMA-specific components<br>
(for example, IB-CM and RNIC-CM would mostly be different but with very minimal commonality<br>
between them) developed but also should work to provide a transport-neutral interface. <br>
<br>
Today, we do not have a RDMA transport-neutral support with IB verbs PI in the kernel but<br>
we would like to see such an interface so that we can extend it to support variety of RDMA fabrics.<br>
Just because we have some interface supported in the kernel today doesn't mean that<br>
we need to live with that interface forever. Within Linux kernel, we absolutely want to develop<br>
an interface that is extendable to support the future fabrics and we can evolve this through <br>
an open source process that is acceptable to linux kernel community.<br>
<br>
And BTW, I am not suggesting to rip of this existing code right away but rather continue to use and<br>
evolve it.<br>
<br>
I would like to really understand the technical reasons why you say RNIC-PI is irrelevant to Linux kernel. <br>
RNIC-PI is developed to support not only the RNICs but it is also IB compatible. This interface is <br>
something that is developed just like the open source process but with much broader community effort <br>
and also with review of linux OpenRDMA community and kernel community members. <br>
<br>
Thanks<br>
Venkat<br>
<br>
<tt>Roland Dreier <roland@topspin.com> wrote on 05/25/2005 07:35:52 PM:<br>
<br>
> I believe the way forward is to evolve the existing drivers/infiniband<br>
> code already in Linux into a drivers/rdma that supports both IB and<br>
> RNICs. To be extremely blunt, I believe the RNIC-PI is irrelevant to<br>
> the Linux kernel -- no IB vendors will support ripping out a working<br>
> midlayer and starting from scratch, and it doesn't make sense to have<br>
> two essentially equivalent midlayers in the same kernel.<br>
> <br>
> To put a really concrete proposal on the table, I would suggest to<br>
> start by extending the current ib_client registration structure, which<br>
> looks like<br>
> <br>
> struct ib_client {<br>
> char *name;<br>
> void (*add) (struct ib_device *);<br>
> void (*remove)(struct ib_device *);<br>
> <br>
> struct list_head list;<br>
> };<br>
> <br>
> by extending the current enum ib_node_type to something like<br>
> <br>
> enum rdma_device_type {<br>
> RDMA_DEVICE_IB_CA,<br>
> RDMA_DEVICE_IB_SWITCH,<br>
> RDMA_DEVICE_IB_ROUTER,<br>
> RDMA_DEVICE_RNIC<br>
> };<br>
> <br>
> Then the various pieces of code layered on top of the RDMA midlayer<br>
> can decide whether they want to deal with a particular device or not<br>
> by looking at the node_type member. For example, the IB CM, IPoIB,<br>
> etc. could ignore devices of type RDMA_DEVICE_RNIC, while SDP or iSER<br>
> would use all devices and the RNIC CM would take only devices of type<br>
> RDMA_DEVICE_RNIC.<br>
> <br>
> Then someone would have to start implementing a low-level driver for a<br>
> specific RNIC, and find which modifications to the existing verbs are<br>
> required. For example, I believe the QP attribute structure passed<br>
> into the QP modify verb probably has to become a union containing the<br>
> IB attributes and the RNIC attributes. However, most verbs should<br>
> work fine with at most trivial modifications.<br>
> <br>
> The existing OpenIB SDP code will be a good example to study as we<br>
> determine what abstractions need to be added to make it simple for<br>
> consumers to deal with the differences between IB and RNIC.<br>
> <br>
> - R.<br>
</tt></body></html>