Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • X xcap-capability-linux
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • xcap
  • xcap-capability-linux
  • Repository
  • xcap-capability-linux
  • drivers
  • net
  • ethernet
  • ibm
  • ehea
  • ehea.h
Find file Blame History Permalink
  • Anton Blanchard's avatar
    ehea: Allocate large enough skbs to avoid partial cacheline DMA writes · 945db2d4
    Anton Blanchard authored Oct 14, 2011
    
    
    The ehea adapter has a mode where it will avoid partial cacheline DMA
    writes on receive by always padding packets to fall on a cacheline
    boundary.
    
    Unfortunately we currently aren't allocating enough space for a full
    ethernet MTU packet to be rounded up, so this optimisation doesn't hit.
    
    It's unfortunate that the next largest packet size exposed by the
    hypervisor interface is 2kB, meaning our skb allocation comes out of a
    4kB SLAB. However the performance increase due to this optimisation is
    quite large and my TCP stream numbers increase from 900MB to 1000MB/sec.
    
    Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
    Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    945db2d4