From: Jesper Dangaard Brouer <brouer@redhat.com> To: netdev@vger.kernel.org, Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org>, tom@herbertland.com, Alexander Duyck <alexander.duyck@gmail.com>, alexei.starovoitov@gmail.com, linux-mm@kvack.org, Jesper Dangaard Brouer <brouer@redhat.com>, Christoph Lameter <cl@linux.com>, "David S. Miller" <davem@davemloft.net> Subject: [net-next PATCH V2 0/3] net: mitigating kmem_cache free slowpath Date: Mon, 08 Feb 2016 13:14:54 +0100 [thread overview] Message-ID: <20160208121328.8860.67014.stgit@localhost> (raw) In-Reply-To: <20160207.142526.1252110536030712971.davem@davemloft.net> 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(-)
WARNING: multiple messages have this Message-ID (diff)
From: Jesper Dangaard Brouer <brouer@redhat.com> To: netdev@vger.kernel.org, Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org>, tom@herbertland.com, Alexander Duyck <alexander.duyck@gmail.com>, alexei.starovoitov@gmail.com, linux-mm@kvack.org, Jesper Dangaard Brouer <brouer@redhat.com>, Christoph Lameter <cl@linux.com>, "David S. Miller" <davem@davemloft.net> Subject: [net-next PATCH V2 0/3] net: mitigating kmem_cache free slowpath Date: Mon, 08 Feb 2016 13:14:54 +0100 [thread overview] Message-ID: <20160208121328.8860.67014.stgit@localhost> (raw) In-Reply-To: <20160207.142526.1252110536030712971.davem@davemloft.net> 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(-) -- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-02-08 12:14 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-10-23 12:46 [PATCH 0/4] net: mitigating kmem_cache slowpath for network stack in NAPI context Jesper Dangaard Brouer 2015-10-23 12:46 ` Jesper Dangaard Brouer 2015-10-23 12:46 ` [PATCH 1/4] net: bulk free infrastructure for NAPI context, use napi_consume_skb Jesper Dangaard Brouer 2015-10-23 12:46 ` Jesper Dangaard Brouer 2015-10-23 12:46 ` [PATCH 2/4] net: bulk free SKBs that were delay free'ed due to IRQ context Jesper Dangaard Brouer 2015-10-23 12:46 ` [PATCH 3/4] ixgbe: bulk free SKBs during TX completion cleanup cycle Jesper Dangaard Brouer 2015-10-23 12:46 ` Jesper Dangaard Brouer 2015-10-23 12:46 ` [PATCH 4/4] net: bulk alloc and reuse of SKBs in NAPI context Jesper Dangaard Brouer 2015-10-27 1:09 ` [PATCH 0/4] net: mitigating kmem_cache slowpath for network stack " David Miller 2016-02-02 21:11 ` [net-next PATCH 00/11] net: mitigating kmem_cache slowpath and BoF discussion patches Jesper Dangaard Brouer 2016-02-02 21:11 ` [net-next PATCH 01/11] net: bulk free infrastructure for NAPI context, use napi_consume_skb Jesper Dangaard Brouer 2016-02-02 21:11 ` [net-next PATCH 02/11] net: bulk free SKBs that were delay free'ed due to IRQ context Jesper Dangaard Brouer 2016-02-02 21:11 ` [net-next PATCH 03/11] ixgbe: bulk free SKBs during TX completion cleanup cycle Jesper Dangaard Brouer 2016-02-02 21:12 ` [net-next PATCH 04/11] net: bulk alloc and reuse of SKBs in NAPI context Jesper Dangaard Brouer 2016-02-03 0:52 ` Alexei Starovoitov 2016-02-03 10:38 ` Jesper Dangaard Brouer 2016-02-02 21:12 ` [net-next PATCH 05/11] mlx5: use napi_*_skb APIs to get bulk alloc and free Jesper Dangaard Brouer 2016-02-02 21:13 ` [net-next PATCH 06/11] RFC: mlx5: RX bulking or bundling of packets before calling network stack Jesper Dangaard Brouer 2016-02-09 11:57 ` Saeed Mahameed 2016-02-10 20:26 ` Jesper Dangaard Brouer 2016-02-16 0:01 ` Saeed Mahameed 2016-02-02 21:13 ` [net-next PATCH 07/11] net: introduce napi_alloc_skb_hint() for more use-cases Jesper Dangaard Brouer 2016-02-02 22:29 ` kbuild test robot 2016-02-02 21:14 ` [net-next PATCH 08/11] mlx5: hint the NAPI alloc skb API about the expected bulk size Jesper Dangaard Brouer 2016-02-02 21:14 ` [net-next PATCH 09/11] RFC: dummy: bulk free SKBs Jesper Dangaard Brouer 2016-02-02 21:15 ` [net-next PATCH 10/11] RFC: net: API for RX handover of multiple SKBs to stack Jesper Dangaard Brouer 2016-02-02 21:15 ` [net-next PATCH 11/11] RFC: net: RPS bulk enqueue to backlog Jesper Dangaard Brouer 2016-02-07 19:25 ` [net-next PATCH 00/11] net: mitigating kmem_cache slowpath and BoF discussion patches David Miller 2016-02-08 12:14 ` Jesper Dangaard Brouer [this message] 2016-02-08 12:14 ` [net-next PATCH V2 0/3] net: mitigating kmem_cache free slowpath Jesper Dangaard Brouer 2016-02-08 12:14 ` [net-next PATCH V2 1/3] net: bulk free infrastructure for NAPI context, use napi_consume_skb Jesper Dangaard Brouer 2016-02-08 12:15 ` [net-next PATCH V2 2/3] net: bulk free SKBs that were delay free'ed due to IRQ context Jesper Dangaard Brouer 2016-02-08 12:15 ` [net-next PATCH V2 3/3] ixgbe: bulk free SKBs during TX completion cleanup cycle Jesper Dangaard Brouer 2016-02-11 16:59 ` [net-next PATCH V2 0/3] net: mitigating kmem_cache free slowpath David Miller 2016-02-13 11:12 ` Tilman Schmidt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20160208121328.8860.67014.stgit@localhost \ --to=brouer@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=alexander.duyck@gmail.com \ --cc=alexei.starovoitov@gmail.com \ --cc=cl@linux.com \ --cc=davem@davemloft.net \ --cc=jeffrey.t.kirsher@intel.com \ --cc=linux-mm@kvack.org \ --cc=netdev@vger.kernel.org \ --cc=tom@herbertland.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.