All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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: link
Be 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.