[Bug 920] [19.11.11] drivers/event/skeleton meson build failure with gcc 10.3.0 + debug on FreeBSD13.0/64
https://bugs.dpdk.org/show_bug.cgi?id=920 Bug ID: 920 Summary: [19.11.11] drivers/event/skeleton meson build failure with gcc 10.3.0 + debug on FreeBSD13.0/64 Product: DPDK Version: 19.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: daxuex@intel.com Target Milestone: --- [DPDK version]: 87ed66bd94 (HEAD, tag: v19.11.11, origin/19.11) [OS version]: FreeBSD 13.0-RELEASE, kernel 4.18.0 ICC19.1.1 gcc version 10.3.0 (FreeBSD Ports Collection) [Test Setup]: echo "#define RTE_LIBRTE_PMD_SKELETON_EVENTDEV_DEBUG 1" >>config/rte_config.h CC=gcc meson --werror -Denable_kmods=True -Dlibdir=lib -Dexamples=all --buildtype=debugoptimized --default-library=static x86_64-native-bsdapp-gcc+debug ninja -j 10 -C x86_64-native-bsdapp-gcc+debug [Notes] 1, Meson build 19.11 also failed with gcc10.3.0 [FreeBSD 13.0-RELEASE log as below] ninja: Entering directory `x86_64-native-bsdapp-gcc+debug' [1157/1594] Compiling C object drivers/libtmp_rte_pmd_skeleton_event.a.p/event_skeleton_skeleton_eventdev.c.o FAILED: drivers/libtmp_rte_pmd_skeleton_event.a.p/event_skeleton_skeleton_eventdev.c.o gcc -Idrivers/libtmp_rte_pmd_skeleton_event.a.p -Idrivers -I../drivers -Idrivers/event/skeleton -I../drivers/event/skeleton -Ilib/librte_eventdev -I../lib/librte_eventdev -I. -I.. -Iconfig -I../config -Ilib/librte_eal/common/include -I../lib/librte_eal/common/include -I../lib/librte_eal/freebsd/eal/include -Ilib/librte_eal/common -I../lib/librte_eal/common -Ilib/librte_eal/common/include/arch/x86 -I../lib/librte_eal/common/include/arch/x86 -Ilib/librte_eal -I../lib/librte_eal -Ilib/librte_kvargs -I../lib/librte_kvargs -Ilib/librte_ring -I../lib/librte_ring -Ilib/librte_ethdev -I../lib/librte_ethdev -Ilib/librte_net -I../lib/librte_net -Ilib/librte_mbuf -I../lib/librte_mbuf -Ilib/librte_mempool -I../lib/librte_mempool -Ilib/librte_meter -I../lib/librte_meter -Ilib/librte_hash -I../lib/librte_hash -Ilib/librte_timer -I../lib/librte_timer -Ilib/librte_cryptodev -I../lib/librte_cryptodev -Idrivers/bus/pci -I../drivers/bus/pci -I../drivers/bus/pci/bsd -Ilib/librte_pci -I../lib/librte_pci -Idrivers/bus/vdev -I../drivers/bus/vdev -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -O2 -g -include rte_config.h -Wextra -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-address-of-packed-member -Wno-packed-not-aligned -Wno-missing-field-initializers -Wno-zero-length-bounds -D_GNU_SOURCE -D__BSD_VISIBLE -fPIC -march=native -Wno-format-truncation -MD -MQ drivers/libtmp_rte_pmd_skeleton_event.a.p/event_skeleton_skeleton_eventdev.c.o -MF drivers/libtmp_rte_pmd_skeleton_event.a.p/event_skeleton_skeleton_eventdev.c.o.d -o drivers/libtmp_rte_pmd_skeleton_event.a.p/event_skeleton_skeleton_eventdev.c.o -c ../drivers/event/skeleton/skeleton_eventdev.c In file included from ../lib/librte_eal/common/include/rte_debug.h:17, from ../drivers/event/skeleton/skeleton_eventdev.c:14: ../drivers/event/skeleton/skeleton_eventdev.c: In function 'skeleton_eventdev_remove': ../lib/librte_eal/common/include/rte_log.h:336:3: error: '%s' directive argument is null [-Werror=format-overflow=] 336 | rte_log(RTE_LOG_ ## l, \ | ^~~~ 337 |RTE_LOGTYPE_ ## t, # t ": " __VA_ARGS__) | ../drivers/event/skeleton/skeleton_eventdev.h:13:2: note: in expansion of macro 'RTE_LOG' 13 | RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) | ^~~ ../drivers/event/skeleton/skeleton_eventdev.c:467:2: note: in expansion of macro 'PMD_DRV_LOG' 467 | PMD_DRV_LOG(INFO, "Closing %s on NUMA node %d", name, rte_socket_id()); | ^~~ cc1: all warnings being treated as errors [1166/1594] Compiling C object drivers/libtmp_rte_pmd_octeontx2_event.a.p/event_octeontx2_otx2_worker_dual.c.o ninja: build stopped: subcommand failed. -- You are receiving this mail because: You are the assignee for the bug.
[PATCH] net/bonding: fix RSS not work for bonding in DPDK21.11
>From 85c4e32996fc262dd6f69d0ce272ae8e8350 Mon Sep 17 00:00:00 2001
From: Yu Wenjun
Date: Wed, 12 Jan 2022 15:01:10 +0800
Subject: [PATCH] net/bonding: fix RSS not work for bonding
RSS don39t work when upgrade to DPDK21.11.
e.g.:
examples/bond/main.c:
conf:
static struct rte_eth_conf port_conf = {
.rxmode = {
.mq_mode = RTE_ETH_MQ_RX_NONE,
.split_hdr_size = 0,
},
.rx_adv_conf = {
.rss_conf = {
.rss_key = NULL,
.rss_hf = RTE_ETH_RSS_IP,
},
},
.txmode = {
.mq_mode = RTE_ETH_MQ_TX_NONE,
},
}
call chain:
rte_eth_bond_create()->rte_eth_dev_configure()->rte_eth_bond_slave_add()->rte_eth_dev_start()
Signed-off-by: Yu Wenjun
---
drivers/net/bonding/rte_eth_bond_pmd.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 84f4900ee5..31bcee15cf 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -3504,6 +3504,11 @@ bond_ethdev_configure(struct rte_eth_dev *dev)
if (dev->data->dev_conf.rxmode.mq_mode & RTE_ETH_MQ_RX_RSS) {
struct rte_eth_rss_conf *rss_conf =
&dev->data->dev_conf.rx_adv_conf.rss_conf
+
+ if (internals->rss_key_len == 0) {
+ internals->rss_key_len = sizeof(default_rss_key)
+ }
+
if (rss_conf->rss_key != NULL) {
if (internals->rss_key_len > rss_conf->rss_key_len) {
RTE_BOND_LOG(ERR, "Invalid rss key length(%u)",
--
2.32.0.windows.1
X710 VF not working anymore on DPDK 21.11
Hi All I use igb_uio or uio_pci_generic to bind X710 VF: :00:07.0 'XL710/X710 Virtual Function 154c' drv=igb_uio unused=iavf,uio_pci_generic The problem is that the device is not probed anymore by DPDK! It works perfectly with 20.11. Any advice? Thank-you Jean-Philippe Longeray Senior Solution Architect Expandium / Viavi Solutions +33 6 76 48 34 95
Re: [EXT] Re: [PATCH] common/cnxk: use cas with release semantics for batch alloc
On 1/12/2022 6:18 AM, Ruifeng Wang wrote:
-Original Message-
From: Ruifeng Wang
Sent: Wednesday, January 12, 2022 11:01 AM
To: Ferruh Yigit ; Ashwin Sekhar Thalakalath
Kottilveetil ; dev@dpdk.org; Honnappa Nagarahalli
Cc: Nithin Kumar Dabilpuram ;
jer...@marvell.com; Sunil Kumar Kori ; Satha
Koteswara Rao Kottidi ; Pavan Nikhilesh
Bhagavatula ; Kiran Kumar Kokkilagadda
; Satheesh Paul ;
Anoob Joseph ; Akhil Goyal ;
nd
Subject: RE: [EXT] Re: [PATCH] common/cnxk: use cas with release semantics
for batch alloc
-Original Message-
From: Ferruh Yigit
Sent: Tuesday, January 11, 2022 9:46 PM
To: Ashwin Sekhar Thalakalath Kottilveetil ;
dev@dpdk.org; Honnappa Nagarahalli ;
Ruifeng Wang
Cc: Nithin Kumar Dabilpuram ;
jer...@marvell.com; Sunil Kumar Kori ; Satha
Koteswara Rao Kottidi ; Pavan Nikhilesh
Bhagavatula ; Kiran Kumar Kokkilagadda
; Satheesh Paul ;
Anoob Joseph ; Akhil Goyal
Subject: Re: [EXT] Re: [PATCH] common/cnxk: use cas with release
semantics for batch alloc
On 1/11/2022 12:26 PM, Ashwin Sekhar Thalakalath Kottilveetil wrote:
CAS is compare and swap. CASL is compare and swap with release
semantics.
What does 'release semantics' mean? What is functional difference in both?
'release semantics' is semantics in memory ordering for store operations.
It ensures store-store ordering.
And some comments below.
But on CNXK platform, the functionality of CAS* instructions is
completely
different when it is done to specific addresses. These APIs are meant
for use for such special cases. These cannot be made ARM generic.
Ashwin Sekhar T K
-Original Message-
From: Ferruh Yigit
Sent: Tuesday, January 11, 2022 5:42 PM
To: Ashwin Sekhar Thalakalath Kottilveetil ;
dev@dpdk.org; Honnappa Nagarahalli
;
Ruifeng Wang (Arm Technology China)
Cc: Nithin Kumar Dabilpuram ; Jerin Jacob
Kollanukkaran ; Sunil Kumar Kori
; Satha Koteswara Rao Kottidi
; Pavan Nikhilesh Bhagavatula
; Kiran Kumar Kokkilagadda
; Satheesh Paul
;
Anoob Joseph ; Akhil Goyal
Subject: [EXT] Re: [PATCH] common/cnxk: use cas with release
semantics for batch alloc
External Email
---
--
- On 1/11/2022 12:08 PM, Ferruh Yigit wrote:
On 11/30/2021 5:45 AM, Ashwin Sekhar T K wrote:
Before issuing the batch alloc, we clear the first word of cache
lines so that NPA can update the status. Make sure that this line
clear is flushed before the batch alloc is issued.
Signed-off-by: Ashwin Sekhar T K
---
drivers/common/cnxk/roc_io.h | 12
drivers/common/cnxk/roc_io_generic.h | 9 +
drivers/common/cnxk/roc_npa.h | 2 +-
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/common/cnxk/roc_io.h
b/drivers/common/cnxk/roc_io.h index fe5f7f46d0..4f15503c29
100644
--- a/drivers/common/cnxk/roc_io.h
+++ b/drivers/common/cnxk/roc_io.h
@@ -78,6 +78,18 @@ roc_atomic64_cas(uint64_t compare, uint64_t
swap,
int64_t *ptr)
return compare;
}
+static __plt_always_inline uint64_t roc_atomic64_casl(uint64_t
+compare, uint64_t swap, int64_t *ptr) {
+ asm volatile(PLT_CPU_FEATURE_PREAMBLE
+ "casl %[compare], %[swap], [%[ptr]]\n"
+ : [compare] "+r"(compare)
+ : [swap] "r"(swap), [ptr] "r"(ptr)
+ : "memory");
+
out of curiosity, what is the "cas with release semantics"?
briefly, what is the difference between 'cas' and 'casl'?
+ Honnappa & Ruifeng,
Thanks Ferruh for adding me in this loop.
Isn't this API Arm wide, instead of being cnxk specific?
Does it make sense to make this API for arm and cnxk use from there?
Yes, CAS operation can be used Arm wide.
Generally, CAS is available via __atomic_compare_exchange/_n() compiler
built-ins. This is the way we use atomic in DPDK. So there is no need to add
another generic API.
Just to make my comment more clear.
For generic CAS operations, compiler built-ins can be used. No more API needed.
Given the special usage of the instructions in CNXK, the inline assembly here
is not intended to be a wrapper of
generic CAS operation but rather an interface to other hardware function. It
doesn't make sense to make it Arm wide.
Got it. Thanks for clarification, I will continue with the set.
Re: [EXT] Re: [PATCH] common/cnxk: use cas with release semantics for batch alloc
On 1/12/2022 3:01 AM, Ruifeng Wang wrote: -Original Message- From: Ferruh Yigit Sent: Tuesday, January 11, 2022 9:46 PM To: Ashwin Sekhar Thalakalath Kottilveetil ; dev@dpdk.org; Honnappa Nagarahalli ; Ruifeng Wang Cc: Nithin Kumar Dabilpuram ; jer...@marvell.com; Sunil Kumar Kori ; Satha Koteswara Rao Kottidi ; Pavan Nikhilesh Bhagavatula ; Kiran Kumar Kokkilagadda ; Satheesh Paul ; Anoob Joseph ; Akhil Goyal Subject: Re: [EXT] Re: [PATCH] common/cnxk: use cas with release semantics for batch alloc On 1/11/2022 12:26 PM, Ashwin Sekhar Thalakalath Kottilveetil wrote: CAS is compare and swap. CASL is compare and swap with release semantics. What does 'release semantics' mean? What is functional difference in both? 'release semantics' is semantics in memory ordering for store operations. It ensures store-store ordering. Thanks.
Re: X710 VF not working anymore on DPDK 21.11
On 1/12/2022 9:07 AM, Jean-Philippe Longeray wrote:
Hi All
I use igb_uio or uio_pci_generic to bind X710 VF:
:00:07.0 'XL710/X710 Virtual Function 154c' drv=igb_uio
unused=iavf,uio_pci_generic
The problem is that the device is not probed anymore by DPDK!
It works perfectly with 20.11.
Any advice?
Hi Jean-Philippe,
i40evf driver is removed in 21.11, in favor of iavf [1], if this is what you
mean.
But DPDK 'iavf' driver should probe it and same functionality should be
available.
cc'ed i40e maintainers as well.
[1]:
fe2a571c70cc ("net/i40e: remove i40evf")
Thank-you
Jean-Philippe *Longeray*
Senior Solution Architect
*Expandium / Viavi Solutions*
+33 6 76 48 34 95
RE: X710 VF not working anymore on DPDK 21.11
Thanks a lot!
Adding library librte_net_iavf.so solves the problem!
Nice!
JPL.
-Message d'origine-
De : Ferruh Yigit
Envoyé : mercredi 12 janvier 2022 10:28
À : Jean-Philippe Longeray
Cc : Qi Zhang ; Beilei Xing ;
dev@dpdk.org
Objet : Re: X710 VF not working anymore on DPDK 21.11
EXTERNAL EMAIL: Do not click links or open attachments unless you know and
trust the sender.
On 1/12/2022 9:07 AM, Jean-Philippe Longeray wrote:
> Hi All
>
> I use igb_uio or uio_pci_generic to bind X710 VF:
>
> :00:07.0 'XL710/X710 Virtual Function 154c' drv=igb_uio
> unused=iavf,uio_pci_generic
>
> The problem is that the device is not probed anymore by DPDK!
>
> It works perfectly with 20.11.
>
> Any advice?
Hi Jean-Philippe,
i40evf driver is removed in 21.11, in favor of iavf [1], if this is what you
mean.
But DPDK 'iavf' driver should probe it and same functionality should be
available.
cc'ed i40e maintainers as well.
[1]:
fe2a571c70cc ("net/i40e: remove i40evf")
>
> Thank-you
>
> Jean-Philippe *Longeray*
>
> Senior Solution Architect
>
> *Expandium / Viavi Solutions*
>
> +33 6 76 48 34 95
>
RE: 20.11.4 patches review and test
Hi Xueming, Happy new year! Sorry for the late reply - could you help revert the commit 2f2c2b5b7e7ae4942b4b3686bce2eb856fee447d Author: Przemyslaw Zegan Date: Wed Nov 3 15:08:23 2021 common/qat: fix queue pairs number As this patch relates to new feature introduce in 2021 and is not meant for 20.11 stable. Sorry for the problem caused. Regards, Fan > -Original Message- > From: Xueming(Steven) Li > Sent: Thursday, December 23, 2021 3:07 PM > To: Lin, Xueqin ; Jiang, YuX ; > sta...@dpdk.org > Cc: Stokes, Ian ; dev@dpdk.org; > abhishek.mara...@microsoft.com; NBU-Contact-Thomas Monjalon > (EXTERNAL) ; d...@linux.vnet.ibm.com; > ktray...@redhat.com; Peng, Yuan ; > jer...@marvell.com; Walker, Benjamin ; > Govindharajan, Hariprasad ; Raslan > Darawsheh ; bl...@debian.org; Mcnamara, John > ; Chen, Zhaoyan ; > Ali Alnubani ; hemant.agra...@nxp.com; > pezh...@redhat.com; juh...@microsoft.com; Xu, Qian Q > > Subject: Re: 20.11.4 patches review and test > > On Thu, 2021-12-16 at 06:40 +, Jiang, YuX wrote: > > > -Original Message- > > > From: Xueming(Steven) Li > > > Sent: Wednesday, December 15, 2021 10:45 PM > > > To: Lin, Xueqin ; Jiang, YuX > > > ; > > > sta...@dpdk.org > > > Cc: Stokes, Ian ; dev@dpdk.org; > > > ktray...@redhat.com; abhishek.mara...@microsoft.com; > > > d...@linux.vnet.ibm.com; NBU-Contact-Thomas Monjalon (EXTERNAL) > > > ; Peng, Yuan ; > > > jer...@marvell.com; Walker, Benjamin ; > > > bl...@debian.org; Raslan Darawsheh ; Mcnamara, > > > John ; Chen, Zhaoyan > > > ; Govindharajan, Hariprasad > > > ; Ali Alnubani > > > ; > > > hemant.agra...@nxp.com; pezh...@redhat.com; > juh...@microsoft.com; > > > Xu, Qian Q > > > Subject: Re: 20.11.4 patches review and test > > > > > > On Fri, 2021-12-10 at 11:35 +, Jiang, YuX wrote: > > > > > -Original Message- > > > > > From: Jiang, YuX > > > > > Sent: Thursday, December 9, 2021 6:01 PM > > > > > To: Xueming Li ; sta...@dpdk.org; Lin, > > > > > Xueqin > > > > > > > > > > Cc: dev@dpdk.org; Abhishek Marathe > > > > > ; > > > > > Ali Alnubani ; Walker, Benjamin > > > > > ; David Christensen > > > > > ; Govindharajan, Hariprasad > > > > > ; Hemant Agrawal > > > > > ; Stokes, Ian ; > > > > > Jerin > > > > > Jacob ; Mcnamara, John > > > > > ; Ju-Hyoung Lee > > > > > ; > > > > > Kevin Traynor ; Luca Boccassi > > > > > ; Pei Zhang ; Xu, Qian Q > > > > > ; Raslan Darawsheh ; > > > Thomas > > > > > Monjalon ; Peng, Yuan > > > ; > > > > > Chen, Zhaoyan > > > > > Subject: RE: 20.11.4 patches review and test > > > > > > > > > > > -Original Message- > > > > > > From: Xueming Li > > > > > > Sent: Tuesday, December 7, 2021 12:15 AM > > > > > > To: sta...@dpdk.org > > > > > > Cc: xuemi...@nvidia.com; dev@dpdk.org; Abhishek Marathe > > > > > > ; Ali Alnubani > > > > > > ; Walker, Benjamin > > > > > > ; David Christensen > > > > > > ; Govindharajan, Hariprasad > > > > > > ; Hemant Agrawal > > > > > > ; Stokes, Ian ; > > > > > > Jerin Jacob ; Mcnamara, John > > > > > ; > > > > > > Ju-Hyoung Lee ; Kevin Traynor > > > > > > ; Luca Boccassi ; Pei > > > > > > Zhang > > > > > > ; Xu, Qian Q ; > > > > > > Raslan > > > > > > Darawsheh ; Thomas Monjalon > > > > > ; > > > > > > Peng, Yuan ; Chen, Zhaoyan > > > > > > > > > > > > Subject: 20.11.4 patches review and test > > > > > > > > > > > > Hi all, > > > > > > > > > > > > Here is a list of patches targeted for stable release > > > > > > 20.11.4. > > > > > > > > > > > > The planned date for the final release is 31th December. > > > > > > > > > > > > Please help with testing and validation of your use cases and > > > > > > report any issues/results with reply-all to this mail. For > > > > > > the > > > > > > final release the fixes and reported validations will be > > > > > > added to > > > > > > the release notes. > > > > > > > > > > > > A release candidate tarball can be found at: > > > > > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https > > > > > > %3A%25 > > > > > > 2F%2Fdpdk.org%2Fbrowse%2Fdpdk- > > > stable%2Ftag%2F%3Fid%3Dv20.11.4- > > > > > > > > > > rc1&data=04%7C01%7Cxuemingl%40nvidia.com%7Cc9cdc823fce64be11 > > > 8 > > > > > > > > > > 0908d9bbd13e8a%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637 > > > 74 > > > > > > > > > > 7329661244261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC > > > JQIjo > > > > > > > > > > iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DtlL0BYV > > > > > > > > > > vWm7JE9JV%2BliWzq6R%2FHmKRSNKbc10nmF81Q%3D&reserved=0 > > > > > > > > > > > > These patches are located at branch 20.11 of dpdk-stable > > > > > > repo: > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https > > > > > > %3A%25 > > > > > > 2F%2Fdpdk.org%2Fbrowse%2Fdpdk- > > > > > > > > > > stable%2F&data=04%7C01%7Cxuemingl%40nvidia.com%7Cc9cdc823fce > > > 6 > > > > > > > > > > 4be1180908d9bbd13e8a%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0 > > > %7 > > > > > > > > > > C637747329661244261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > >
Re: [RFC] ethdev: introduce ethdev dump API
12/01/2022 03:44, Min Hu (Connor): > Hi, Thomas, > > 在 2022/1/11 20:48, Thomas Monjalon 写道: > > Please use --cc-cmd devtools/get-maintainer.sh so all maintainers are > > Cc'edlike this ? > git send-email -to dev@dpdk.org -cc ferruh.yi...@intel.com -cc > tho...@monjalon.net --cc-cmd devtools/get-maintainer.sh *.patch > --suppress-cc=all > > I did this, but it doesn't work. It only Cc ferruh and you. You should read the documentation about the tools: https://doc.dpdk.org/guides/contributing/patches.html#checking-the-patches In my file ~/.config/dpdk/devel.config, I have these lines: export DPDK_GETMAINTAINER_PATH=$root/linux/scripts/get_maintainer.pl export DPDK_CHECKPATCH_PATH=$root/linux/scripts/checkpatch.pl export DPDK_CHECKPATCH_CODESPELL=$root/codespell/dictionary.txt Did you set DPDK_GETMAINTAINER_PATH?
RE: [PATCH 2/8] ethdev: add dev op for IP reassembly configuration
> > > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> > > index d9a03f12f9..ecc6c1fe37 100644
> > > --- a/lib/ethdev/rte_ethdev.c
> > > +++ b/lib/ethdev/rte_ethdev.c
> > > @@ -6473,6 +6473,36 @@ rte_eth_rx_metadata_negotiate(uint16_t port_id,
> > uint64_t *features)
> > > (*dev->dev_ops->rx_metadata_negotiate)(dev, features));
> > > }
> > >
> > > +int
> > > +rte_eth_ip_reassembly_conf_set(uint16_t port_id,
> > > +struct rte_eth_ip_reass_params *conf)
> > > +{
> > > + struct rte_eth_dev *dev;
> > > +
> > > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > > + dev = &rte_eth_devices[port_id];
> >
> > Should we check here that device is properly configured, but not started
> > yet?
> Ok will add checks for dev->data->dev_configured and dev->data->dev_started
>
> > Another question - if we have reassembly_conf_set() would it make sense to
> > have also reassembly_conf_get?
> > So user can retrieve current ip_reassembly config values?
> >
> The set/supported values can be retrieved using rte_eth_dev_info :: reass_capa
Hmm, I thought rte_eth_dev_info :: reass_capa reports
max supported values, not currently set values.
Did I misunderstand something?
RE: [PATCH 3/8] ethdev: add mbuf dynfield for incomplete IP reassembly
> >
> > > Hardware IP reassembly may be incomplete for multiple reasons like
> > > reassembly timeout reached, duplicate fragments, etc.
> > > To save application cycles to process these packets again, a new
> > > mbuf ol_flag (RTE_MBUF_F_RX_IPREASSEMBLY_INCOMPLETE) is added to
> > > show that the mbuf received is not reassembled properly.
> >
> > If we use dynfiled for data, why not use dynflag for
> > RTE_MBUF_F_RX_IPREASSEMBLY_INCOMPLETE?
> > That way we can avoid introduced hardcoded (always defined) flags for that
> > case.
>
> I have not looked into using dynflag. Will explore if it can be used.
>
>
> > >
> > > +/**
> > > + * In case of IP reassembly offload failure, ol_flags in mbuf will be set
> > > + * with RTE_MBUF_F_RX_IPREASSEMBLY_INCOMPLETE and packets will be
> > returned
> > > + * without alteration. The application can retrieve the attached
> > > fragments
> > > + * using mbuf dynamic field.
> > > + */
> > > +typedef struct {
> > > + /**
> > > + * Next fragment packet. Application should fetch dynamic field of
> > > + * each fragment until a NULL is received and nb_frags is 0.
> > > + */
> > > + struct rte_mbuf *next_frag;
> > > + /** Time spent(in ms) by HW in waiting for further fragments. */
> > > + uint16_t time_spent;
> > > + /** Number of more fragments attached in mbuf dynamic fields. */
> > > + uint16_t nb_frags;
> > > +} rte_eth_ip_reass_dynfield_t;
> >
> >
> > Looks like a bit of overkill to me:
> > We do already have 'next' and 'nb_frags' fields inside mbuf,
> > why can't they be used here? Why a separate ones are necessary?
> >
> The next and nb_frags in mbuf is for segmented buffers and not IP fragments.
> But here we will have separate mbufs in each dynfield denoting each of the
> fragments which may have further segmented buffers.
Makes sense, thanks for explanation.
Though in that case just 'struct rte_mbuf *next_frag' might be enough
(user will walk though the list till mbuf->next_frag != NULL)?
The reason I am asking: current sizeof(rte_eth_ip_reass_dynfield_t) is 16B,
which is quite a lot for mbuf, especially considering that it has to be
continuous 16B.
Making it smaller (8B) or even splitting into 2 fileds (8+4) will give it more
chances
to coexist with other dynfields.
RE: [PATCH 2/8] ethdev: add dev op for IP reassembly configuration
> > > Another question - if we have reassembly_conf_set() would it make sense to > > > have also reassembly_conf_get? > > > So user can retrieve current ip_reassembly config values? > > > > > The set/supported values can be retrieved using rte_eth_dev_info :: > reass_capa > > Hmm, I thought rte_eth_dev_info :: reass_capa reports > max supported values, not currently set values. > Did I misunderstand something? > Reassembly configuration is expected to be a one-time setting and is not expected to change multiple times in the application. You are correct that rte_eth_dev_info :: reass_capa reports max supported values by the PMD. But if somebody uses the _set API, dev_info values will be overwritten. However, a get API can be added, if we have some use case. IMO, we can add it later if it will be required.
RE: [PATCH 2/8] ethdev: add dev op for IP reassembly configuration
> > > > Another question - if we have reassembly_conf_set() would it make sense > > > > to > > > > have also reassembly_conf_get? > > > > So user can retrieve current ip_reassembly config values? > > > > > > > The set/supported values can be retrieved using rte_eth_dev_info :: > > reass_capa > > > > Hmm, I thought rte_eth_dev_info :: reass_capa reports > > max supported values, not currently set values. > > Did I misunderstand something? > > > Reassembly configuration is expected to be a one-time setting and is not > expected > to change multiple times in the application. > You are correct that rte_eth_dev_info :: reass_capa reports max supported > values > by the PMD. > But if somebody uses the _set API, dev_info values will be overwritten. > However, a get API can be added, if we have some use case. > IMO, we can add it later if it will be required. Basically you forbid user to reconfigure this feature during application life-time? That sounds like a really strange approach to me and Probably will affect its usability in a negative way. Wonder why it has to be that restrictive? Also with the model you suggest, what would happen after user will do: dev_stop(); dev_configure();? Would rte_eth_dev_info :: reass_capa be reset to initial values, or user values will be preserved, or ...?
Re: [EXT] Re: [dpdk-dev] [PATCH 22.02 2/2] net/cnxk: add devargs for configuring SDP channel mask
On 1/11/2022 2:29 PM, Satheesh Paul wrote: Hi, Please find reply inline. Thanks, Satheesh. -Original Message- From: Ferruh Yigit Sent: 11 January 2022 05:26 PM To: Satheesh Paul ; Nithin Kumar Dabilpuram ; Kiran Kumar Kokkilagadda ; Sunil Kumar Kori ; Satha Koteswara Rao Kottidi Cc: dev@dpdk.org; Ori Kam ; Andrew Rybchenko Subject: [EXT] Re: [dpdk-dev] [PATCH 22.02 2/2] net/cnxk: add devargs for configuring SDP channel mask External Email -- On 11/9/2021 9:42 AM, psathe...@marvell.com wrote: From: Satheesh Paul This patch adds support to configure channel mask which will be used by rte flow when adding flow rules on SDP interfaces. Hi Satheesh, + Ori & Andrew. What 'SDP' stands for? It stands for "System DMA Packet Interface". This is when the system acts as PCIe endpoint. For instance, an x86 machine can act as a host having an Octeon TX* board plugged through this PCIe interface and packets are transferred through this PCIe interface. And can this new devarg be provided with flow rule? Why it needs to be a new devarg? SDP and its channel related info are specific to the hardware and rte flow api cannot be extended to support them. Hence, it is added as a new devarg. Can you please give a sample of the rte flow API that will be used? This channel mask will be used by the rte_flow_create() api. It is actually transparent at rte_flow_create() invocation itself. That is, at the time of rte_flow_create() invocation, user does not give any additional information. But internally, the driver's flow creation api takes the SDP channel/mask value supplied at the startup and applies it. Basically, in Octeon tx*, the interfaces have a "channel identifier" number. The rules in packet classification hardware are configured to match the channel number. With this change, we are relaxing the exact match and are allowing a range for this SDP interface. Got it. I am still not quite clear what SDP is, but from below document my understanding was user need to provide these channel & mask while creating a flow rule, but according above description that is not the case, but this is internal to the driver, so I am OK to proceed. Thanks for clarification. Thanks, ferruh Signed-off-by: Satheesh Paul --- doc/guides/nics/cnxk.rst | 21 ++ drivers/net/cnxk/cnxk_ethdev_devargs.c | 40 -- 2 files changed, 59 insertions(+), 2 deletions(-) diff --git a/doc/guides/nics/cnxk.rst b/doc/guides/nics/cnxk.rst index 837ffc02b4..470e01b811 100644 --- a/doc/guides/nics/cnxk.rst +++ b/doc/guides/nics/cnxk.rst @@ -276,6 +276,27 @@ Runtime Config Options set with this custom mask, inbound encrypted traffic from all ports with matching channel number pattern will be directed to the inline IPSec device. +- ``SDP device channel and mask`` (default ``none``) + Set channel and channel mask configuration for the SDP device. This + will be used when creating flow rules on the SDP device. + + By default, for rules created on the SDP device, the RTE Flow API sets the + channel number and mask to cover the entire SDP channel range in the channel + field of the MCAM entry. This behaviour can be modified using the + ``sdp_channel_mask`` ``devargs`` parameter. + + For example:: + + -a 0002:1d:00.0,sdp_channel_mask=0x700/0xf00 + + With the above configuration, RTE Flow rules API will set the channel + and channel mask as 0x700 and 0xF00 in the MCAM entries of the flow rules + created on the SDP device. This option needs to be used when more than one + SDP interface is in use and RTE Flow rules created need to distinguish + between traffic from each SDP interface. The channel and mask combination + specified should match all the channels(or rings) configured on the SDP + interface. + .. note:: <...>
RE: [PATCH 3/8] ethdev: add mbuf dynfield for incomplete IP reassembly
> > > >
> > > > +/**
> > > > + * In case of IP reassembly offload failure, ol_flags in mbuf will be
> > > > set
> > > > + * with RTE_MBUF_F_RX_IPREASSEMBLY_INCOMPLETE and packets will
> be
> > > returned
> > > > + * without alteration. The application can retrieve the attached
> > > > fragments
> > > > + * using mbuf dynamic field.
> > > > + */
> > > > +typedef struct {
> > > > + /**
> > > > +* Next fragment packet. Application should fetch dynamic field
> > > > of
> > > > +* each fragment until a NULL is received and nb_frags is 0.
> > > > +*/
> > > > + struct rte_mbuf *next_frag;
> > > > + /** Time spent(in ms) by HW in waiting for further fragments. */
> > > > + uint16_t time_spent;
> > > > + /** Number of more fragments attached in mbuf dynamic fields. */
> > > > + uint16_t nb_frags;
> > > > +} rte_eth_ip_reass_dynfield_t;
> > >
> > >
> > > Looks like a bit of overkill to me:
> > > We do already have 'next' and 'nb_frags' fields inside mbuf,
> > > why can't they be used here? Why a separate ones are necessary?
> > >
> > The next and nb_frags in mbuf is for segmented buffers and not IP fragments.
> > But here we will have separate mbufs in each dynfield denoting each of the
> > fragments which may have further segmented buffers.
>
> Makes sense, thanks for explanation.
> Though in that case just 'struct rte_mbuf *next_frag' might be enough
> (user will walk though the list till mbuf->next_frag != NULL)?
> The reason I am asking: current sizeof(rte_eth_ip_reass_dynfield_t) is 16B,
> which is quite a lot for mbuf, especially considering that it has to be
> continuous
> 16B.
> Making it smaller (8B) or even splitting into 2 fileds (8+4) will give it more
> chances
> to coexist with other dynfields.
Even if we drop nb_frags, we will be left with uint16_t time_spent.
Are you suggesting to use separate dynfield altogether for 2 bytes of
time_spent?
Re: 20.11.4 patches review and test
On Wed, 2022-01-12 at 09:53 +, Zhang, Roy Fan wrote: > Hi Xueming, > > Happy new year! > Sorry for the late reply - could you help revert the commit > > 2f2c2b5b7e7ae4942b4b3686bce2eb856fee447d > Author: Przemyslaw Zegan > Date: Wed Nov 3 15:08:23 2021 > common/qat: fix queue pairs number > > As this patch relates to new feature introduce in 2021 and is not meant for > 20.11 stable. > Sorry for the problem caused. NP, happy new year! > > Regards, > Fan > > > -Original Message- > > From: Xueming(Steven) Li > > Sent: Thursday, December 23, 2021 3:07 PM > > To: Lin, Xueqin ; Jiang, YuX ; > > sta...@dpdk.org > > Cc: Stokes, Ian ; dev@dpdk.org; > > abhishek.mara...@microsoft.com; NBU-Contact-Thomas Monjalon > > (EXTERNAL) ; d...@linux.vnet.ibm.com; > > ktray...@redhat.com; Peng, Yuan ; > > jer...@marvell.com; Walker, Benjamin ; > > Govindharajan, Hariprasad ; Raslan > > Darawsheh ; bl...@debian.org; Mcnamara, John > > ; Chen, Zhaoyan ; > > Ali Alnubani ; hemant.agra...@nxp.com; > > pezh...@redhat.com; juh...@microsoft.com; Xu, Qian Q > > > > Subject: Re: 20.11.4 patches review and test > > > > On Thu, 2021-12-16 at 06:40 +, Jiang, YuX wrote: > > > > -Original Message- > > > > From: Xueming(Steven) Li > > > > Sent: Wednesday, December 15, 2021 10:45 PM > > > > To: Lin, Xueqin ; Jiang, YuX > > > > ; > > > > sta...@dpdk.org > > > > Cc: Stokes, Ian ; dev@dpdk.org; > > > > ktray...@redhat.com; abhishek.mara...@microsoft.com; > > > > d...@linux.vnet.ibm.com; NBU-Contact-Thomas Monjalon (EXTERNAL) > > > > ; Peng, Yuan ; > > > > jer...@marvell.com; Walker, Benjamin ; > > > > bl...@debian.org; Raslan Darawsheh ; Mcnamara, > > > > John ; Chen, Zhaoyan > > > > ; Govindharajan, Hariprasad > > > > ; Ali Alnubani > > > > ; > > > > hemant.agra...@nxp.com; pezh...@redhat.com; > > juh...@microsoft.com; > > > > Xu, Qian Q > > > > Subject: Re: 20.11.4 patches review and test > > > > > > > > On Fri, 2021-12-10 at 11:35 +, Jiang, YuX wrote: > > > > > > -Original Message- > > > > > > From: Jiang, YuX > > > > > > Sent: Thursday, December 9, 2021 6:01 PM > > > > > > To: Xueming Li ; sta...@dpdk.org; Lin, > > > > > > Xueqin > > > > > > > > > > > > Cc: dev@dpdk.org; Abhishek Marathe > > > > > > ; > > > > > > Ali Alnubani ; Walker, Benjamin > > > > > > ; David Christensen > > > > > > ; Govindharajan, Hariprasad > > > > > > ; Hemant Agrawal > > > > > > ; Stokes, Ian ; > > > > > > Jerin > > > > > > Jacob ; Mcnamara, John > > > > > > ; Ju-Hyoung Lee > > > > > > ; > > > > > > Kevin Traynor ; Luca Boccassi > > > > > > ; Pei Zhang ; Xu, Qian Q > > > > > > ; Raslan Darawsheh ; > > > > Thomas > > > > > > Monjalon ; Peng, Yuan > > > > ; > > > > > > Chen, Zhaoyan > > > > > > Subject: RE: 20.11.4 patches review and test > > > > > > > > > > > > > -Original Message- > > > > > > > From: Xueming Li > > > > > > > Sent: Tuesday, December 7, 2021 12:15 AM > > > > > > > To: sta...@dpdk.org > > > > > > > Cc: xuemi...@nvidia.com; dev@dpdk.org; Abhishek Marathe > > > > > > > ; Ali Alnubani > > > > > > > ; Walker, Benjamin > > > > > > > ; David Christensen > > > > > > > ; Govindharajan, Hariprasad > > > > > > > ; Hemant Agrawal > > > > > > > ; Stokes, Ian ; > > > > > > > Jerin Jacob ; Mcnamara, John > > > > > > ; > > > > > > > Ju-Hyoung Lee ; Kevin Traynor > > > > > > > ; Luca Boccassi ; Pei > > > > > > > Zhang > > > > > > > ; Xu, Qian Q ; > > > > > > > Raslan > > > > > > > Darawsheh ; Thomas Monjalon > > > > > > ; > > > > > > > Peng, Yuan ; Chen, Zhaoyan > > > > > > > > > > > > > > Subject: 20.11.4 patches review and test > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > Here is a list of patches targeted for stable release > > > > > > > 20.11.4. > > > > > > > > > > > > > > The planned date for the final release is 31th December. > > > > > > > > > > > > > > Please help with testing and validation of your use cases and > > > > > > > report any issues/results with reply-all to this mail. For > > > > > > > the > > > > > > > final release the fixes and reported validations will be > > > > > > > added to > > > > > > > the release notes. > > > > > > > > > > > > > > A release candidate tarball can be found at: > > > > > > > > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https > > > > > > > %3A%25 > > > > > > > 2F%2Fdpdk.org%2Fbrowse%2Fdpdk- > > > > stable%2Ftag%2F%3Fid%3Dv20.11.4- > > > > > > > > > > > > > rc1&data=04%7C01%7Cxuemingl%40nvidia.com%7Cc9cdc823fce64be11 > > > > 8 > > > > > > > > > > > > > 0908d9bbd13e8a%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637 > > > > 74 > > > > > > > > > > > > > 7329661244261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC > > > > JQIjo > > > > > > > > > > > > > iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DtlL0BYV > > > > > > > > > > > > > vWm7JE9JV%2BliWzq6R%2FHmKRSNKbc10nmF81Q%3D&reserved=0 > > > > > > > > > > > > > > These patches are located at branch 20.11 of dpdk-stable > > > > > > > repo: > > >
RE: [PATCH 2/8] ethdev: add dev op for IP reassembly configuration
> > > > > Another question - if we have reassembly_conf_set() would it make > > > > > sense > to > > > > > have also reassembly_conf_get? > > > > > So user can retrieve current ip_reassembly config values? > > > > > > > > > The set/supported values can be retrieved using rte_eth_dev_info :: > > > reass_capa > > > > > > Hmm, I thought rte_eth_dev_info :: reass_capa reports > > > max supported values, not currently set values. > > > Did I misunderstand something? > > > > > Reassembly configuration is expected to be a one-time setting and is not > expected > > to change multiple times in the application. > > You are correct that rte_eth_dev_info :: reass_capa reports max supported > values > > by the PMD. > > But if somebody uses the _set API, dev_info values will be overwritten. > > However, a get API can be added, if we have some use case. > > IMO, we can add it later if it will be required. > > Basically you forbid user to reconfigure this feature > during application life-time? > That sounds like a really strange approach to me and > Probably will affect its usability in a negative way. > Wonder why it has to be that restrictive? > Also with the model you suggest, what would happen after user will do: > dev_stop(); dev_configure();? > Would rte_eth_dev_info :: reass_capa be reset to initial values, > or user values will be preserved, or ...? > I am not restricting the user to not reconfigure the feature. When dev_configure() is called again after dev_stop(), it will reset the previously set values to max ones. However, if you insist the get API can be added. No strong opinion on that.
RE: 20.11.4 patches review and test
> -Original Message- > From: Xueming(Steven) Li > Sent: Wednesday, January 12, 2022 7:02 PM > To: Lin, Xueqin ; sta...@dpdk.org; Zhang, Roy Fan > ; Jiang, YuX > Cc: Stokes, Ian ; dev@dpdk.org; > abhishek.mara...@microsoft.com; ktray...@redhat.com; > d...@linux.vnet.ibm.com; NBU-Contact-Thomas Monjalon (EXTERNAL) > ; Peng, Yuan ; > jer...@marvell.com; Walker, Benjamin ; > Govindharajan, Hariprasad ; Raslan > Darawsheh ; bl...@debian.org; Mcnamara, John > ; Chen, Zhaoyan ; > Ali Alnubani ; hemant.agra...@nxp.com; > pezh...@redhat.com; juh...@microsoft.com; Xu, Qian Q > > Subject: Re: 20.11.4 patches review and test > > On Wed, 2022-01-12 at 09:53 +, Zhang, Roy Fan wrote: > > Hi Xueming, > > > > Happy new year! > > Sorry for the late reply - could you help revert the commit > > > > 2f2c2b5b7e7ae4942b4b3686bce2eb856fee447d > > Author: Przemyslaw Zegan > > Date: Wed Nov 3 15:08:23 2021 > > common/qat: fix queue pairs number > > > > As this patch relates to new feature introduce in 2021 and is not meant for > 20.11 stable. > > Sorry for the problem caused. > > NP, happy new year! > Hi Xueming, May I know this patch http://inbox.dpdk.org/stable/20211208103410.835542-1-ferruh.yi...@intel.com/T/#u will be merged into LTS20.11.4 or not? [dpdk-20.11.4]kernel/linux/kni/rte_kni.ko build failed on OpenSuse15.3 with gcc7.5.0&clang11.0.1 > > > > Regards, > > Fan > > > > > -Original Message- > > > From: Xueming(Steven) Li > > > Sent: Thursday, December 23, 2021 3:07 PM > > > To: Lin, Xueqin ; Jiang, YuX > > > ; sta...@dpdk.org > > > Cc: Stokes, Ian ; dev@dpdk.org; > > > abhishek.mara...@microsoft.com; NBU-Contact-Thomas Monjalon > > > (EXTERNAL) ; d...@linux.vnet.ibm.com; > > > ktray...@redhat.com; Peng, Yuan ; > > > jer...@marvell.com; Walker, Benjamin ; > > > Govindharajan, Hariprasad ; > > > Raslan Darawsheh ; bl...@debian.org; Mcnamara, > > > John ; Chen, Zhaoyan > > > ; Ali Alnubani ; > > > hemant.agra...@nxp.com; pezh...@redhat.com; > juh...@microsoft.com; > > > Xu, Qian Q > > > Subject: Re: 20.11.4 patches review and test > > > > > > On Thu, 2021-12-16 at 06:40 +, Jiang, YuX wrote: > > > > > -Original Message- > > > > > From: Xueming(Steven) Li > > > > > Sent: Wednesday, December 15, 2021 10:45 PM > > > > > To: Lin, Xueqin ; Jiang, YuX > > > > > ; sta...@dpdk.org > > > > > Cc: Stokes, Ian ; dev@dpdk.org; > > > > > ktray...@redhat.com; abhishek.mara...@microsoft.com; > > > > > d...@linux.vnet.ibm.com; NBU-Contact-Thomas Monjalon (EXTERNAL) > > > > > ; Peng, Yuan ; > > > > > jer...@marvell.com; Walker, Benjamin > > > > > ; bl...@debian.org; Raslan Darawsheh > > > > > ; Mcnamara, John > ; > > > > > Chen, Zhaoyan ; Govindharajan, > > > > > Hariprasad ; Ali Alnubani > > > > > ; hemant.agra...@nxp.com; > > > > > pezh...@redhat.com; > > > juh...@microsoft.com; > > > > > Xu, Qian Q > > > > > Subject: Re: 20.11.4 patches review and test > > > > > > > > > > On Fri, 2021-12-10 at 11:35 +, Jiang, YuX wrote: > > > > > > > -Original Message- > > > > > > > From: Jiang, YuX > > > > > > > Sent: Thursday, December 9, 2021 6:01 PM > > > > > > > To: Xueming Li ; sta...@dpdk.org; Lin, > > > > > > > Xueqin > > > > > > > Cc: dev@dpdk.org; Abhishek Marathe > > > > > > > ; Ali Alnubani > > > > > > > ; Walker, Benjamin > > > > > > > ; David Christensen > > > > > > > ; Govindharajan, Hariprasad > > > > > > > ; Hemant Agrawal > > > > > > > ; Stokes, Ian > > > > > > > ; Jerin Jacob ; > > > > > > > Mcnamara, John ; Ju-Hyoung Lee > > > > > > > ; Kevin Traynor ; > > > > > > > Luca Boccassi ; Pei Zhang > > > > > > > ; Xu, Qian Q ; > > > > > > > Raslan Darawsheh ; > > > > > Thomas > > > > > > > Monjalon ; Peng, Yuan > > > > > ; > > > > > > > Chen, Zhaoyan > > > > > > > Subject: RE: 20.11.4 patches review and test > > > > > > > > > > > > > > > -Original Message- > > > > > > > > From: Xueming Li > > > > > > > > Sent: Tuesday, December 7, 2021 12:15 AM > > > > > > > > To: sta...@dpdk.org > > > > > > > > Cc: xuemi...@nvidia.com; dev@dpdk.org; Abhishek Marathe > > > > > > > > ; Ali Alnubani > > > > > > > > ; Walker, Benjamin > > > > > > > > ; David Christensen > > > > > > > > ; Govindharajan, Hariprasad > > > > > > > > ; Hemant Agrawal > > > > > > > > ; Stokes, Ian > > > > > > > > ; Jerin Jacob ; > > > > > > > > Mcnamara, John > > > > > > > ; > > > > > > > > Ju-Hyoung Lee ; Kevin Traynor > > > > > > > > ; Luca Boccassi ; > > > > > > > > Pei Zhang ; Xu, Qian Q > > > > > > > > ; Raslan Darawsheh > > > > > > > > ; Thomas Monjalon > > > > > > > ; > > > > > > > > Peng, Yuan ; Chen, Zhaoyan > > > > > > > > > > > > > > > > Subject: 20.11.4 patches review and test > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > Here is a list of patches targeted for stable release > > > > > > > > 20.11.4. > > > > > > > > > > > > > > > > The planned date for the final release is 31th December. > > > > > > > > > > > > > > > > Please help with testing and validation of your use cases > >
Re: [PATCH 1/1] fix spelling in code
12/01/2022 08:28, Josh Soref:
> Some additional comment fixes...
They are not only comments, some are functions or struct fields.
> The tool comes from https://github.com/jsoref
It requires some reviews. I started to review below.
> -cpt_lfs_alloc(struct dev *dev, uint8_t eng_grpmsk, uint8_t blkaddr,
> +cpt_lfs_alloc(struct dev *dev, uint8_t eng_grpmask, uint8_t blkaddr,
grpmsk is shorter and understandable.
Adding some letters is not a fix in this case.
> -cnstr_shdsc_authenc(uint32_t *descbuf, bool ps, bool swap,
> +cnstr_shdsc_authentic(uint32_t *descbuf, bool ps, bool swap,
That's a wrong change: authenc means authentication + encryption.
> -#define COMPRESSDEV_NAME_ZIP_PMD compress_octeonx
> +#define COMPRESSDEV_NAME_ZIP_PMD compress_octeontx
Good catch! I wonder how your tool finds it.
> - comp_dev->interm_buff_mz =
> + comp_dev->interim_buff_mz =
Not sure about this one.
> - UPDATE_STAT64(rx_stat_grxpf, rx_stat_xoffstateentered);
> + UPDATE_STAT64(rx_stat_grxpf, rx_stat_xoffsetateentered);
Looks wrong.
> - * inner_ofst: If zero, this is an outer header. If non-zero, this is
> + * inner_offset: If zero, this is an outer header. If non-zero, this is
I would not change this to respect how the author shortened it.
> @@ -106,7 +106,7 @@ typedef struct VhostUserCryptoSessionParam {
> uint8_t dir;
> uint8_t hash_mode;
> uint8_t chaining_dir;
> - uint8_t *ciphe_key;
> + uint8_t *cipher_key;
> uint8_t *auth_key;
> uint8_t cipher_key_buf[VHOST_USER_CRYPTO_MAX_CIPHER_KEY_LENGTH];
> uint8_t auth_key_buf[VHOST_USER_CRYPTO_MAX_HMAC_KEY_LENGTH];
It looks to be unused. Is it an API change?
Re: [PATCH 0/1] Spelling code fixes*
12/01/2022 08:28, Josh Soref: > fixed spellings: > > * accelerator > * acceptable > * account > * accounting > * acknowledge > * acknowledgement > * across > * action > * actually > * adapter > * adaptive > * added > * addition > * address > * addresses > * adds > * adjustment > * affinity ... It would be more convenient to review the changes, example: * acelerator -> accelerator And it would be nice to make some categories, like shorter and longer replacement, because shorter is almost always a good fix, but a longer replacement may not be required and require more attention.
Re: [RFC v3] ethdev: introduce ethdev dump API
Min Hu (Connor) writes: > Added the ethdev dump API which provides functions for query private info > from device. There exists many private properties in different PMD drivers, > such as adapter state, Rx/Tx func algorithm in hns3 PMD. The information of > these properties is important for debug. As the information is private, > the new API is introduced. > > Signed-off-by: Min Hu (Connor) > Acked-by: Morten BrÞrup > --- > v3: > * fix comment. > * add rte_eth_dev_priv_dump to version.map file. > > v2: > * fix dump API name > * adjust description in doc. > --- > doc/guides/rel_notes/release_22_03.rst | 7 +++ > lib/ethdev/ethdev_driver.h | 17 + > lib/ethdev/rte_ethdev.c| 15 +++ > lib/ethdev/rte_ethdev.h| 16 > lib/ethdev/version.map | 3 +++ > 5 files changed, 58 insertions(+) > Acked-by: Ray Kinsella
Re: [PATCH 0/1] Spelling code fixes*
On Wed, Jan 12, 2022, 6:50 AM Thomas Monjalon wrote: > 12/01/2022 08:28, Josh Soref: > > fixed spellings: > > > > * accelerator > > * acceptable > > * account > > * accounting > > * acknowledge > > * acknowledgement > > * across > > * action > > * actually > > * adapter > > * adaptive > > * added > > * addition > > * address > > * addresses > > * adds > > * adjustment > > * affinity > ... > > It would be more convenient to review the changes, example: > * acelerator -> accelerator > And it would be nice to make some categories, > like shorter and longer replacement, > because shorter is almost always a good fix, > but a longer replacement may not be required and require more attention. > The original task actually has this. But I generally fold all of the replacements together, so a given commit for `addresses` at this point may be a mix of changes from `addresse`, `adddresses`, and `Addressses`
Re: 20.11.4 patches review and test
On Wed, 2022-01-12 at 11:29 +, Jiang, YuX wrote: > > -Original Message- > > From: Xueming(Steven) Li > > Sent: Wednesday, January 12, 2022 7:02 PM > > To: Lin, Xueqin ; sta...@dpdk.org; Zhang, Roy > > Fan > > ; Jiang, YuX > > Cc: Stokes, Ian ; dev@dpdk.org; > > abhishek.mara...@microsoft.com; ktray...@redhat.com; > > d...@linux.vnet.ibm.com; NBU-Contact-Thomas Monjalon (EXTERNAL) > > ; Peng, Yuan ; > > jer...@marvell.com; Walker, Benjamin ; > > Govindharajan, Hariprasad ; > > Raslan > > Darawsheh ; bl...@debian.org; Mcnamara, John > > ; Chen, Zhaoyan ; > > Ali Alnubani ; hemant.agra...@nxp.com; > > pezh...@redhat.com; juh...@microsoft.com; Xu, Qian Q > > > > Subject: Re: 20.11.4 patches review and test > > > > On Wed, 2022-01-12 at 09:53 +, Zhang, Roy Fan wrote: > > > Hi Xueming, > > > > > > Happy new year! > > > Sorry for the late reply - could you help revert the commit > > > > > > 2f2c2b5b7e7ae4942b4b3686bce2eb856fee447d > > > Author: Przemyslaw Zegan > > > Date: Wed Nov 3 15:08:23 2021 > > > common/qat: fix queue pairs number > > > > > > As this patch relates to new feature introduce in 2021 and is not > > > meant for > > 20.11 stable. > > > Sorry for the problem caused. > > > > NP, happy new year! > > > Hi Xueming, > May I know this patch > http://inbox.dpdk.org/stable/20211208103410.835542-1- > ferruh.yi...@intel.com/T/#u will be merged into LTS20.11.4 or not? > [dpdk-20.11.4]kernel/linux/kni/rte_kni.ko build failed on > OpenSuse15.3 with gcc7.5.0&clang11.0.1 Yes, the patch was delivered to stable list, queued into final release: https://mails.dpdk.org/archives/stable/2021-December/035355.html > > > > > > > Regards, > > > Fan > > > > > > > -Original Message- > > > > From: Xueming(Steven) Li > > > > Sent: Thursday, December 23, 2021 3:07 PM > > > > To: Lin, Xueqin ; Jiang, YuX > > > > ; sta...@dpdk.org > > > > Cc: Stokes, Ian ; dev@dpdk.org; > > > > abhishek.mara...@microsoft.com; NBU-Contact-Thomas Monjalon > > > > (EXTERNAL) ; d...@linux.vnet.ibm.com; > > > > ktray...@redhat.com; Peng, Yuan ; > > > > jer...@marvell.com; Walker, Benjamin > > > > ; > > > > Govindharajan, Hariprasad ; > > > > Raslan Darawsheh ; bl...@debian.org; > > > > Mcnamara, > > > > John ; Chen, Zhaoyan > > > > ; Ali Alnubani ; > > > > hemant.agra...@nxp.com; pezh...@redhat.com; > > juh...@microsoft.com; > > > > Xu, Qian Q > > > > Subject: Re: 20.11.4 patches review and test > > > > > > > > On Thu, 2021-12-16 at 06:40 +, Jiang, YuX wrote: > > > > > > -Original Message- > > > > > > From: Xueming(Steven) Li > > > > > > Sent: Wednesday, December 15, 2021 10:45 PM > > > > > > To: Lin, Xueqin ; Jiang, YuX > > > > > > ; sta...@dpdk.org > > > > > > Cc: Stokes, Ian ; dev@dpdk.org; > > > > > > ktray...@redhat.com; abhishek.mara...@microsoft.com; > > > > > > d...@linux.vnet.ibm.com; NBU-Contact-Thomas Monjalon > > > > > > (EXTERNAL) > > > > > > ; Peng, Yuan ; > > > > > > jer...@marvell.com; Walker, Benjamin > > > > > > ; bl...@debian.org; Raslan > > > > > > Darawsheh > > > > > > ; Mcnamara, John > > ; > > > > > > Chen, Zhaoyan ; Govindharajan, > > > > > > Hariprasad ; Ali > > > > > > Alnubani > > > > > > ; hemant.agra...@nxp.com; > > > > > > pezh...@redhat.com; > > > > juh...@microsoft.com; > > > > > > Xu, Qian Q > > > > > > Subject: Re: 20.11.4 patches review and test > > > > > > > > > > > > On Fri, 2021-12-10 at 11:35 +, Jiang, YuX wrote: > > > > > > > > -Original Message- > > > > > > > > From: Jiang, YuX > > > > > > > > Sent: Thursday, December 9, 2021 6:01 PM > > > > > > > > To: Xueming Li ; sta...@dpdk.org; > > > > > > > > Lin, > > > > > > > > Xueqin > > > > > > > > Cc: dev@dpdk.org; Abhishek Marathe > > > > > > > > ; Ali Alnubani > > > > > > > > ; Walker, Benjamin > > > > > > > > ; David Christensen > > > > > > > > ; Govindharajan, Hariprasad > > > > > > > > ; Hemant Agrawal > > > > > > > > ; Stokes, Ian > > > > > > > > ; Jerin Jacob > > > > > > > > ; > > > > > > > > Mcnamara, John ; Ju-Hyoung Lee > > > > > > > > ; Kevin Traynor > > > > > > > > ; > > > > > > > > Luca Boccassi ; Pei Zhang > > > > > > > > ; Xu, Qian Q ; > > > > > > > > Raslan Darawsheh ; > > > > > > Thomas > > > > > > > > Monjalon ; Peng, Yuan > > > > > > ; > > > > > > > > Chen, Zhaoyan > > > > > > > > Subject: RE: 20.11.4 patches review and test > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > From: Xueming Li > > > > > > > > > Sent: Tuesday, December 7, 2021 12:15 AM > > > > > > > > > To: sta...@dpdk.org > > > > > > > > > Cc: xuemi...@nvidia.com; dev@dpdk.org; Abhishek > > > > > > > > > Marathe > > > > > > > > > ; Ali Alnubani > > > > > > > > > ; Walker, Benjamin > > > > > > > > > ; David Christensen > > > > > > > > > ; Govindharajan, Hariprasad > > > > > > > > > ; Hemant Agrawal > > > > > > > > > ; Stokes, Ian > > > > > > > > > ; Jerin Jacob > > > > > > > > > ; > > > > > > > > > Mcnamara, John > > > > > > > > ; > > > > > > > > > Ju-Hyoung Lee ; Kevin Traynor > > >
[PATCH] net/af_xdp: use libxdp if available
AF_XDP support is deprecated in libbpf since v0.7.0 [1]. The
libxdp library now provides the functionality which once was in
libbpf and which the AF_XDP PMD relies on. This commit updates the
AF_XDP meson build to use the libxdp library if a version >= v1.3.0 is
available. If it is not available, only versions of libbpf prior to v0.7.0
are allowed, as they still contain the required AF_XDP functionality.
libbpf still remains a dependency even if libxdp is present, as we
use libbpf APIs for program loading.
The minimum required kernel version for libxdp for use with AF_XDP is v5.3.
For the library to be fully-featured, a kernel v5.10 or newer is
recommended. The full compatibility information can be found in the libxdp
README.
v1.3.0 of libxdp includes an important fix required for linking with
DPDK which is why this version or greater is required. Meson uses
pkg-config to verify the version of libxdp on the system, so it is
necessary that the library is discoverable using pkg-config in order for
the PMD to use it. To verify this, you can run:
pkg-config --modversion libxdp
[1] https://github.com/libbpf/libbpf/commit/277846bc6c15
Signed-off-by: Ciara Loftus
---
RFC -> v1:
* Set minimum libxdp version at v1.3.0
* Don't provide alternative to discovery via pkg-config
* Add missing newline to end of file
---
doc/guides/nics/af_xdp.rst | 6 ++--
doc/guides/rel_notes/release_22_03.rst | 4 +++
drivers/net/af_xdp/compat.h| 4 +++
drivers/net/af_xdp/meson.build | 39 +-
drivers/net/af_xdp/rte_eth_af_xdp.c| 1 -
5 files changed, 42 insertions(+), 12 deletions(-)
diff --git a/doc/guides/nics/af_xdp.rst b/doc/guides/nics/af_xdp.rst
index c9d0e1ad6c..60f4536ac5 100644
--- a/doc/guides/nics/af_xdp.rst
+++ b/doc/guides/nics/af_xdp.rst
@@ -43,9 +43,7 @@ Prerequisites
This is a Linux-specific PMD, thus the following prerequisites apply:
* A Linux Kernel (version > v4.18) with XDP sockets configuration enabled;
-* libbpf (within kernel version > v5.1-rc4) with latest af_xdp support
installed,
- User can install libbpf via `make install_lib` && `make install_headers` in
- /tools/lib/bpf;
+* Both libxdp >=v1.3.0 and libbpf libraries installed, or, libbpf <=v0.6.0
* A Kernel bound interface to attach to;
* For need_wakeup feature, it requires kernel version later than v5.3-rc1;
* For PMD zero copy, it requires kernel version later than v5.4-rc1;
@@ -143,4 +141,4 @@ Limitations
NAPI context from a watchdog timer instead of from softirqs. More information
on this feature can be found at [1].
- [1] https://lwn.net/Articles/837010/
\ No newline at end of file
+ [1] https://lwn.net/Articles/837010/
diff --git a/doc/guides/rel_notes/release_22_03.rst
b/doc/guides/rel_notes/release_22_03.rst
index 6d99d1eaa9..1258bdac61 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -55,6 +55,10 @@ New Features
Also, make sure to start the actual text at the margin.
===
+* **Update AF_XDP PMD**
+
+ * Added support for libxdp >=v1.3.0.
+
Removed Items
-
diff --git a/drivers/net/af_xdp/compat.h b/drivers/net/af_xdp/compat.h
index 3880dc7dd7..245df1b109 100644
--- a/drivers/net/af_xdp/compat.h
+++ b/drivers/net/af_xdp/compat.h
@@ -2,7 +2,11 @@
* Copyright(c) 2020 Intel Corporation.
*/
+#ifdef RTE_LIBRTE_AF_XDP_PMD_LIBXDP
+#include
+#else
#include
+#endif
#include
#include
diff --git a/drivers/net/af_xdp/meson.build b/drivers/net/af_xdp/meson.build
index 3ed2b29784..cdc4c1ca06 100644
--- a/drivers/net/af_xdp/meson.build
+++ b/drivers/net/af_xdp/meson.build
@@ -9,19 +9,44 @@ endif
sources = files('rte_eth_af_xdp.c')
+xdp_dep = dependency('libxdp', version : '>=1.3.0', required: false, method:
'pkg-config')
bpf_dep = dependency('libbpf', required: false, method: 'pkg-config')
if not bpf_dep.found()
bpf_dep = cc.find_library('bpf', required: false)
endif
-if bpf_dep.found() and cc.has_header('bpf/xsk.h') and
cc.has_header('linux/if_xdp.h')
-ext_deps += bpf_dep
-bpf_ver_dep = dependency('libbpf', version : '>=0.2.0',
-required: false, method: 'pkg-config')
-if bpf_ver_dep.found()
-dpdk_conf.set('RTE_LIBRTE_AF_XDP_PMD_SHARED_UMEM', 1)
+if cc.has_header('linux/if_xdp.h')
+if xdp_dep.found() and cc.has_header('xdp/xsk.h')
+if bpf_dep.found() and cc.has_header('bpf/bpf.h')
+dpdk_conf.set('RTE_LIBRTE_AF_XDP_PMD_LIBXDP', 1)
+dpdk_conf.set('RTE_LIBRTE_AF_XDP_PMD_SHARED_UMEM', 1)
+ext_deps += xdp_dep
+ext_deps += bpf_dep
+else
+build = false
+reason = 'missing dependency, libbpf'
+endif
+elif bpf_dep.found() and cc.has_header('bpf/xsk.h') and
cc.has_header('bpf/bpf.h')
+# libxdp not found. Rely solely on libbpf for xsk functionality
+# which is only a
[PATCH v3] ethdev: mark old macros as deprecated
Old macros kept for backward compatibility, but this cause old macro
usage to sneak in silently.
Marking old macros as deprecated. Downside is this will cause some noise
for applications that are using old macros.
Fixes: 295968d17407 ("ethdev: add namespace")
Signed-off-by: Ferruh Yigit
Acked-by: Stephen Hemminger
---
v2:
* Release notes updated
v3:
* Update 22.03 release note
---
doc/guides/rel_notes/release_22_03.rst | 3 +
lib/ethdev/rte_ethdev.h| 474 +
2 files changed, 247 insertions(+), 230 deletions(-)
diff --git a/doc/guides/rel_notes/release_22_03.rst
b/doc/guides/rel_notes/release_22_03.rst
index 6d99d1eaa94a..16c66c0641d4 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -84,6 +84,9 @@ API Changes
Also, make sure to start the actual text at the margin.
===
+* ethdev: Old public macros and enumeration constants without ``RTE_ETH_``
prefix,
+ which are kept for backward compatibility, are marked as deprecated.
+
ABI Changes
---
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index fa299c8ad70e..147cc1ced36a 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -288,76 +288,78 @@ struct rte_eth_stats {
* Device supported speeds bitmap flags
*/
#define RTE_ETH_LINK_SPEED_AUTONEG 0 /**< Autonegotiate (all
speeds) */
-#define ETH_LINK_SPEED_AUTONEG RTE_ETH_LINK_SPEED_AUTONEG
#define RTE_ETH_LINK_SPEED_FIXED RTE_BIT32(0) /**< Disable autoneg (fixed
speed) */
-#define ETH_LINK_SPEED_FIXED RTE_ETH_LINK_SPEED_FIXED
#define RTE_ETH_LINK_SPEED_10M_HD RTE_BIT32(1) /**< 10 Mbps half-duplex */
-#define ETH_LINK_SPEED_10M_HD RTE_ETH_LINK_SPEED_10M_HD
#define RTE_ETH_LINK_SPEED_10M RTE_BIT32(2) /**< 10 Mbps full-duplex */
-#define ETH_LINK_SPEED_10M RTE_ETH_LINK_SPEED_10M
#define RTE_ETH_LINK_SPEED_100M_HD RTE_BIT32(3) /**< 100 Mbps half-duplex */
-#define ETH_LINK_SPEED_100M_HD RTE_ETH_LINK_SPEED_100M_HD
#define RTE_ETH_LINK_SPEED_100MRTE_BIT32(4) /**< 100 Mbps full-duplex */
-#define ETH_LINK_SPEED_100MRTE_ETH_LINK_SPEED_100M
#define RTE_ETH_LINK_SPEED_1G RTE_BIT32(5) /**< 1 Gbps */
-#define ETH_LINK_SPEED_1G RTE_ETH_LINK_SPEED_1G
#define RTE_ETH_LINK_SPEED_2_5GRTE_BIT32(6) /**< 2.5 Gbps */
-#define ETH_LINK_SPEED_2_5GRTE_ETH_LINK_SPEED_2_5G
#define RTE_ETH_LINK_SPEED_5G RTE_BIT32(7) /**< 5 Gbps */
-#define ETH_LINK_SPEED_5G RTE_ETH_LINK_SPEED_5G
#define RTE_ETH_LINK_SPEED_10G RTE_BIT32(8) /**< 10 Gbps */
-#define ETH_LINK_SPEED_10G RTE_ETH_LINK_SPEED_10G
#define RTE_ETH_LINK_SPEED_20G RTE_BIT32(9) /**< 20 Gbps */
-#define ETH_LINK_SPEED_20G RTE_ETH_LINK_SPEED_20G
#define RTE_ETH_LINK_SPEED_25G RTE_BIT32(10) /**< 25 Gbps */
-#define ETH_LINK_SPEED_25G RTE_ETH_LINK_SPEED_25G
#define RTE_ETH_LINK_SPEED_40G RTE_BIT32(11) /**< 40 Gbps */
-#define ETH_LINK_SPEED_40G RTE_ETH_LINK_SPEED_40G
#define RTE_ETH_LINK_SPEED_50G RTE_BIT32(12) /**< 50 Gbps */
-#define ETH_LINK_SPEED_50G RTE_ETH_LINK_SPEED_50G
#define RTE_ETH_LINK_SPEED_56G RTE_BIT32(13) /**< 56 Gbps */
-#define ETH_LINK_SPEED_56G RTE_ETH_LINK_SPEED_56G
#define RTE_ETH_LINK_SPEED_100GRTE_BIT32(14) /**< 100 Gbps */
-#define ETH_LINK_SPEED_100GRTE_ETH_LINK_SPEED_100G
#define RTE_ETH_LINK_SPEED_200GRTE_BIT32(15) /**< 200 Gbps */
-#define ETH_LINK_SPEED_200GRTE_ETH_LINK_SPEED_200G
/**@}*/
+#define ETH_LINK_SPEED_AUTONEG RTE_DEPRECATED(ETH_LINK_SPEED_AUTONEG)
RTE_ETH_LINK_SPEED_AUTONEG
+#define ETH_LINK_SPEED_FIXED RTE_DEPRECATED(ETH_LINK_SPEED_FIXED)
RTE_ETH_LINK_SPEED_FIXED
+#define ETH_LINK_SPEED_10M_HD RTE_DEPRECATED(ETH_LINK_SPEED_10M_HD)
RTE_ETH_LINK_SPEED_10M_HD
+#define ETH_LINK_SPEED_10M RTE_DEPRECATED(ETH_LINK_SPEED_10M)
RTE_ETH_LINK_SPEED_10M
+#define ETH_LINK_SPEED_100M_HD RTE_DEPRECATED(ETH_LINK_SPEED_100M_HD)
RTE_ETH_LINK_SPEED_100M_HD
+#define ETH_LINK_SPEED_100MRTE_DEPRECATED(ETH_LINK_SPEED_100M)
RTE_ETH_LINK_SPEED_100M
+#define ETH_LINK_SPEED_1G RTE_DEPRECATED(ETH_LINK_SPEED_1G)
RTE_ETH_LINK_SPEED_1G
+#define ETH_LINK_SPEED_2_5GRTE_DEPRECATED(ETH_LINK_SPEED_2_5G)
RTE_ETH_LINK_SPEED_2_5G
+#define ETH_LINK_SPEED_5G RTE_DEPRECATED(ETH_LINK_SPEED_5G)
RTE_ETH_LINK_SPEED_5G
+#define ETH_LINK_SPEED_10G RTE_DEPRECATED(ETH_LINK_SPEED_10G)
RTE_ETH_LINK_SPEED_10G
+#define ETH_LINK_SPEED_20G RTE_DEPRECATED(ETH_LINK_SPEED_20G)
RTE_ETH_LINK_SPEED_20G
+#define ETH_LINK_SPEED_25G RTE_DEPRECATED(ETH_LINK_SPEED_25G)
RTE_ETH_LINK_SPEED_25G
+#define ETH_LINK_SPEED_40G RTE_DEPRECATED(ETH_LINK_SPEED_40G)
RTE_ETH_LINK_SPEED_40G
+#define ETH_LINK_SPEED_50G RTE_DEPRECATED(ETH_LINK_SPEED_50G)
RTE_ETH_LINK_SPEED_50G
+#define ETH_LINK
Re: [dpdk-dev] [PATCH v5 0/5] remove octeontx2 drivers
> Jerin Jacob (1): > drivers: remove octeontx2 drivers > > Liron Himi (4): > common/cnxk: add REE HW definitions > common/cnxk: add REE mbox definitions > common/cnxk: add REE support > regex/cn9k: use cnxk infrastructure Applied, thanks.
[RFC] DTS Commit Policies
Hello Everyone, The DTS Working Group wanted to let everyone give feedback on the proposed DTS commit policies. Please leave a comment with any feedback you have. We will be reviewing feedback in the DTS Working Group meeting on January 26th, at which point the comment period will close. The purpose of the commit policies is to help standardize the code that makes up DTS, as well as help new additions meet community requirements, such as avoiding breaking changes, ensuring runtime stability, and aiding debugability. Owen Hilyard DTS Working Group meeting room: https://armltd.zoom.us/j/97503259680?pwd=VVlmWnlnTXJkVGkwR2JOU3R3b3Vndz09&from=addon
Re: [PATCH] app/test-fib: fix possible division by zero
Hi Kevin,
On 11/01/2022 17:15, Kevin Traynor wrote:
On 23/12/2021 15:25, Vladimir Medvedkin wrote:
This patch fixes the division by 0, which occurs if the number of
routes is less than 10.
Can be triggered by passing -n argument with value < 10:
9 causing a divide by zero - another example of inflation :-)
Too bad that we are not working in a wheel
(https://en.wikipedia.org/wiki/Wheel_theory), where division by 0 is
always defined :)
./dpdk-test-fib -- -n 9
...
Floating point exception (core dumped)
Fixes: 103809d032cd ("app/test-fib: add test application for FIB")
Cc: vladimir.medved...@intel.com
You probably want to add 'Cc: sta...@dpdk.org' for this.
Signed-off-by: Vladimir Medvedkin
---
app/test-fib/main.c | 40
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/app/test-fib/main.c b/app/test-fib/main.c
index ecd420116a..9bc8b8a7ca 100644
--- a/app/test-fib/main.c
+++ b/app/test-fib/main.c
@@ -902,8 +902,9 @@ run_v4(void)
return -ret;
}
}
- printf("AVG FIB add %"PRIu64"\n",
- (rte_rdtsc_precise() - start) / j);
+ if (j != 0)
+ printf("AVG FIB add %"PRIu64"\n",
+ (rte_rdtsc_precise() - start) / j);
You are just not printing the result for these cases. Do you think it is
worth to print a warning message (one), and update any documentation so
the user is aware of the acceptable bounds?
Agree, I'll send v2
i += j;
}
@@ -930,8 +931,9 @@ run_v4(void)
return -ret;
}
}
- printf("AVG LPM add %"PRIu64"\n",
- (rte_rdtsc_precise() - start) / j);
+ if (j != 0)
+ printf("AVG LPM add %"PRIu64"\n",
+ (rte_rdtsc_precise() - start) / j);
i += j;
}
}
@@ -984,8 +986,9 @@ run_v4(void)
for (j = 0; j < (config.nb_routes - i) / k; j++)
rte_fib_delete(fib, rt[i + j].addr, rt[i + j].depth);
- printf("AVG FIB delete %"PRIu64"\n",
- (rte_rdtsc_precise() - start) / j);
+ if (j != 0)
+ printf("AVG FIB delete %"PRIu64"\n",
+ (rte_rdtsc_precise() - start) / j);
i += j;
}
@@ -996,8 +999,9 @@ run_v4(void)
rte_lpm_delete(lpm, rt[i + j].addr,
rt[i + j].depth);
- printf("AVG LPM delete %"PRIu64"\n",
- (rte_rdtsc_precise() - start) / j);
+ if (j != 0)
+ printf("AVG LPM delete %"PRIu64"\n",
+ (rte_rdtsc_precise() - start) / j);
i += j;
}
}
@@ -1097,8 +1101,9 @@ run_v6(void)
return -ret;
}
}
- printf("AVG FIB add %"PRIu64"\n",
- (rte_rdtsc_precise() - start) / j);
+ if (j != 0)
+ printf("AVG FIB add %"PRIu64"\n",
+ (rte_rdtsc_precise() - start) / j);
i += j;
}
@@ -1125,8 +1130,9 @@ run_v6(void)
return -ret;
}
}
- printf("AVG LPM add %"PRIu64"\n",
- (rte_rdtsc_precise() - start) / j);
+ if (j != 0)
+ printf("AVG LPM add %"PRIu64"\n",
+ (rte_rdtsc_precise() - start) / j);
i += j;
}
}
@@ -1183,8 +1189,9 @@ run_v6(void)
for (j = 0; j < (config.nb_routes - i) / k; j++)
rte_fib6_delete(fib, rt[i + j].addr, rt[i + j].depth);
- printf("AVG FIB delete %"PRIu64"\n",
- (rte_rdtsc_precise() - start) / j);
+ if (j != 0)
+ printf("AVG FIB delete %"PRIu64"\n",
+ (rte_rdtsc_precise() - start) / j);
i += j;
}
@@ -1195,8 +1202,9 @@ run_v6(void)
rte_lpm6_delete(lpm, rt[i + j].addr,
rt[i + j].depth);
- printf("AVG LPM delete %"PRIu64"\n",
- (rte_rdtsc_precise() - start) / j);
+ if (j != 0)
+ printf("AVG LPM delete %"PRIu64"\n",
+ (rte_rdtsc_precise() - start) / j);
i += j;
}
}
--
Regards,
Vladimir
ETH_RSS_IP only does not seem to balance traffic
Hi, My system developper friend recently ran into a problem where l3fwd does not appear to receive balanced traffic on Intel XL710, but it is resolved when the attached patch is applied. -.rss_hf = ETH_RSS_IP, +.rss_hf = ETH_RSS_IP | ETH_RSS_TCP | ETH_RSS_UDP, IIRC I ran into a similar problem 3 or 4 years back, but didn't report then because I believed I was doing something silly. But since my friend is an experienced engineer, I feel like it may be better (for the community) to ask this in the list. We are using dpdk-stable-18.11.6 and igb_uio. What are we doing wrong? If it is not a FAQ, I can test it again with more recent stable, and will report the details. Thanks. Best, Yasu
RE: [PATCH 00/12] add packet generator library and example app
> From: Bruce Richardson [mailto:bruce.richard...@intel.com] > Sent: Tuesday, 14 December 2021 15.58 > > On Tue, Dec 14, 2021 at 02:12:30PM +, Ronan Randles wrote: > > This patchset introduces a Gen library for DPDK. This library > provides an easy > > way to generate traffic in order to test software based network > components. > > > > This library enables the basic functionality required in the traffic > generator. > > This includes: raw data setting, packet Tx and Rx, creation and > destruction of a > > Gen instance and various types of data parsing. > > This functionality is implemented in "lib/gen/rte_gen.c". IPv4 > parsing > > functionality is also added in "lib/net/rte_ip.c", this is then used > in the gen > > library. > > > > A sample app is included in "examples/generator" which shows the use > of the gen > > library in making a traffic generator. This can be used to generate > traffic by > > running the dpdk-generator generator executable. This sample app > supports > > runtime stats reporting (/gen/stats) and line rate limiting > > (/gen/mpps,) through telemetry.py. > > > > As more features are added to the gen library, the sample application > will > > become more powerful through the "/gen/packet" string parameter > > (currently supports IP and Ether address setting). This will allow > every > > application to generate more complex traffic types in the future > without > > changing API. > > > > I think this is great to see, and sounds a good addition to DPDK. One > thing > to address in any v2 is to add more documentation for both the library > and > the example app. You need a chapter on the lib added to the programmers > guide to help others use the library from their code, and a chapter on > the > generator example in the example apps guide. > > More general question - if we do have a traffic generator in DPDK, > would it > be better in the "app" rather than the examples one? If it's only going > to > ever stay a simple example of using the lib, examples might be fine, > but I > suspect that it will get quite complicated if people start using it and > adding more features, in which case a move to the "app" folder might be > more appropriate. Thoughts? > > /Bruce If adding a traffic generator lib/app to DPDK itself, it should be able to evolve freely, unencumbered by the DPDK ABI/API stability requirements. Also, it MUST be optional when building DPDK for production purposes. Consider the security perspective: If a network appliance based on DPDK is compromised by a hacker, you don't want it to include a traffic generator. -Morten
Re: [PATCH] buildtools: fix avx512 check for Python 3.5
03/01/2022 19:00, Dmitry Kozlyuk:
> 2022-01-03 12:09 (UTC-0500), Lance Richardson:
> > Python 3.5 subprocess.run() does not have a capture_output
> > parameter (it is present only in 3.7 and up). Capture output
> > by using subprocess.PIPE for stdout instead.
> >
> > Fixes: bb9cd91095b3 ("buildtools: make AVX512 check portable")
> > Cc: sta...@dpdk.org
> > Signed-off-by: Lance Richardson
>
> Acked-by: Dmitry Kozlyuk
Applied, thanks.
Re: [PATCH] doc/api: remove dependency on findutils on FreeBSD
22/12/2021 16:18, Bruce Richardson:
> Standard "find" on BSD does not support the "-printf" so gfind from
> findutils package was used to enable full doc builds. We can remove this
> extra dependency by using "sed" and "tr" to adjust the output from
> regular find instread.
>
> Fixes: 8260f4f98cfe ("mk: use script to generate examples.dox")
> Fixes: 499fe9dfcfc7 ("doc: add dependency on examples for API doxygen")
> Fixes: 897e55c8d27f ("doc: fix Doxygen examples build on FreeBSD")
> Cc: bl...@debian.org
> Cc: tho...@monjalon.net
> Cc: sta...@dpdk.org
>
> Signed-off-by: Bruce Richardson
> ---
> -$FIND "${EXAMPLES_DIR}" -type f -name '*.c' -printf '@example examples/%P\n'
> | LC_ALL=C sort
> +$FIND "${EXAMPLES_DIR}" -type f -name '*.c' | sed
> "s|${EXAMPLES_DIR}|@example examples|" | LC_ALL=C sort
Broke up this long line (after each pipe),
and applied, thanks.
[PATCH] examples/pipeline: print table entries to file
Add support for the show CLI command to print table entries to a file
instead of standard output.
Signed-off-by: Cristian Dumitrescu
Signed-off-by: Harshad Narayane
---
examples/pipeline/cli.c | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/examples/pipeline/cli.c b/examples/pipeline/cli.c
index c32349e5f0..2278bcbd51 100644
--- a/examples/pipeline/cli.c
+++ b/examples/pipeline/cli.c
@@ -1346,7 +1346,7 @@ cmd_pipeline_table_default(char **tokens,
}
static const char cmd_pipeline_table_show_help[] =
-"pipeline table show\n";
+"pipeline table show [filename]\n";
static void
cmd_pipeline_table_show(char **tokens,
@@ -1357,9 +1357,10 @@ cmd_pipeline_table_show(char **tokens,
{
struct pipeline *p;
char *pipeline_name, *table_name;
+ FILE *file = NULL;
int status;
- if (n_tokens != 5) {
+ if (n_tokens != 5 && n_tokens != 6) {
snprintf(out, out_size, MSG_ARG_MISMATCH, tokens[0]);
return;
}
@@ -1372,9 +1373,18 @@ cmd_pipeline_table_show(char **tokens,
}
table_name = tokens[3];
- status = rte_swx_ctl_pipeline_table_fprintf(stdout, p->ctl, table_name);
+ file = (n_tokens == 6) ? fopen(tokens[5] , "w") : stdout;
+ if (!file) {
+ snprintf(out, out_size, "Cannot open file %s.\n", tokens[5]);
+ return;
+ }
+
+ status = rte_swx_ctl_pipeline_table_fprintf(file, p->ctl, table_name);
if (status)
snprintf(out, out_size, MSG_ARG_INVALID, "table_name");
+
+ if (file)
+ fclose(file);
}
static const char cmd_pipeline_selector_group_add_help[] =
@@ -1806,7 +1816,7 @@ cmd_pipeline_selector_group_member_delete(char **tokens,
}
static const char cmd_pipeline_selector_show_help[] =
-"pipeline selector show\n";
+"pipeline selector show [filename]\n";
static void
cmd_pipeline_selector_show(char **tokens,
@@ -1817,9 +1827,10 @@ cmd_pipeline_selector_show(char **tokens,
{
struct pipeline *p;
char *pipeline_name, *selector_name;
+ FILE *file = NULL;
int status;
- if (n_tokens != 5) {
+ if (n_tokens != 5 && n_tokens != 6) {
snprintf(out, out_size, MSG_ARG_MISMATCH, tokens[0]);
return;
}
@@ -1832,10 +1843,19 @@ cmd_pipeline_selector_show(char **tokens,
}
selector_name = tokens[3];
- status = rte_swx_ctl_pipeline_selector_fprintf(stdout,
- p->ctl, selector_name);
+
+ file = (n_tokens == 6) ? fopen(tokens[5], "w") : stdout;
+ if (!file) {
+ snprintf(out, out_size, "Cannot open file %s.\n", tokens[5]);
+ return;
+ }
+
+ status = rte_swx_ctl_pipeline_selector_fprintf(file, p->ctl,
selector_name);
if (status)
snprintf(out, out_size, MSG_ARG_INVALID, "selector_name");
+
+ if (file)
+ fclose(file);
}
static int
--
2.17.1
[PATCH V2] examples/pipeline: print table entries to file
Add support for the show CLI command to print table entries to a file
instead of standard output.
Signed-off-by: Cristian Dumitrescu
Signed-off-by: Harshad Narayane
---
examples/pipeline/cli.c | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/examples/pipeline/cli.c b/examples/pipeline/cli.c
index c32349e5f0..edae63dae6 100644
--- a/examples/pipeline/cli.c
+++ b/examples/pipeline/cli.c
@@ -1346,7 +1346,7 @@ cmd_pipeline_table_default(char **tokens,
}
static const char cmd_pipeline_table_show_help[] =
-"pipeline table show\n";
+"pipeline table show [filename]\n";
static void
cmd_pipeline_table_show(char **tokens,
@@ -1357,9 +1357,10 @@ cmd_pipeline_table_show(char **tokens,
{
struct pipeline *p;
char *pipeline_name, *table_name;
+ FILE *file = NULL;
int status;
- if (n_tokens != 5) {
+ if (n_tokens != 5 && n_tokens != 6) {
snprintf(out, out_size, MSG_ARG_MISMATCH, tokens[0]);
return;
}
@@ -1372,9 +1373,18 @@ cmd_pipeline_table_show(char **tokens,
}
table_name = tokens[3];
- status = rte_swx_ctl_pipeline_table_fprintf(stdout, p->ctl, table_name);
+ file = (n_tokens == 6) ? fopen(tokens[5], "w") : stdout;
+ if (!file) {
+ snprintf(out, out_size, "Cannot open file %s.\n", tokens[5]);
+ return;
+ }
+
+ status = rte_swx_ctl_pipeline_table_fprintf(file, p->ctl, table_name);
if (status)
snprintf(out, out_size, MSG_ARG_INVALID, "table_name");
+
+ if (file)
+ fclose(file);
}
static const char cmd_pipeline_selector_group_add_help[] =
@@ -1806,7 +1816,7 @@ cmd_pipeline_selector_group_member_delete(char **tokens,
}
static const char cmd_pipeline_selector_show_help[] =
-"pipeline selector show\n";
+"pipeline selector show [filename]\n";
static void
cmd_pipeline_selector_show(char **tokens,
@@ -1817,9 +1827,10 @@ cmd_pipeline_selector_show(char **tokens,
{
struct pipeline *p;
char *pipeline_name, *selector_name;
+ FILE *file = NULL;
int status;
- if (n_tokens != 5) {
+ if (n_tokens != 5 && n_tokens != 6) {
snprintf(out, out_size, MSG_ARG_MISMATCH, tokens[0]);
return;
}
@@ -1832,10 +1843,19 @@ cmd_pipeline_selector_show(char **tokens,
}
selector_name = tokens[3];
- status = rte_swx_ctl_pipeline_selector_fprintf(stdout,
- p->ctl, selector_name);
+
+ file = (n_tokens == 6) ? fopen(tokens[5], "w") : stdout;
+ if (!file) {
+ snprintf(out, out_size, "Cannot open file %s.\n", tokens[5]);
+ return;
+ }
+
+ status = rte_swx_ctl_pipeline_selector_fprintf(file, p->ctl,
selector_name);
if (status)
snprintf(out, out_size, MSG_ARG_INVALID, "selector_name");
+
+ if (file)
+ fclose(file);
}
static int
--
2.17.1
[PATCH] doc: update matching versions in ice guide
Add recommended matching list for ice PMD in DPDK 21.08 and DPDK 21.11. Signed-off-by: Qi Zhang --- doc/guides/nics/ice.rst | 4 1 file changed, 4 insertions(+) diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst index f95fef8cf0..a1780c46c3 100644 --- a/doc/guides/nics/ice.rst +++ b/doc/guides/nics/ice.rst @@ -58,6 +58,10 @@ The detailed information can refer to chapter Tested Platforms/Tested NICs in re +---+---+-+---+--+---+ |21.05 | 1.6.5 | 1.3.26 | 1.3.30 |1.3.6 | 3.0| +---+---+-+---+--+---+ + |21.08 | 1.7.16| 1.3.27 | 1.3.31 |1.3.7 | 3.1| + +---+---+-+---+--+---+ + |21.11 | 1.7.16| 1.3.27 | 1.3.31 |1.3.7 | 3.1| + +---+---+-+---+--+---+ Pre-Installation Configuration -- -- 2.26.2
Re: [PATCH] net/cnxk: fix promiscuous mode in multicast enable flow
On Wed, Dec 1, 2021 at 4:00 PM wrote:
>
> From: Asaf Ravid
>
> When multicast promisc was being enabled it caused the unicast promisc
> to be disabled. This fix resolves this by setting NIX_RX_MODE_PROMISC
> when eth_dev->data->promiscuous is set, regardless.
>
> ci: skip_checkpatch skip_roc_check
>
> Fixes: 325d79c00a5a ("net/cnxk: support all multicast")
>
> Signed-off-by: Asaf Ravid
Acked-by: Jerin Jacob
Applied to dpdk-next-net-mrvl/for-next-net. Thanks
Changed the git log to:
net/cnxk: fix promiscuous mode in multicast enable flow
When multicast promiscuous was being enabled it caused the unicast
promiscuous to be disabled. This fix resolves this by setting
NIX_RX_MODE_PROMISC when eth_dev->data->promiscuous is set, regardless.
Fixes: 325d79c00a5a ("net/cnxk: support all multicast")
Cc: sta...@dpdk.org
Signed-off-by: Asaf Ravid
Acked-by: Jerin Jacob
> ---
> drivers/common/cnxk/roc_nix_npc.c | 2 +-
> drivers/net/cnxk/cnxk_ethdev_ops.c | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/common/cnxk/roc_nix_npc.c
> b/drivers/common/cnxk/roc_nix_npc.c
> index c0666c87d5..ad8839dde8 100644
> --- a/drivers/common/cnxk/roc_nix_npc.c
> +++ b/drivers/common/cnxk/roc_nix_npc.c
> @@ -96,7 +96,7 @@ roc_nix_npc_mcast_config(struct roc_nix *roc_nix, bool
> mcast_enable,
>
> if (mcast_enable)
> req->mode = NIX_RX_MODE_ALLMULTI;
> - else if (prom_enable)
> + if (prom_enable)
> req->mode = NIX_RX_MODE_PROMISC;
>
> return mbox_process(mbox);
> diff --git a/drivers/net/cnxk/cnxk_ethdev_ops.c
> b/drivers/net/cnxk/cnxk_ethdev_ops.c
> index ce5f1f7240..34e4809650 100644
> --- a/drivers/net/cnxk/cnxk_ethdev_ops.c
> +++ b/drivers/net/cnxk/cnxk_ethdev_ops.c
> @@ -517,7 +517,8 @@ cnxk_nix_allmulticast_enable(struct rte_eth_dev *eth_dev)
> {
> struct cnxk_eth_dev *dev = cnxk_eth_pmd_priv(eth_dev);
>
> - return roc_nix_npc_mcast_config(&dev->nix, true, false);
> + return roc_nix_npc_mcast_config(&dev->nix, true,
> + eth_dev->data->promiscuous);
> }
>
> int
> --
> 2.25.1
>
Re: [PATCH 1/1] mempool: implement index-based per core cache
Hi Konstatin,
Thank you for your comments and the test report!
> On Jan 10, 2022, at 8:26 PM, Ananyev, Konstantin
> wrote:
>
>
>
>
>> Current mempool per core cache implementation stores pointers to mbufs
>> On 64b architectures, each pointer consumes 8B
>> This patch replaces it with index-based implementation,
>> where in each buffer is addressed by (pool base address + index)
>> It reduces the amount of memory/cache required for per core cache
>>
>> L3Fwd performance testing reveals minor improvements in the cache
>> performance (L1 and L2 misses reduced by 0.60%)
>> with no change in throughput
>
> I feel really sceptical about that patch and the whole idea in general:
> - From what I read above there is no real performance improvement observed.
> (In fact on my IA boxes mempool_perf_autotest reports ~20% slowdown,
> see below for more details).
Currently, the optimizations (loop unroll and vectorization) are only
implemented for ARM64.
Similar optimizations can be implemented for x86 platforms which should close
the performance gap
and in my understanding should give better performance for a bulk size of 32.
> - Space utilization difference looks neglectable too.
Sorry, I did not understand this point.
> - The change introduces a new build time config option with a major
> limitation:
> All memzones in a pool have to be within the same 4GB boundary.
> To address it properly, extra changes will be required in init(/populate)
> part of the code.
I agree to the above mentioned challenges and I am currently working on
resolving these issues.
> All that will complicate mempool code, will make it more error prone
> and harder to maintain.
> But, as there is no real gain in return - no point to add such extra
> complexity at all.
>
> Konstantin
>
> CSX 2.1 GHz
> ==
>
> echo 'mempool_perf_autotest' | ./dpdk-test -n 4 --lcores='6-13' --no-pci
>
> params :
> rate_persec
>
> (normal/index-based/diff %)
> (with cache)
> cache=512 cores=1 n_get_bulk=32 n_put_bulk=32 n_keep=32 :
> 740989337.00/504116019.00/-31.97
> cache=512 cores=1 n_get_bulk=32 n_put_bulk=32 n_keep=128 :
> 756495155.00/615002931.00/-18.70
> cache=512 cores=2 n_get_bulk=32 n_put_bulk=32 n_keep=32 :
> 1483499110.00/1007248997.00/-32.10
> cache=512 cores=2 n_get_bulk=32 n_put_bulk=32 n_keep=128 :
> 1512439807.00/1229927218.00/-18.68
> cache=512 cores=8 n_get_bulk=32 n_put_bulk=32 n_keep=32 :
> 5933668757.00/4029048421.00/-32.10
> cache=512 cores=8 n_get_bulk=32 n_put_bulk=32 n_keep=128 :
> 6049234942.00/492344.00/-18.65
>
> (with user-owned cache)
> cache=512 cores=1 n_get_bulk=32 n_put_bulk=32 n_keep=32 :
> 630600499.00/504312627.00/-20.03
> cache=512 cores=1 n_get_bulk=32 n_put_bulk=32 n_keep=128 :
> 756259225.00/615042252.00/-18.67
> cache=512 cores=2 n_get_bulk=32 n_put_bulk=32 n_keep=32 :
> 1262052966.00/1007039283.00/-20.21
> cache=512 cores=2 n_get_bulk=32 n_put_bulk=32 n_keep=128 :
> 1517853081.00/1230818508.00/-18.91
> cache=512 cores=8 n_get_bulk=32 n_put_bulk=32 n_keep=32
> :5054529533.00/4028052273.00/-20.31
> cache=512 cores=8 n_get_bulk=32 n_put_bulk=32 n_keep=128 :
> 6059340592.00/4912893129.00/-18.92
>
>>
>> Suggested-by: Honnappa Nagarahalli
>> Signed-off-by: Dharmik Thakkar
>> Reviewed-by: Ruifeng Wang
>> ---
>> lib/mempool/rte_mempool.h | 114 +-
>> lib/mempool/rte_mempool_ops_default.c | 7 ++
>> 2 files changed, 119 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
>> index 1e7a3c15273c..4fabd3b1920b 100644
>> --- a/lib/mempool/rte_mempool.h
>> +++ b/lib/mempool/rte_mempool.h
>> @@ -50,6 +50,10 @@
>> #include
>> #include
>>
>> +#ifdef RTE_MEMPOOL_INDEX_BASED_LCORE_CACHE
>> +#include
>> +#endif
>> +
>> #include "rte_mempool_trace_fp.h"
>>
>> #ifdef __cplusplus
>> @@ -239,6 +243,9 @@ struct rte_mempool {
>> int32_t ops_index;
>>
>> struct rte_mempool_cache *local_cache; /**< Per-lcore local cache */
>> +#ifdef RTE_MEMPOOL_INDEX_BASED_LCORE_CACHE
>> +void *pool_base_value; /**< Base value to calculate indices */
>> +#endif
>>
>> uint32_t populated_size; /**< Number of populated objects. */
>> struct rte_mempool_objhdr_list elt_list; /**< List of objects in pool */
>> @@ -1314,7 +1321,19 @@ rte_mempool_cache_flush(struct rte_mempool_cache
>> *cache,
>> if (cache == NULL || cache->len == 0)
>> return;
>> rte_mempool_trace_cache_flush(cache, mp);
>> +
>> +#ifdef RTE_MEMPOOL_INDEX_BASED_LCORE_CACHE
>> +unsigned int i;
>> +unsigned int cache_len = cache->len;
>> +void *obj_table[RTE_MEMPOOL_CACHE_MAX_SIZE * 3];
>> +void *base_value = mp->pool_base_value;
>> +uint32_t *cache_objs = (ui
Re: [PATCH 0/1] mempool: implement index-based per core cache
Hi, Thank you for your valuable review comments and suggestions! I will be sending out a v2 in which I have increased the size of the mempool to 32GB by using division by sizeof(uintptr_t). However, I am seeing ~5% performance degradation with mempool_perf_autotest (for bulk size of 32) with this change when compared to the base performance. Earlier, without this change, I was seeing an improvement of ~13% compared to base performance. So, this is a significant degradation. I would appreciate your review comments on v2. Thank you! > On Jan 10, 2022, at 12:38 AM, Jerin Jacob wrote: > > On Sat, Jan 8, 2022 at 3:07 PM Morten Brørup > wrote: >> >>> From: Bruce Richardson [mailto:bruce.richard...@intel.com] >>> Sent: Friday, 7 January 2022 14.51 >>> >>> On Fri, Jan 07, 2022 at 12:29:23PM +0100, Morten Brørup wrote: > From: Bruce Richardson [mailto:bruce.richard...@intel.com] > Sent: Friday, 7 January 2022 12.16 > > On Sat, Dec 25, 2021 at 01:16:03AM +0100, Morten Brørup wrote: >>> From: Dharmik Thakkar [mailto:dharmik.thak...@arm.com] Sent: > Friday, 24 >>> December 2021 23.59 >>> >>> Current mempool per core cache implementation stores pointers >>> to > mbufs >>> On 64b architectures, each pointer consumes 8B This patch >>> replaces > it >>> with index-based implementation, where in each buffer is >>> addressed > by >>> (pool base address + index) It reduces the amount of >>> memory/cache >>> required for per core cache >>> >>> L3Fwd performance testing reveals minor improvements in the >>> cache >>> performance (L1 and L2 misses reduced by 0.60%) with no change >>> in >>> throughput >>> >>> Micro-benchmarking the patch using mempool_perf_test shows > significant >>> improvement with majority of the test cases >>> >> >> I still think this is very interesting. And your performance >>> numbers > are >> looking good. >> >> However, it limits the size of a mempool to 4 GB. As previously >> discussed, the max mempool size can be increased by multiplying >>> the > index >> with a constant. >> >> I would suggest using sizeof(uintptr_t) as the constant >>> multiplier, > so >> the mempool can hold objects of any size divisible by > sizeof(uintptr_t). >> And it would be silly to use a mempool to hold objects smaller >>> than >> sizeof(uintptr_t). >> >> How does the performance look if you multiply the index by >> sizeof(uintptr_t)? >> > > Each mempool entry is cache aligned, so we can use that if we want >>> a > bigger > multiplier. Thanks for chiming in, Bruce. Please also read this discussion about the multiplier: http://inbox.dpdk.org/dev/calbae1prqyyog96f6ecew1vpf3toh1h7mzzuliy95z9xjbr...@mail.gmail.com/ >>> >>> I actually wondered after I had sent the email whether we had indeed an >>> option to disable the cache alignment or not! Thanks for pointing out >>> that >>> we do. This brings a couple additional thoughts: >>> >>> * Using indexes for the cache should probably be a runtime flag rather >>> than >>> a build-time one. >>> * It would seem reasonable to me to disallow use of the indexed-cache >>> flag >>> and the non-cache aligned flag simultaneously. >>> * On the offchance that that restriction is unacceptable, then we can >>> make things a little more complicated by doing a runtime computation >>> of >>> the "index-shiftwidth" to use. >>> >>> Overall, I think defaulting to cacheline shiftwidth and disallowing >>> index-based addressing when using unaligned buffers is simplest and >>> easiest >>> unless we can come up with a valid usecase for needing more than that. >>> >>> /Bruce >> >> This feature is a performance optimization. >> >> With that in mind, it should not introduce function pointers or similar >> run-time checks or in the fast path, to determine what kind of cache to use >> per mempool. And if an index multiplier is implemented, it should be a >> compile time constant, probably something between sizeof(uintptr_t) or >> RTE_MEMPOOL_ALIGN (=RTE_CACHE_LINE_SIZE). >> >> The patch comes with a tradeoff between better performance and limited >> mempool size, and possibly some limitations regarding very small objects >> that are not cache line aligned to avoid wasting memory >> (RTE_MEMPOOL_POPULATE_F_ALIGN_OBJ). >> >> With no multiplier, the only tradeoff is that the mempool size is limited to >> 4 GB. >> >> If the multiplier is small (i.e. 8 bytes) the only tradeoff is that the >> mempool size is limited to 32 GB. (And a waste of memory for objects smaller >> than 8 byte; but I don't think anyone would use a mempool to hold objects >> smaller than 8 byte.) >> >> If the multiplier is larger (i.e. 64 bytes cache line size), the mempool >> size is instead limited to 256 GB, but RTE_MEMPOOL_POPULATE_F_ALIGN_OBJ has >> no effect. >>
[PATCH v2 0/1] mempool: implement index-based per core cache
Current mempool per core cache implementation stores pointers to mbufs On 64b architectures, each pointer consumes 8B This patch replaces it with index-based implementation, where in each buffer is addressed by (pool base address + index) It reduces the amount of memory/cache required for per core cache L3Fwd performance testing reveals minor improvements in the cache performance (L1 and L2 misses reduced by 0.60%) with no change in throughput Micro-benchmarking the patch using mempool_perf_test shows significant improvement with majority of the test cases Number of cores = 1: n_get_bulk=1 n_put_bulk=1 n_keep=32 %_change_with_patch=18.01 n_get_bulk=1 n_put_bulk=1 n_keep=128 %_change_with_patch=19.91 n_get_bulk=1 n_put_bulk=4 n_keep=32 %_change_with_patch=-20.37 (regression) n_get_bulk=1 n_put_bulk=4 n_keep=128 %_change_with_patch=-17.01 (regression) n_get_bulk=1 n_put_bulk=32 n_keep=32 %_change_with_patch=-25.06 (regression) n_get_bulk=1 n_put_bulk=32 n_keep=128 %_change_with_patch=-23.81 (regression) n_get_bulk=4 n_put_bulk=1 n_keep=32 %_change_with_patch=53.93 n_get_bulk=4 n_put_bulk=1 n_keep=128 %_change_with_patch=60.90 n_get_bulk=4 n_put_bulk=4 n_keep=32 %_change_with_patch=1.64 n_get_bulk=4 n_put_bulk=4 n_keep=128 %_change_with_patch=8.76 n_get_bulk=4 n_put_bulk=32 n_keep=32 %_change_with_patch=-4.71 (regression) n_get_bulk=4 n_put_bulk=32 n_keep=128 %_change_with_patch=-3.19 (regression) n_get_bulk=32 n_put_bulk=1 n_keep=32 %_change_with_patch=65.63 n_get_bulk=32 n_put_bulk=1 n_keep=128 %_change_with_patch=75.19 n_get_bulk=32 n_put_bulk=4 n_keep=32 %_change_with_patch=11.75 n_get_bulk=32 n_put_bulk=4 n_keep=128 %_change_with_patch=15.52 n_get_bulk=32 n_put_bulk=32 n_keep=32 %_change_with_patch=13.45 n_get_bulk=32 n_put_bulk=32 n_keep=128 %_change_with_patch=11.58 Number of core = 2: n_get_bulk=1 n_put_bulk=1 n_keep=32 %_change_with_patch=18.21 n_get_bulk=1 n_put_bulk=1 n_keep=128 %_change_with_patch=21.89 n_get_bulk=1 n_put_bulk=4 n_keep=32 %_change_with_patch=-21.21 (regression) n_get_bulk=1 n_put_bulk=4 n_keep=128 %_change_with_patch=-17.05 (regression) n_get_bulk=1 n_put_bulk=32 n_keep=32 %_change_with_patch=-26.09 (regression) n_get_bulk=1 n_put_bulk=32 n_keep=128 %_change_with_patch=-23.49 (regression) n_get_bulk=4 n_put_bulk=1 n_keep=32 %_change_with_patch=56.28 n_get_bulk=4 n_put_bulk=1 n_keep=128 %_change_with_patch=67.69 n_get_bulk=4 n_put_bulk=4 n_keep=32 %_change_with_patch=1.45 n_get_bulk=4 n_put_bulk=4 n_keep=128 %_change_with_patch=8.84 n_get_bulk=4 n_put_bulk=32 n_keep=32 %_change_with_patch=-5.27 (regression) n_get_bulk=4 n_put_bulk=32 n_keep=128 %_change_with_patch=-3.09 (regression) n_get_bulk=32 n_put_bulk=1 n_keep=32 %_change_with_patch=76.11 n_get_bulk=32 n_put_bulk=1 n_keep=128 %_change_with_patch=86.06 n_get_bulk=32 n_put_bulk=4 n_keep=32 %_change_with_patch=11.86 n_get_bulk=32 n_put_bulk=4 n_keep=128 %_change_with_patch=16.55 n_get_bulk=32 n_put_bulk=32 n_keep=32 %_change_with_patch=13.01 n_get_bulk=32 n_put_bulk=32 n_keep=128 %_change_with_patch=11.51 >From analyzing the results, it is clear that for n_get_bulk and n_put_bulk sizes of 32 there is no performance regression IMO, the other sizes are not practical from performance perspective and the regression in those cases can be safely ignored An attempt to increase the size of mempool to 32GB, by dividing the index by sizeof(uintptr_t), has led to a performance degradation of ~5% compared to the base performance --- v2: - Increase size of mempool to 32GB (Morten) - Improve performance for other platforms using dual loop unrolling --- Dharmik Thakkar (1): mempool: implement index-based per core cache lib/mempool/rte_mempool.h | 150 +- lib/mempool/rte_mempool_ops_default.c | 7 ++ 2 files changed, 156 insertions(+), 1 deletion(-) -- 2.17.1
[PATCH v2 1/1] mempool: implement index-based per core cache
Current mempool per core cache implementation stores pointers to mbufs
On 64b architectures, each pointer consumes 8B
This patch replaces it with index-based implementation,
where in each buffer is addressed by (pool base address + index)
It reduces the amount of memory/cache required for per core cache
L3Fwd performance testing reveals minor improvements in the cache
performance (L1 and L2 misses reduced by 0.60%)
with no change in throughput
Suggested-by: Honnappa Nagarahalli
Signed-off-by: Dharmik Thakkar
Reviewed-by: Ruifeng Wang
---
lib/mempool/rte_mempool.h | 150 +-
lib/mempool/rte_mempool_ops_default.c | 7 ++
2 files changed, 156 insertions(+), 1 deletion(-)
diff --git a/lib/mempool/rte_mempool.h b/lib/mempool/rte_mempool.h
index 1e7a3c15273c..f2403fbc97a7 100644
--- a/lib/mempool/rte_mempool.h
+++ b/lib/mempool/rte_mempool.h
@@ -50,6 +50,10 @@
#include
#include
+#ifdef RTE_MEMPOOL_INDEX_BASED_LCORE_CACHE
+#include
+#endif
+
#include "rte_mempool_trace_fp.h"
#ifdef __cplusplus
@@ -239,6 +243,9 @@ struct rte_mempool {
int32_t ops_index;
struct rte_mempool_cache *local_cache; /**< Per-lcore local cache */
+#ifdef RTE_MEMPOOL_INDEX_BASED_LCORE_CACHE
+ void *pool_base_value; /**< Base value to calculate indices */
+#endif
uint32_t populated_size; /**< Number of populated objects. */
struct rte_mempool_objhdr_list elt_list; /**< List of objects in pool */
@@ -1314,7 +1321,22 @@ rte_mempool_cache_flush(struct rte_mempool_cache *cache,
if (cache == NULL || cache->len == 0)
return;
rte_mempool_trace_cache_flush(cache, mp);
+
+#ifdef RTE_MEMPOOL_INDEX_BASED_LCORE_CACHE
+ unsigned int i;
+ unsigned int cache_len = cache->len;
+ void *obj_table[RTE_MEMPOOL_CACHE_MAX_SIZE * 3];
+ void *base_value = mp->pool_base_value;
+ uint32_t *cache_objs = (uint32_t *) cache->objs;
+ for (i = 0; i < cache_len; i++) {
+ /* Scale by sizeof(uintptr_t) to accommodate 16GB/32GB mempool
*/
+ cache_objs[i] = cache_objs[i] << 3;
+ obj_table[i] = (void *) RTE_PTR_ADD(base_value, cache_objs[i]);
+ }
+ rte_mempool_ops_enqueue_bulk(mp, obj_table, cache->len);
+#else
rte_mempool_ops_enqueue_bulk(mp, cache->objs, cache->len);
+#endif
cache->len = 0;
}
@@ -1334,7 +1356,14 @@ static __rte_always_inline void
rte_mempool_do_generic_put(struct rte_mempool *mp, void * const *obj_table,
unsigned int n, struct rte_mempool_cache *cache)
{
+#ifdef RTE_MEMPOOL_INDEX_BASED_LCORE_CACHE
+ uint32_t *cache_objs;
+ void *base_value;
+ uint32_t i;
+ uint32_t temp_objs[2];
+#else
void **cache_objs;
+#endif
/* increment stat now, adding in mempool always success */
RTE_MEMPOOL_STAT_ADD(mp, put_bulk, 1);
@@ -1344,7 +1373,13 @@ rte_mempool_do_generic_put(struct rte_mempool *mp, void
* const *obj_table,
if (unlikely(cache == NULL || n > RTE_MEMPOOL_CACHE_MAX_SIZE))
goto ring_enqueue;
+#ifdef RTE_MEMPOOL_INDEX_BASED_LCORE_CACHE
+ cache_objs = (uint32_t *) cache->objs;
+ cache_objs = &cache_objs[cache->len];
+ base_value = mp->pool_base_value;
+#else
cache_objs = &cache->objs[cache->len];
+#endif
/*
* The cache follows the following algorithm
@@ -1354,13 +1389,50 @@ rte_mempool_do_generic_put(struct rte_mempool *mp, void
* const *obj_table,
*/
/* Add elements back into the cache */
+
+#ifdef RTE_MEMPOOL_INDEX_BASED_LCORE_CACHE
+#if defined __ARM_NEON
+ uint64x2_t v_obj_table;
+ uint64x2_t v_base_value = vdupq_n_u64((uint64_t)base_value);
+ uint32x2_t v_cache_objs;
+
+ for (i = 0; i < (n & ~0x1); i += 2) {
+ v_obj_table = vld1q_u64((const uint64_t *)&obj_table[i]);
+ v_cache_objs = vqmovn_u64(vsubq_u64(v_obj_table, v_base_value));
+
+ /* Scale by sizeof(uintptr_t) to accommodate 16GB/32GB mempool
*/
+ v_cache_objs = vshr_n_u32(v_cache_objs, 3);
+ vst1_u32(cache_objs + i, v_cache_objs);
+ }
+#else
+ for (i = 0; i < (n & ~0x1); i += 2) {
+ temp_objs[0] = (uint32_t) RTE_PTR_DIFF(obj_table[i],
base_value);
+ temp_objs[1] = (uint32_t) RTE_PTR_DIFF(obj_table[i + 1],
base_value);
+ /* Scale by sizeof(uintptr_t) to accommodate 16GB/32GB mempool
*/
+ cache_objs[i] = temp_objs[0] >> 3;
+ cache_objs[i + 1] = temp_objs[1] >> 3;
+ }
+#endif
+ if (n & 0x1) {
+ temp_objs[0] = (uint32_t) RTE_PTR_DIFF(obj_table[i],
base_value);
+
+ /* Divide by sizeof(uintptr_t) to accommodate 16G/32G mempool */
+ cache_objs[i] = temp_objs[0] >> 3;
+ }
+#else
rte_memcpy(&cache_objs[0], obj_table, sizeof(void *) * n);
+#endif
cach
Re: [PATCH] doc: update matching versions in ice guide
On Thu, Jan 13, 2022 at 3:12 AM Qi Zhang wrote: > > Add recommended matching list for ice PMD in DPDK 21.08 and DPDK 21.11. Any reason why this is not marked for backport in 21.11? > > Signed-off-by: Qi Zhang > --- > doc/guides/nics/ice.rst | 4 > 1 file changed, 4 insertions(+) > > diff --git a/doc/guides/nics/ice.rst b/doc/guides/nics/ice.rst > index f95fef8cf0..a1780c46c3 100644 > --- a/doc/guides/nics/ice.rst > +++ b/doc/guides/nics/ice.rst > @@ -58,6 +58,10 @@ The detailed information can refer to chapter Tested > Platforms/Tested NICs in re > > +---+---+-+---+--+---+ > |21.05 | 1.6.5 | 1.3.26 | 1.3.30 |1.3.6 > |3.0| > > +---+---+-+---+--+---+ > + |21.08 | 1.7.16| 1.3.27 | 1.3.31 |1.3.7 > |3.1| > + > +---+---+-+---+--+---+ > + |21.11 | 1.7.16| 1.3.27 | 1.3.31 |1.3.7 > |3.1| > + > +---+---+-+---+--+---+ > > Pre-Installation Configuration > -- -- David Marchand
