lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1272906384.2226.80.camel@edumazet-laptop>
Date:	Mon, 03 May 2010 19:06:24 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev <netdev@...r.kernel.org>
Subject: [RFC] network driver skb allocations

Some performance idea about drivers and skb allocations :

-----------------------------------------------------------------------------------------------------------
   PerfTop:     954 irqs/sec  kernel:99.5% [1000Hz cycles],  (all, cpu: 0)
-----------------------------------------------------------------------------------------------------------

             samples  pcnt function                      DSO
             _______ _____ _____________________________ _________________

             2378.00 16.3% __alloc_skb                   [kernel.kallsyms]
             1962.00 13.5% eth_type_trans                [kernel.kallsyms]
             1472.00 10.1% __kmalloc_track_caller        [kernel.kallsyms]
              991.00  6.8% __slab_alloc                  [kernel.kallsyms]
              938.00  6.4% _raw_spin_lock                [kernel.kallsyms]
              914.00  6.3% __netdev_alloc_skb            [kernel.kallsyms]
              876.00  6.0% kmem_cache_alloc              [kernel.kallsyms]
              519.00  3.6% tg3_poll_work                 [kernel.kallsyms]
              416.00  2.9% tg3_read32                    [kernel.kallsyms]
              394.00  2.7% get_rps_cpu                   [kernel.kallsyms]

Current logic for drivers is to :

allocate skbs (sk_buff + data) and put them in a ring buffer.

When rx interrupt comes, get the skb and give it to stack.

Allocate a new skb (sk_buff + data) and put it in rx fat ring buffer (511 entries for tg3 )

This is suboptimal, because sk_buff will probably be cold 512 rx later...
Also, NUMA info might be wrong : sk_buff should be allocated on current node,
not on the device preferred node.

Drivers should allocate only the data part for NIC, and at the time of interrupt,
allocate the skb_buff and link it to buffer filled by NIC.

With a prefetch(first_cache_line_of_data) before doing sk_buff allocation and init,
eth_type_trans() / get_rps_cpus() would be much faster.






--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ