.. and as a note - it'll all be behind #ifdef RSS.
-a On 17 May 2014 07:49, Adrian Chadd <[email protected]> wrote: > On 17 May 2014 07:44, Bentkofsky, Michael <[email protected]> wrote: >> Hi Adrian, >> >> >> >> I haven’t had the chance to look this over carefully yet as we’re at BSDCan. >> I think I understand what you’re trying to achieve by aligning the per-CPU >> timer processing per core. In principal that sounds reasonable, although I >> am unsure if you were trying to solve a particular performance issue with >> this particular change. My sense is this is all preparatory with the goal of >> all inp processing to become per core. Could you comment on the general >> evolution you’re considering? Do most of the PCB structures become per-core, >> as in PCB groups? >> >> >> >> If you’d like us to test this change, I’m happy to do so. At the moment I >> don’t know if we’d expect to see any benefit – do you have any traffic >> conditions for which this showed any difference? But we can certainly drive >> many hundreds of thousands of connections at reasonably high connection >> rates if that will help. > > Hi! > > Yes, the aim is to provide RSS support in the RSS model of "align > everything to a specific core." The goal for RSS is to remove both > lock contention between cores and keep data CPU/cache local to improve > efficiency there. > > There's nothing obvious that'll be beneficial right now. The items at > https://wiki.freebsd.org/NetworkRSS have to occur before it is > beneficial to anyone. > > > > -a _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[email protected]"
