From: "Loftus, Ciara" <ciara.loftus@intel.com>
To: "Ye, Xiaolong" <xiaolong.ye@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Laatz, Kevin" <kevin.laatz@intel.com>
Subject: Re: [dpdk-dev] [PATCH] net/af_xdp: enable support for unaligned umem chunks
Date: Wed, 4 Sep 2019 10:30:07 +0000 [thread overview]
Message-ID: <74F120C019F4A64C9B78E802F6AD4CC2791F9E2B@IRSMSX106.ger.corp.intel.com> (raw)
In-Reply-To: <20190903220214.GA27520@intel.com>
>
> Hi, Ciara
>
> Thanks for the patch, the performance number is quite impressive.
>
> On 08/29, Ciara Loftus wrote:
> >This patch enables the unaligned chunks feature for AF_XDP which allows
> >chunks to be placed at arbitrary places in the umem, as opposed to them
> >being required to be aligned to 2k. This allows for DPDK application
> >mempools to be mapped directly into the umem and in turn enable zero
> >copy transfer between umem and the PMD.
> >
> >This patch replaces the zero copy via external mbuf mechanism
> >introduced in commit e9ff8bb71943 ("net/af_xdp: enable zero copy by
> external mbuf").
> >The pmd_zero copy vdev argument is also removed as now the PMD will
> >auto-detect presence of the unaligned chunks feature and enable it if
> >so and otherwise fall back to copy mode if not detected.
> >
> >When enabled, this feature significantly improves single-core
> >performance of the PMD.
> >
> >Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> >Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> >---
> > doc/guides/nics/af_xdp.rst | 1 -
> > doc/guides/rel_notes/release_19_11.rst | 9 +
> > drivers/net/af_xdp/rte_eth_af_xdp.c | 304 ++++++++++++++++++-------
> > 3 files changed, 231 insertions(+), 83 deletions(-)
> >
> >diff --git a/doc/guides/nics/af_xdp.rst b/doc/guides/nics/af_xdp.rst
> >index ec46f08f0..48dd788ac 100644
> >--- a/doc/guides/nics/af_xdp.rst
> >+++ b/doc/guides/nics/af_xdp.rst
> >@@ -35,7 +35,6 @@ The following options can be provided to set up an
> af_xdp port in DPDK.
> > * ``iface`` - name of the Kernel interface to attach to (required);
> > * ``start_queue`` - starting netdev queue id (optional, default 0);
> > * ``queue_count`` - total netdev queue number (optional, default 1);
> >-* ``pmd_zero_copy`` - enable zero copy or not (optional, default 0);
> >
> > Prerequisites
> > -------------
> >diff --git a/doc/guides/rel_notes/release_19_11.rst
> >b/doc/guides/rel_notes/release_19_11.rst
> >index 8490d897c..28a8e5372 100644
> >--- a/doc/guides/rel_notes/release_19_11.rst
> >+++ b/doc/guides/rel_notes/release_19_11.rst
> >@@ -56,6 +56,13 @@ New Features
> > Also, make sure to start the actual text at the margin.
> >
> =========================================================
> >
> >+* **Updated the AF_XDP PMD.**
> >+
> >+ Updated the AF_XDP PMD. The new features include:
> >+
> >+ * Enabled zero copy between application mempools and UMEM by
> enabling the
> >+ XDP_UMEM_UNALIGNED_CHUNKS UMEM flag.
> >+
>
> Better to document the kernel dependency in the af_xdp.rst.
Will do.
>
> >
> > Removed Items
> > -------------
> >@@ -69,6 +76,8 @@ Removed Items
> > Also, make sure to start the actual text at the margin.
> >
> =========================================================
> >
> >+* Removed AF_XDP pmd_zero copy vdev argument. Support is now auto-
> detected.
> >+
> >
> > API Changes
> > -----------
> >diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
> >b/drivers/net/af_xdp/rte_eth_af_xdp.c
> >index 41ed5b2af..7956d5778 100644
> >--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
> >+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
> [snip]
> > reserve_fill_queue(struct xsk_umem_info *umem, uint16_t reserve_size)
> >{
> > struct xsk_ring_prod *fq = &umem->fq;
> >- void *addrs[reserve_size];
> > uint32_t idx;
> > uint16_t i;
> >+#if defined(XDP_UMEM_UNALIGNED_CHUNK_FLAG)
> >+
> >+ if (unlikely(!xsk_ring_prod__reserve(fq, reserve_size, &idx))) {
> >+ AF_XDP_LOG(DEBUG, "Failed to reserve enough fq
> descs.\n");
> >+ return -1;
> >+ }
> >+
> >+ for (i = 0; i < reserve_size; i++) {
> >+ struct rte_mbuf *mbuf;
> >+ __u64 *fq_addr;
> >+ uint64_t addr;
> >+
> >+ mbuf = rte_pktmbuf_alloc(umem->mb_pool);
> >+ if (unlikely(mbuf == NULL))
> >+ break;
>
> If this rare case happens, not all of the reserved slots of fq will be filled with
> proper mbuf addr, then we just call xsk_ring_prod__submit(fq,
> reserve_size) to let kernel receive packets on these addrs, something
> unexpected may happen.
Good catch. I'll fix this in the v2.
Thanks!
Ciara
>
> Thanks,
> Xiaolong
>
> >+
prev parent reply other threads:[~2019-09-04 10:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-29 15:02 Ciara Loftus
2019-08-30 7:47 ` Loftus, Ciara
2019-08-30 16:07 ` William Tu
2019-09-02 8:48 ` Loftus, Ciara
2019-09-02 8:55 ` Loftus, Ciara
2019-09-02 14:44 ` William Tu
2019-09-03 22:02 ` Ye Xiaolong
2019-09-04 10:30 ` Loftus, Ciara [this message]
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=74F120C019F4A64C9B78E802F6AD4CC2791F9E2B@IRSMSX106.ger.corp.intel.com \
--to=ciara.loftus@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=kevin.laatz@intel.com \
--cc=xiaolong.ye@intel.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 NNTP newsgroup(s).