Date: Sat, 17 May 2014 14:44:20 +0000 From: "Bentkofsky, Michael" <MBentkofsky@verisign.com> To: "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org> Cc: "'Adrian Chadd \(adrian@freebsd.org\)'" <adrian@freebsd.org> Subject: Re: [rfc] tcp timer update for RSS Message-ID: <080FBD5B7A09F845842100A6DE79623346F2EB44@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
next in thread | raw e-mail | index | archive | help
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-CP= U 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 d= on't know if we'd expect to see any benefit - do you have any traffic condi= tions for which this showed any difference? But we can certainly drive many= hundreds of thousands of connections at reasonably high connection rates i= f that will help. Thanks, Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?080FBD5B7A09F845842100A6DE79623346F2EB44>