From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: intel-wired-lan@lists.osuosl.org
Cc: Alexander Lobakin <aleksander.lobakin@intel.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
nex.sw.ncis.osdt.itp.upstreaming@intel.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH RFC iwl-next 00/12] idpf: XDP chapter I: convert Rx to libeth
Date: Fri, 10 May 2024 17:26:08 +0200 [thread overview]
Message-ID: <20240510152620.2227312-1-aleksander.lobakin@intel.com> (raw)
Applies on top of "idpf: don't enable NAPI and interrupts prior to
allocating Rx buffers" from Tony's tree.
Sent as RFC as we're at the end of the development cycle and several
kdocs are messed up. I'll fix them when sending non-RFC after the window
opens.
XDP for idpf is currently 5 chapters:
* convert Rx to libeth (this);
* convert Tx and stats to libeth;
* generic XDP and XSk code changes;
* actual XDP for idpf via libeth_xdp;
* XSk for idpf (^).
Part I does the following:
* splits &idpf_queue into 4 (RQ, SQ, FQ, CQ) and puts them on a diet;
* ensures optimal cacheline placement, strictly asserts CL sizes;
* moves currently unused/dead singleq mode out of line;
* reuses libeth's Rx ptype definitions and helpers;
* uses libeth's Rx buffer management for both header and payload;
* eliminates memcpy()s and coherent DMA uses on hotpath, uses
napi_build_skb() instead of in-place short skb allocation.
Most idpf patches, except for the queue split, removes more lines
than adds.
Expect far better memory utilization and +5-8% on Rx depending on
the case (+17% on skb XDP_DROP :>).
Alexander Lobakin (12):
libeth: add cacheline / struct alignment helpers
idpf: stop using macros for accessing queue descriptors
idpf: split &idpf_queue into 4 strictly-typed queue structures
idpf: avoid bloating &idpf_q_vector with big %NR_CPUS
idpf: strictly assert cachelines of queue and queue vector structures
idpf: merge singleq and splitq &net_device_ops
idpf: compile singleq code only under default-n CONFIG_IDPF_SINGLEQ
idpf: reuse libeth's definitions of parsed ptype structures
idpf: remove legacy Page Pool Ethtool stats
libeth: support different types of buffers for Rx
idpf: convert header split mode to libeth + napi_build_skb()
idpf: use libeth Rx buffer management for payload buffer
drivers/net/ethernet/intel/Kconfig | 13 +-
drivers/net/ethernet/intel/idpf/Kconfig | 25 +
drivers/net/ethernet/intel/idpf/Makefile | 3 +-
drivers/net/ethernet/intel/idpf/idpf.h | 10 +-
.../net/ethernet/intel/idpf/idpf_lan_txrx.h | 2 +
drivers/net/ethernet/intel/idpf/idpf_txrx.h | 746 ++++-----
include/net/libeth/cache.h | 64 +
include/net/libeth/rx.h | 19 +
.../net/ethernet/intel/idpf/idpf_ethtool.c | 152 +-
drivers/net/ethernet/intel/idpf/idpf_lib.c | 88 +-
drivers/net/ethernet/intel/idpf/idpf_main.c | 1 +
.../ethernet/intel/idpf/idpf_singleq_txrx.c | 311 ++--
drivers/net/ethernet/intel/idpf/idpf_txrx.c | 1405 +++++++++--------
.../net/ethernet/intel/idpf/idpf_virtchnl.c | 175 +-
drivers/net/ethernet/intel/libeth/rx.c | 122 +-
15 files changed, 1726 insertions(+), 1410 deletions(-)
create mode 100644 drivers/net/ethernet/intel/idpf/Kconfig
create mode 100644 include/net/libeth/cache.h
--
2.45.0
next reply other threads:[~2024-05-10 15:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-10 15:26 Alexander Lobakin [this message]
2024-05-10 15:26 ` [PATCH RFC iwl-next 01/12] libeth: add cacheline / struct alignment helpers Alexander Lobakin
2024-05-10 15:26 ` [PATCH RFC iwl-next 02/12] idpf: stop using macros for accessing queue descriptors Alexander Lobakin
2024-05-16 17:45 ` Mina Almasry
2024-05-10 15:26 ` [PATCH RFC iwl-next 03/12] idpf: split &idpf_queue into 4 strictly-typed queue structures Alexander Lobakin
2024-05-10 15:26 ` [PATCH RFC iwl-next 04/12] idpf: avoid bloating &idpf_q_vector with big %NR_CPUS Alexander Lobakin
2024-05-10 15:26 ` [PATCH RFC iwl-next 05/12] idpf: strictly assert cachelines of queue and queue vector structures Alexander Lobakin
2024-05-10 15:26 ` [PATCH RFC iwl-next 06/12] idpf: merge singleq and splitq &net_device_ops Alexander Lobakin
2024-05-10 15:26 ` [PATCH RFC iwl-next 07/12] idpf: compile singleq code only under default-n CONFIG_IDPF_SINGLEQ Alexander Lobakin
2024-05-14 2:01 ` [Intel-wired-lan] " Tantilov, Emil S
2024-05-16 10:40 ` Alexander Lobakin
2024-05-10 15:26 ` [PATCH RFC iwl-next 08/12] idpf: reuse libeth's definitions of parsed ptype structures Alexander Lobakin
2024-05-10 16:22 ` Mina Almasry
2024-05-10 15:26 ` [PATCH RFC iwl-next 09/12] idpf: remove legacy Page Pool Ethtool stats Alexander Lobakin
2024-05-10 15:26 ` [PATCH RFC iwl-next 10/12] libeth: support different types of buffers for Rx Alexander Lobakin
2024-05-10 15:26 ` [PATCH RFC iwl-next 11/12] idpf: convert header split mode to libeth + napi_build_skb() Alexander Lobakin
2024-05-10 15:26 ` [PATCH RFC iwl-next 12/12] idpf: use libeth Rx buffer management for payload buffer Alexander Lobakin
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=20240510152620.2227312-1-aleksander.lobakin@intel.com \
--to=aleksander.lobakin@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nex.sw.ncis.osdt.itp.upstreaming@intel.com \
--cc=pabeni@redhat.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).