On Tue, Apr 3, 2012 at 10:49 PM, mxb <m...@alumni.chalmers.se> wrote:
> > On Apr 3, 2012, at 4:31 PM, Tony Sarendal wrote: > > > On Tue, Apr 3, 2012 at 3:41 PM, Jonathan Gray <j...@jsg.id.au> wrote: > > > >> On Tue, Apr 03, 2012 at 03:09:37PM +0200, Tony Sarendal wrote: > >>> When testing new boxes with Intel E3-1270 cpu I don't see AES on the > >> cpu's > >>> in dmesg. > >>> Does this mean that the aes-ni stuff isn't used on these ? I was a bit > >>> curious to see if it had any effect on ipsec performance. > >> > >> According to > >> > >> > http://ark.intel.com/products/52276/Intel-Xeon-Processor-E3-1270-%288M-Cache-3_40-GHz%29 > >> > >> it does support it. So it sounds like a problem with the bios. It > would > >> be printing along with the other cpuid flags in the cpu part > >> of dmesg were it enabled. And if the cpuid says it is not present, > >> it is not used. > >> > > > > You are star. It was disabled in bios. > > > > Cheers. > > > > Sometimes you even need to flash BIOS to have it. > > Worked fine here. Performance boost depended a lot on packet size, a full speed one direction tcp data transfer got a 30% boost from enabling aes-ni. Small packet size, 200 byte mtu in sending direction, gave around 5% boost. The test box has been doing 400Mbps of large frame data transfer for a day or so now. One interesting thing was that running with SP kernel two low-latency, high-speed, tcp tranfers could starve userland badly enough to drop bgp sessions where as with MP kernel the box remained responsive no matter how many tcp sessions I shot through it. /T
