1. 21 10月, 2011 4 次提交
  2. 22 9月, 2011 2 次提交
  3. 10 8月, 2011 1 次提交
    • M
      crypto: sha1 - SSSE3 based SHA1 implementation for x86-64 · 66be8951
      Mathias Krause 提交于
      This is an assembler implementation of the SHA1 algorithm using the
      Supplemental SSE3 (SSSE3) instructions or, when available, the
      Advanced Vector Extensions (AVX).
      
      Testing with the tcrypt module shows the raw hash performance is up to
      2.3 times faster than the C implementation, using 8k data blocks on a
      Core 2 Duo T5500. For the smalest data set (16 byte) it is still 25%
      faster.
      
      Since this implementation uses SSE/YMM registers it cannot safely be
      used in every situation, e.g. while an IRQ interrupts a kernel thread.
      The implementation falls back to the generic SHA1 variant, if using
      the SSE/YMM registers is not possible.
      
      With this algorithm I was able to increase the throughput of a single
      IPsec link from 344 Mbit/s to 464 Mbit/s on a Core 2 Quad CPU using
      the SSSE3 variant -- a speedup of +34.8%.
      
      Saving and restoring SSE/YMM state might make the actual throughput
      fluctuate when there are FPU intensive userland applications running.
      For example, meassuring the performance using iperf2 directly on the
      machine under test gives wobbling numbers because iperf2 uses the FPU
      for each packet to check if the reporting interval has expired (in the
      above test I got min/max/avg: 402/484/464 MBit/s).
      
      Using this algorithm on a IPsec gateway gives much more reasonable and
      stable numbers, albeit not as high as in the directly connected case.
      Here is the result from an RFC 2544 test run with a EXFO Packet Blazer
      FTB-8510:
      
       frame size    sha1-generic     sha1-ssse3    delta
          64 byte     37.5 MBit/s    37.5 MBit/s     0.0%
         128 byte     56.3 MBit/s    62.5 MBit/s   +11.0%
         256 byte     87.5 MBit/s   100.0 MBit/s   +14.3%
         512 byte    131.3 MBit/s   150.0 MBit/s   +14.2%
        1024 byte    162.5 MBit/s   193.8 MBit/s   +19.3%
        1280 byte    175.0 MBit/s   212.5 MBit/s   +21.4%
        1420 byte    175.0 MBit/s   218.7 MBit/s   +25.0%
        1518 byte    150.0 MBit/s   181.2 MBit/s   +20.8%
      
      The throughput for the largest frame size is lower than for the
      previous size because the IP packets need to be fragmented in this
      case to make there way through the IPsec tunnel.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Cc: Maxim Locktyukhin <maxim.locktyukhin@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      66be8951
  4. 27 7月, 2011 5 次提交
  5. 26 7月, 2011 1 次提交
    • J
      xen/tracing: fix compile errors when tracing is disabled. · b3c4b982
      Jeremy Fitzhardinge 提交于
      When CONFIG_FUNCTION_TRACER is disabled, compilation fails as follows:
        CC      arch/x86/xen/setup.o
      In file included from arch/x86/include/asm/xen/hypercall.h:42,
                       from arch/x86/xen/setup.c:19:
      include/trace/events/xen.h:31: warning: 'struct multicall_entry' declared inside parameter list
      include/trace/events/xen.h:31: warning: its scope is only this definition or declaration, which is probably not what you want
      include/trace/events/xen.h:31: warning: 'struct multicall_entry' declared inside parameter list
      include/trace/events/xen.h:31: warning: 'struct multicall_entry' declared inside parameter list
      include/trace/events/xen.h:31: warning: 'struct multicall_entry' declared inside parameter list
      [...]
      arch/x86/xen/trace.c:5: error: '__HYPERVISOR_set_trap_table' undeclared here (not in a function)
      arch/x86/xen/trace.c:5: error: array index in initializer not of integer type
      arch/x86/xen/trace.c:5: error: (near initialization for 'xen_hypercall_names')
      arch/x86/xen/trace.c:6: error: '__HYPERVISOR_mmu_update' undeclared here (not in a function)
      arch/x86/xen/trace.c:6: error: array index in initializer not of integer type
      arch/x86/xen/trace.c:6: error: (near initialization for 'xen_hypercall_names')
      
      Fix this by making sure struct multicall_entry has a declaration in
      scope at all times, and don't bother compiling xen/trace.c when tracing
      is disabled.
      Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      b3c4b982
  6. 25 7月, 2011 2 次提交
  7. 24 7月, 2011 20 次提交
  8. 23 7月, 2011 2 次提交
    • O
      virtio: expose for non-virtualization users too · e7254219
      Ohad Ben-Cohen 提交于
      virtio has been so far used only in the context of virtualization,
      and the virtio Kconfig was sourced directly by the relevant arch
      Kconfigs when VIRTUALIZATION was selected.
      
      Now that we start using virtio for inter-processor communications,
      we need to source the virtio Kconfig outside of the virtualization
      scope too.
      
      Moreover, some architectures might use virtio for both virtualization
      and inter-processor communications, so directly sourcing virtio
      might yield unexpected results due to conflicting selections.
      
      The simple solution offered by this patch is to always source virtio's
      Kconfig in drivers/Kconfig, and remove it from the appropriate arch
      Kconfigs. Additionally, a virtio menu entry has been added so virtio
      drivers don't show up in the general drivers menu.
      
      This way anyone can use virtio, though it's arguably less accessible
      (and neat!) for virtualization users now.
      
      Note: some architectures (mips and sh) seem to have a VIRTUALIZATION
      menu merely for sourcing virtio's Kconfig, so that menu is removed too.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      e7254219
    • J
      asm-generic: move archictures to common delay.h · a4e05276
      Jonas Bonn 提交于
      This patch moves the in-tree architectures that were using the 'generic'
      delay.h over to using the header file in asm-generic.
      
      This is not done using the generic-y mechanism as none of these arch's
      have started using that mechanism yet.  This is a trivial change to make
      later when the arch begins using generic-y.
      
      Note the subtle change to the avr32 and SH architectures where the argument
      to __const_udelay was previously using the rounded down constant value
      instead of the rounded up value.
      Signed-off-by: NJonas Bonn <jonas@southpole.se>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
      a4e05276
  9. 22 7月, 2011 3 次提交