Skip to content
  • Yunsheng Lin's avatar
    99f6b5fb
    net: hns3: use bounce buffer when rx page can not be reused · 99f6b5fb
    Yunsheng Lin authored
    
    
    Currently rx page will be reused to receive future packet when
    the stack releases the previous skb quickly. If the old page
    can not be reused, a new page will be allocated and mapped,
    which comsumes a lot of cpu when IOMMU is in the strict mode,
    especially when the application and irq/NAPI happens to run on
    the same cpu.
    
    So allocate a new frag to memcpy the data to avoid the costly
    IOMMU unmapping/mapping operation, and add "frag_alloc_err"
    and "frag_alloc" stats in "ethtool -S ethX" cmd.
    
    The throughput improves above 50% when running single thread of
    iperf using TCP when IOMMU is in strict mode and iperf shares the
    same cpu with irq/NAPI(rx_copybreak = 2048 and mtu = 1500).
    
    Signed-off-by: default avatarYunsheng Lin <linyunsheng@huawei.com>
    Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    99f6b5fb
    net: hns3: use bounce buffer when rx page can not be reused
    Yunsheng Lin authored
    
    
    Currently rx page will be reused to receive future packet when
    the stack releases the previous skb quickly. If the old page
    can not be reused, a new page will be allocated and mapped,
    which comsumes a lot of cpu when IOMMU is in the strict mode,
    especially when the application and irq/NAPI happens to run on
    the same cpu.
    
    So allocate a new frag to memcpy the data to avoid the costly
    IOMMU unmapping/mapping operation, and add "frag_alloc_err"
    and "frag_alloc" stats in "ethtool -S ethX" cmd.
    
    The throughput improves above 50% when running single thread of
    iperf using TCP when IOMMU is in strict mode and iperf shares the
    same cpu with irq/NAPI(rx_copybreak = 2048 and mtu = 1500).
    
    Signed-off-by: default avatarYunsheng Lin <linyunsheng@huawei.com>
    Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Loading