Well, I resubmitted the kernel level changes with the comment and signed-off-by fields. I will wait on resubmitting the userspace changes.
The only real contribution to the discussion on what we should do, would be to suggest that maybe we just keep them in a user-patches dir for a while (until a couple of kernel revs with invalidate supported) then move them into the main code base. > On Fri, 2007-05-04 at 19:32 -0500, Steve Wise wrote: >> On Fri, 2007-05-04 at 14:50 -0700, Roland Dreier wrote: >> > A few general things: >> > - please always submit patches with a changelog entry and >> > Signed-off-by: line >> > - please send patches in logical chunks. Usually I'm complaining >> > about people combining unrelated things into one patch, but in this >> > case I think you divided the patch up too much -- rather than 5 >> > patches, this should probably be one kernel patch and one userspace >> > patch. >> > - please make libibverbs patches apply to the libibverbs git tree >> > with -p1. You seem to have generated patches against an OFED >> package. >> > >> > OK, with that out of the way, I think there are still some issues to >> > sort out with how to handle send with invalidate from userspace. >> > These patches don't address the case of new userspace with >> > send-with-invalidate support talking to an unpatched kernel -- it >> > seems that send-with-invalidate would be silently turned into a plain >> > send request, which is not a very good failure mode. >> > >> > I don't know what the right solution is yet -- a kernel ABI bump for >> > this one case (send with invalidate support for userspace drivers that >> > don't do kernel bypass == amso1100) is ugly. Maybe we also need a >> > device capabilities bit that says whether send-with-invalidate is >> > supported? >> > >> >> There already exists a SEND-INV capabilities flag. >> >> <snip> >> IB_DEVICE_SEND_W_INV = (1<<16), >> >> I think with the capabilities flag, we shouldn't worry about changing >> the ABI. But the drivers will need to set this flag. Amso currently >> does... > > Actually, since Amso has set this flag since day one, it doesn't really > solve the ABI issue Roland describes. > > > Steve. > > -- Mikkel Hagen Project Assistant - Fibre Channel/SAS/SATA Consortiums Research and Development Engineer - iWARP Consortium FC/SAS/SATA:1-603-862-0701 iWARP:1-603-862-5083 Fax:1-603-862-4181 UNH-IOL 121 Technology Drive, Suite 2 Durham, NH 03824 _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
