Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > Subject: Re: [openib-general] [PATCH ] RFC IB/cm do not track remote QPN in > timewait state > > Michael S. Tsirkin wrote: > >>I've thought about this too, and I think this may end up making the most > >>sense. > >>How would the driver determine how long the QP should remain in timewait, > > > > > > Need to look into this - likely we can just add a call for that. > > Roland? > > The Intel gen1 code passed this into the modify QP call for either reset or > error. My question was more, does the driver have enough information to > calculate the timewait duration based on other modify QP parameters? I don't > know that you want the timewait duration determined by a userspace app. > > > There's no need for CM or any other entity to track timewait QP in this > > setup - > > we can remove TIMEWAIT_EXIT event or pass it up immediately. > > The CM still needs to be able to respond to duplicate DREQs, so it will be
Correct of course - I should have said that CM will only need to track he remote QP/ID and not the local QP, therefore there won't be need for synchronisation beetween timewait in verbs layer and CM. -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
