[EMAIL PROTECTED] 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). > > Also I can't say I'm thrilled by adding > > > + struct iw_cm_verbs *iwcm; > > 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. >
My understanding is that this is a partial answer, not a deferred one. What is fully addressed is how the iWARP device accepts or initiates a connection that will start the transition to MPA mode immediately. In that mode, there is no integration with the host network TCP layer required -- only co-ordination with the host network IP layer. Linking to the net device does that. Deferred entry into MPA mode is indeed a complex issue, which is why Tom did not propose an immediate solution. The initial model is IB compatible, deals with the needs of virtually all RDMA applications, and is very simple. Locking down this first step, to enable transport neutral application development, is important. It should not have to wait for the entire stack integration problem to be solved. The latter is a complex issue that includes things like compliance with netfilter rules that need to apply to *all* connections with IP semantics, including SDP. That complexity will take some time to work out properly. Meanwhile we can establish a very workable baseline. _______________________________________________ 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
