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]"
