[rfc] tcp timer update for RSS

[Adrian Chadd]

On 17 May 2014 07:44, Bentkofsky, Michael <MBentkofsky at verisign.com> 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