On Fri, 2006-01-20 at 15:12 -0800, Roland Dreier wrote: > Sean> I haven't seen anyone object to merging the other changes. > Sean> Roland, Hal - any opinion? > > I don't see much urgency in merging it now. When svn diverges from > what's upstream in the kernel, it makes my life harder because I have > to figure out which patches belong upstream and sometimes merge things > by hand (when they hit the divergent regions).
The easy solution here is not to diverge. Unless the iWARP support regresses IB functionality, it does no harm and creates a single software core for both iWARP and IB developers to bring new drivers to market. > > Also I can't say I'm thrilled by adding > > > + struct iw_cm_verbs *iwcm; I agree there are more elegant approaches, however, the design criteria was to minimize changes to ib_verbs and the risk of IB functional regression. I think this approach accomplishes that goal. > > to struct ib_device -- we still really haven't answered the issue of > how iWARP connections interact with the host network stack, we've just > pushed it off into low-level driver code where we can't see it. The implementation not withstanding, we have answered the integration question: - No transport level connection state sharing - No migration of host established connections to RDMA mode. RDMA connection management is integrated with the host stack to the same degree that IB CM is integrated. > > Finally (a minor point), there's a lot of stuff like > > > + const void* pdata, u8 pdata_len) > > It's more idiomatic in the kernel to say "void *pdata" -- in other > words, the space comes before the *, not after it. > > - R. _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
