On Tue, Jan 20, 2015 at 08:58:34AM +0100, Hans Petter Selasky wrote: > On 01/20/15 08:51, Konstantin Belousov wrote: > > On Tue, Jan 20, 2015 at 05:30:25AM +0100, Hans Petter Selasky wrote: > >> On 01/19/15 22:59, Adrian Chadd wrote: > >>> Hi, > >>> > >>> Would you please check what the results of this are with CPU specific > >>> callwheels? > >>> > >>> I'm doing some 10+ gig traffic testing on -HEAD with RSS enabled (on > >>> ixgbe) and with this setup, the per-CPU TCP callwheel stuff is > >>> enabled. But all the callwheels are now back on clock(0) and so is the > >>> lock contention. :( > >>> > >>> Thanks, > >>> > >> > >> Hi, > >> > >> Like stated in the manual page, callout_reset_curcpu/on() does not work > >> with MPSAFE callouts any more! > > I.e. you 'fixed' some undeterminate bugs in callout migration by not > > doing migration at all anymore. > > > >> > >> You need to use callout_init_{mtx,rm,rw} and remove the custom locking > >> inside the callback in the TCP stack to get it working like before! > > > > No, you need to do this, if you think that whole callout KPI must be > > rototiled. It is up to the person who modifies the KPI, to ensure that > > existing code is not broken. > > > > As I understand, currently we are back to the one-cpu callouts. > > Do other people consider this situation acceptable ? > > > > Hi Konstantin, > > Please read the callout 9 manual page first.
Assume I read it. How this changes any of my points above ? """ A change in the CPU selection cannot happen if this function is re-scheduled inside a callout function. Else the callback function given by the func argument will be executed on the same CPU like previously done. """ You cannot do this without fixing consumers. _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"