From: Alexander Lobakin <alexandr.lobakin@intel.com> To: intel-wired-lan@lists.osuosl.org Cc: Alexander Lobakin <alexandr.lobakin@intel.com>, Tony Nguyen <anthony.l.nguyen@intel.com>, Jesse Brandeburg <jesse.brandeburg@intel.com>, Maciej Fijalkowski <maciej.fijalkowski@intel.com>, Michal Swiatkowski <michal.swiatkowski@linux.intel.com>, "David S. Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH net-next 0/9] intel: switch to napi_build_skb() Date: Tue, 23 Nov 2021 18:18:31 +0100 [thread overview] Message-ID: <20211123171840.157471-1-alexandr.lobakin@intel.com> (raw) napi_build_skb() I introduced earlier this year ([0]) aims to decrease MM pressure and the overhead from in-place kmem_cache_alloc() on each Rx entry processing by decaching skbuff_heads from NAPI per-cpu cache filled prior to that by napi_consume_skb() (so it is sort of a direct shortcut for free -> mm -> alloc cycle). Currently, no in-tree drivers use it. Switch all Intel Ethernet drivers to it to get slight-to-medium perf boosts depending on the frame size. ice driver, 50 Gbps link, pktgen + XDP_PASS (local in) sample: frame_size/nthreads 64/42 128/20 256/8 512/4 1024/2 1532/1 net-next (Kpps) 46062 34654 18248 9830 5343 2714 series 47438 34708 18330 9875 5435 2777 increase 2.9% 0.15% 0.45% 0.46% 1.72% 2.32% Additionally, e1000's been switched to napi_consume_skb() as it's safe and works fine there, and there's no point in napi_build_skb() without paired NAPI cache feeding point. [0] https://lore.kernel.org/all/20210213141021.87840-1-alobakin@pm.me Alexander Lobakin (9): e1000: switch to napi_consume_skb() e1000: switch to napi_build_skb() i40e: switch to napi_build_skb() iavf: switch to napi_build_skb() ice: switch to napi_build_skb() igb: switch to napi_build_skb() igc: switch to napi_build_skb() ixgbe: switch to napi_build_skb() ixgbevf: switch to napi_build_skb() drivers/net/ethernet/intel/e1000/e1000_main.c | 14 ++++++++------ drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +- drivers/net/ethernet/intel/iavf/iavf_txrx.c | 2 +- drivers/net/ethernet/intel/ice/ice_txrx.c | 2 +- drivers/net/ethernet/intel/igb/igb_main.c | 2 +- drivers/net/ethernet/intel/igc/igc_main.c | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +- drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +- 8 files changed, 15 insertions(+), 13 deletions(-) -- 2.33.1
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Lobakin <alexandr.lobakin@intel.com> To: intel-wired-lan@osuosl.org Subject: [Intel-wired-lan] [PATCH net-next 0/9] intel: switch to napi_build_skb() Date: Tue, 23 Nov 2021 18:18:31 +0100 [thread overview] Message-ID: <20211123171840.157471-1-alexandr.lobakin@intel.com> (raw) napi_build_skb() I introduced earlier this year ([0]) aims to decrease MM pressure and the overhead from in-place kmem_cache_alloc() on each Rx entry processing by decaching skbuff_heads from NAPI per-cpu cache filled prior to that by napi_consume_skb() (so it is sort of a direct shortcut for free -> mm -> alloc cycle). Currently, no in-tree drivers use it. Switch all Intel Ethernet drivers to it to get slight-to-medium perf boosts depending on the frame size. ice driver, 50 Gbps link, pktgen + XDP_PASS (local in) sample: frame_size/nthreads 64/42 128/20 256/8 512/4 1024/2 1532/1 net-next (Kpps) 46062 34654 18248 9830 5343 2714 series 47438 34708 18330 9875 5435 2777 increase 2.9% 0.15% 0.45% 0.46% 1.72% 2.32% Additionally, e1000's been switched to napi_consume_skb() as it's safe and works fine there, and there's no point in napi_build_skb() without paired NAPI cache feeding point. [0] https://lore.kernel.org/all/20210213141021.87840-1-alobakin at pm.me Alexander Lobakin (9): e1000: switch to napi_consume_skb() e1000: switch to napi_build_skb() i40e: switch to napi_build_skb() iavf: switch to napi_build_skb() ice: switch to napi_build_skb() igb: switch to napi_build_skb() igc: switch to napi_build_skb() ixgbe: switch to napi_build_skb() ixgbevf: switch to napi_build_skb() drivers/net/ethernet/intel/e1000/e1000_main.c | 14 ++++++++------ drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +- drivers/net/ethernet/intel/iavf/iavf_txrx.c | 2 +- drivers/net/ethernet/intel/ice/ice_txrx.c | 2 +- drivers/net/ethernet/intel/igb/igb_main.c | 2 +- drivers/net/ethernet/intel/igc/igc_main.c | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +- drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +- 8 files changed, 15 insertions(+), 13 deletions(-) -- 2.33.1
next reply other threads:[~2021-11-23 17:24 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-23 17:18 Alexander Lobakin [this message] 2021-11-23 17:18 ` [Intel-wired-lan] [PATCH net-next 0/9] intel: switch to napi_build_skb() Alexander Lobakin 2021-11-23 17:18 ` [PATCH net-next 1/9] e1000: switch to napi_consume_skb() Alexander Lobakin 2021-11-23 17:18 ` [Intel-wired-lan] " Alexander Lobakin 2021-12-28 0:06 ` Brelinski, Tony 2021-12-28 0:06 ` Brelinski, Tony 2021-11-23 17:18 ` [PATCH net-next 2/9] e1000: switch to napi_build_skb() Alexander Lobakin 2021-11-23 17:18 ` [Intel-wired-lan] " Alexander Lobakin 2021-12-28 0:07 ` Brelinski, Tony 2021-12-28 0:07 ` Brelinski, Tony 2021-11-23 17:18 ` [PATCH net-next 3/9] i40e: " Alexander Lobakin 2021-11-23 17:18 ` [Intel-wired-lan] " Alexander Lobakin 2021-12-03 14:44 ` G, GurucharanX 2021-12-03 14:44 ` G, GurucharanX 2021-11-23 17:18 ` [PATCH net-next 4/9] iavf: " Alexander Lobakin 2021-11-23 17:18 ` [Intel-wired-lan] " Alexander Lobakin 2021-12-14 12:50 ` Jankowski, Konrad0 2021-12-14 12:50 ` Jankowski, Konrad0 2021-11-23 17:18 ` [PATCH net-next 5/9] ice: " Alexander Lobakin 2021-11-23 17:18 ` [Intel-wired-lan] " Alexander Lobakin 2021-12-07 10:03 ` G, GurucharanX 2021-12-07 10:03 ` G, GurucharanX 2021-11-23 17:18 ` [PATCH net-next 6/9] igb: " Alexander Lobakin 2021-11-23 17:18 ` [Intel-wired-lan] " Alexander Lobakin 2021-12-22 3:45 ` G, GurucharanX 2021-12-22 3:45 ` G, GurucharanX 2021-11-23 17:18 ` [PATCH net-next 7/9] igc: " Alexander Lobakin 2021-11-23 17:18 ` [Intel-wired-lan] " Alexander Lobakin 2021-12-08 8:15 ` Kraus, NechamaX 2021-12-08 8:15 ` Kraus, NechamaX 2021-11-23 17:18 ` [PATCH net-next 8/9] ixgbe: " Alexander Lobakin 2021-11-23 17:18 ` [Intel-wired-lan] " Alexander Lobakin 2021-12-03 14:45 ` G, GurucharanX 2021-12-03 14:45 ` G, GurucharanX 2021-11-23 17:18 ` [PATCH net-next 9/9] ixgbevf: " Alexander Lobakin 2021-11-23 17:18 ` [Intel-wired-lan] " Alexander Lobakin 2021-12-12 13:47 ` Jankowski, Konrad0 2021-12-12 13:47 ` Jankowski, Konrad0
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=20211123171840.157471-1-alexandr.lobakin@intel.com \ --to=alexandr.lobakin@intel.com \ --cc=anthony.l.nguyen@intel.com \ --cc=davem@davemloft.net \ --cc=intel-wired-lan@lists.osuosl.org \ --cc=jesse.brandeburg@intel.com \ --cc=kuba@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=maciej.fijalkowski@intel.com \ --cc=michal.swiatkowski@linux.intel.com \ --cc=netdev@vger.kernel.org \ /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.