I usually try to avoid sending messages like the following, but...
Well said, Roland. TTKO - Time To Kernel dot Org. I for one want iWARP there along with IB. Before 2007. Before 2006! Tom. At 02:09 PM 5/27/2005, Roland Dreier wrote: > Caitlin> There isn't enough there to go farther. > >I think there is. In fact I outlined exactly what I would do if I >were working at an iWARP company: > > Roland> Then someone would have to start implementing a low-level > Roland> driver for a specific RNIC, and find which modifications > Roland> to the existing verbs are required. For example, I > Roland> believe the QP attribute structure passed into the QP > Roland> modify verb probably has to become a union containing the > Roland> IB attributes and the RNIC attributes. However, most > Roland> verbs should work fine with at most trivial modifications. > >As for which option I was suggesting, it was c: > > Caitlin> c) The same methods but with struct/enums that have > Caitlin> common and transport specific portions? That is doable, > Caitlin> in fact that is what RNIC-PI is today. Repeating that > Caitlin> work with the gen2 verbs will be time consuming. I don't > Caitlin> want to have to wait 4 months to debate the details of > Caitlin> this before I can start working on my next generation of > Caitlin> verbs. > >OpenIB chose to focus on getting working code released quickly. >OpenRDMA chose to focus on writing architecture documents and API >specifications. The results were completely unsurprising. > >I have outlined what I believe are good and valid reasons why there >should not be two verbs layers in the Linux kernel. If you think I'm >wrong and that you will be able to have RNIC-PI merged into the Linux >kernel alongside the existing IB midlayer, then implementing iWARP >support through RNIC-PI is a reasonable way forward. > >If you believe that the single verbs layer in the kernel should be >RNIC-PI, then you should extend RNIC-PI to support the IB features >currently supported (eg datagrams), and port the existing IB code to >the new API. Once that's done I would certainly be happy to review >the changes for merging. However, I don't think any current OpenIB >contributors will be willing to do the work to port to RNIC-PI. I see >no reason to spend a lot of effort to end up with a result that will >be at best equivalent to what we have today and will likely be worse >in some real ways (for example, how does RNIC-PI handle adapter hotplug?) > >If neither of these options appeals to you, then the only alternative >left seems to be to work with the OpenIB community to evolve the >existing IB midlayer into an RDMA midlayer than can support both IB >and iWARP. > >Without seeing some real patches from the iWARP side, it's hard for me >to see any value in continuing to participate in this debate. > > - R. >_______________________________________________ >openib-general mailing list >[email protected] >http://openib.org/mailman/listinfo/openib-general > >To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
