Re: [net-next PATCH V2 0/3] net: mitigating kmem_cache free slowpath

[Tilman Schmidt]

Hi Jesper,

Am 08.02.2016 um 13:14 schrieb Jesper Dangaard Brouer:
> Introduce new API napi_consume_skb(), that hides/handles bulk freeing
> for the caller.  The drivers simply need to use this call when freeing
> SKBs in NAPI context, e.g. replacing their calles to dev_kfree_skb() /
> dev_consume_skb_any().

Would you mind adding a kerneldoc comment for the new API function?

Thanks,
Tilman

-- 
Tilman Schmidt  E-Mail: til...@imap.cc
Bonn, Germany
Nous, on a des fleurs et des bougies pour nous protéger.



signature.asc
Description: OpenPGP digital signature

Re: [net-next PATCH V2 0/3] net: mitigating kmem_cache free slowpath

[David Miller]

From: Jesper Dangaard Brouer 
Date: Mon, 08 Feb 2016 13:14:54 +0100

> This patchset is the first real use-case for kmem_cache bulk _free_.
> The use of bulk _alloc_ is NOT included in this patchset. The full use
> have previously been posted here [1].
> 
> The bulk free side have the largest benefit for the network stack
> use-case, because network stack is hitting the kmem_cache/SLUB
> slowpath when freeing SKBs, due to the amount of outstanding SKBs.
> This is solved by using the new API kmem_cache_free_bulk().
> 
> Introduce new API napi_consume_skb(), that hides/handles bulk freeing
> for the caller.  The drivers simply need to use this call when freeing
> SKBs in NAPI context, e.g. replacing their calles to dev_kfree_skb() /
> dev_consume_skb_any().
> 
> Driver ixgbe is the first user of this new API.
> 
> [1] http://thread.gmane.org/gmane.linux.network/384302/focus=397373

Series applied, thanks.

[net-next PATCH V2 0/3] net: mitigating kmem_cache free slowpath

[Jesper Dangaard Brouer]

This patchset is the first real use-case for kmem_cache bulk _free_.
The use of bulk _alloc_ is NOT included in this patchset. The full use
have previously been posted here [1].

The bulk free side have the largest benefit for the network stack
use-case, because network stack is hitting the kmem_cache/SLUB
slowpath when freeing SKBs, due to the amount of outstanding SKBs.
This is solved by using the new API kmem_cache_free_bulk().

Introduce new API napi_consume_skb(), that hides/handles bulk freeing
for the caller.  The drivers simply need to use this call when freeing
SKBs in NAPI context, e.g. replacing their calles to dev_kfree_skb() /
dev_consume_skb_any().

Driver ixgbe is the first user of this new API.

[1] http://thread.gmane.org/gmane.linux.network/384302/focus=397373

---

Jesper Dangaard Brouer (3):
  net: bulk free infrastructure for NAPI context, use napi_consume_skb
  net: bulk free SKBs that were delay free'ed due to IRQ context
  ixgbe: bulk free SKBs during TX completion cleanup cycle


 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |6 +-
 include/linux/skbuff.h|4 +
 net/core/dev.c|9 ++-
 net/core/skbuff.c |   87 +++--
 4 files changed, 96 insertions(+), 10 deletions(-)

--