From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id CD471A2E1B for ; Wed, 4 Sep 2019 12:30:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C6ED91ED68; Wed, 4 Sep 2019 12:30:13 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id EE4ED1ED66 for ; Wed, 4 Sep 2019 12:30:11 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2019 03:30:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,465,1559545200"; d="scan'208";a="185074678" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga003.jf.intel.com with ESMTP; 04 Sep 2019 03:30:08 -0700 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.187]) by IRSMSX107.ger.corp.intel.com ([169.254.10.55]) with mapi id 14.03.0439.000; Wed, 4 Sep 2019 11:30:07 +0100 From: "Loftus, Ciara" To: "Ye, Xiaolong" CC: "dev@dpdk.org" , "Richardson, Bruce" , "Laatz, Kevin" Thread-Topic: [PATCH] net/af_xdp: enable support for unaligned umem chunks Thread-Index: AQHVXnr4Twm2A1sQNkidp5qfGLRRc6caeMIAgADhVEA= Date: Wed, 4 Sep 2019 10:30:07 +0000 Message-ID: <74F120C019F4A64C9B78E802F6AD4CC2791F9E2B@IRSMSX106.ger.corp.intel.com> References: <20190829150259.22206-1-ciara.loftus@intel.com> <20190903220214.GA27520@intel.com> In-Reply-To: <20190903220214.GA27520@intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2RiMmJmODctM2Q1My00YTdjLWE1OTktZWJiZDZjOGVhODFlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiUDh0aWgxRzIzNFJVQjluQktMN3F0XC82TEwydEpjZVdTelRWM0I3MjIzZER5WVN5aVwvNDdyQ0FYbzc5NXp1cFhGIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] net/af_xdp: enable support for unaligned umem chunks X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" >=20 > Hi, Ciara >=20 > Thanks for the patch, the performance number is quite impressive. >=20 > 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 > >Signed-off-by: Kevin Laatz > >--- > > 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. > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > >+* **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. > >+ >=20 > Better to document the kernel dependency in the af_xdp.rst. Will do. >=20 > > > > Removed Items > > ------------- > >@@ -69,6 +76,8 @@ Removed Items > > Also, make sure to start the actual text at the margin. > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > >+* 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 =3D &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 =3D 0; i < reserve_size; i++) { > >+ struct rte_mbuf *mbuf; > >+ __u64 *fq_addr; > >+ uint64_t addr; > >+ > >+ mbuf =3D rte_pktmbuf_alloc(umem->mb_pool); > >+ if (unlikely(mbuf =3D=3D NULL)) > >+ break; >=20 > If this rare case happens, not all of the reserved slots of fq will be fi= lled 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 >=20 > Thanks, > Xiaolong >=20 > >+