Re: [dpdk-dev] [dpdk-stable] [PATCH] examples/l2fwd: fix l2fwd long options parse issue
On Thu, Jun 10, 2021 at 3:02 AM SunChengLian wrote:
>
> Readd other long options case in l2fwd_parse_args function
> to ensure all long options will work well.
Please, be more explicit about the thing you want to fix.
I understand --no-mac-updating is broken.
You want to fix this long option.
Is this correct?
The Fixes: should follow the common format.
I recommend setting this alias in your config so that you only need to
call "git fixline $sha1":
$ git config alias.fixline "log -1 --abbrev=12 --format='Fixes: %h
(\"%s\")%nCc: %ae'"
So here, it should be:
Fixes: fa19eb20d212 ("examples/l2fwd: add forwarding port mapping option")
And I recommend aligning this example with others.
Iow do something like:
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 32d405e65a..06cf8e1f14 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -433,13 +433,14 @@ enum {
/* first long only option value must be >= 256, so that we won't
* conflict with short options */
- CMD_LINE_OPT_MIN_NUM = 256,
+ CMD_LINE_OPT_MAC_UPDATING_NUM = 256,
+ CMD_LINE_OPT_NO_MAC_UPDATING_NUM,
CMD_LINE_OPT_PORTMAP_NUM,
};
static const struct option lgopts[] = {
- { CMD_LINE_OPT_MAC_UPDATING, no_argument, &mac_updating, 1},
- { CMD_LINE_OPT_NO_MAC_UPDATING, no_argument, &mac_updating, 0},
+ { CMD_LINE_OPT_MAC_UPDATING, no_argument, 0,
CMD_LINE_OPT_MAC_UPDATING_NUM},
+ { CMD_LINE_OPT_NO_MAC_UPDATING, no_argument, 0,
CMD_LINE_OPT_NO_MAC_UPDATING_NUM},
{ CMD_LINE_OPT_PORTMAP_CONFIG, 1, 0, CMD_LINE_OPT_PORTMAP_NUM},
{NULL, 0, 0, 0}
};
@@ -492,6 +493,14 @@ l2fwd_parse_args(int argc, char **argv)
break;
/* long options */
+ case CMD_LINE_OPT_MAC_UPDATING_NUM:
+ mac_updating = 1;
+ break;
+
+ case CMD_LINE_OPT_NO_MAC_UPDATING_NUM:
+ mac_updating = 0;
+ break;
+
case CMD_LINE_OPT_PORTMAP_NUM:
ret = l2fwd_parse_port_pair_config(optarg);
if (ret) {
In a followup patch, the "mac-updating" option can be removed since
the associated mac_updating variable is set to 1 by default.
--
David Marchand
Re: [dpdk-dev] [RFC v3 0/6] Add mdev (Mediated device) support in DPDK
01/06/2021 05:06, Chenbo Xia: > Hi everyone, > > This is a draft implementation of the mdev (Mediated device [1]) > support in DPDK PCI bus driver. Mdev is a way to virtualize devices > in Linux kernel. Based on the device-api (mdev_type/device_api), > there could be different types of mdev devices (e.g. vfio-pci). Please could you illustrate with an usage of mdev in DPDK? What does it enable which is not possible today? > In this patchset, the PCI bus driver is extended to support scanning > and probing the mdev devices whose device-api is "vfio-pci". > > +-+ > | PCI bus | > +++ > | > ++---+---++ > || || > Physical PCI devices ... Mediated PCI devices ... > > The first four patches in this patchset are mainly preparation of mdev > bus support. The left two patches are the key implementation of mdev bus. > > The implementation of mdev bus in DPDK has several options: > > 1: Embed mdev bus in current pci bus > >This patchset takes this option for an example. Mdev has several >device types: pci/platform/amba/ccw/ap. DPDK currently only cares >pci devices in all mdev device types so we could embed the mdev bus >into current pci bus. Then pci bus with mdev support will scan/plug/ >unplug/.. not only normal pci devices but also mediated pci devices. I think it is a different bus. It would be cleaner to not touch the PCI bus. Having a separate bus will allow an easy way to identify a device with the new generic devargs syntax, example: bus=mdev,uuid=XXX or more complex: bus=mdev,uuid=XXX/class=crypto/driver=qat,foo=bar > 2: A new mdev bus that scans mediated pci devices and probes mdev driver to >plug-in pci devices to pci bus > >If we took this option, a new mdev bus will be implemented to scan >mediated pci devices and a new mdev driver for pci devices will be >implemented in pci bus to plug-in mediated pci devices to pci bus. > >Our RFC v1 takes this option: > > http://patchwork.dpdk.org/project/dpdk/cover/20190403071844.21126-1-tiwei@intel.com/ > >Note that: for either option 1 or 2, device drivers do not know the >implementation difference but only use structs/functions exposed by >pci bus. Mediated pci devices are different from normal pci devices >on: 1. Mediated pci devices use UUID as address but normal ones use BDF. >2. Mediated pci devices may have some capabilities that normal pci >devices do not have. For example, mediated pci devices could have >regions that have sparse mmap capability, which allows a region to have >multiple mmap areas. Another example is mediated pci devices may have >regions/part of regions not mmaped but need to access them. Above >difference will change the current ABI (i.e., struct rte_pci_device). >Please check 5th and 6th patch for details. > > 3. A brand new mdev bus that does everything > >This option will implement a new and standalone mdev bus. This option >does not need any changes in current pci bus but only needs some shared >code (linux vfio part) in pci bus. Drivers of devices that support mdev >will register itself as a mdev driver and do not rely on pci bus anymore. >This option, IMHO, will make the code clean. The only potential problem >may be code duplication, which could be solved by making code of linux >vfio part of pci bus common and shared. Yes I prefer this third option. We can find an elegant way of sharing some VFIO code between buses.
Re: [dpdk-dev] [RFC v3 4/6] eal: add a helper for reading string from sysfs
01/06/2021 05:06, Chenbo Xia: > From: Tiwei Bie > > This patch adds a helper for reading string from sysfs. > > Signed-off-by: Cunming Liang > Signed-off-by: Tiwei Bie > --- > lib/eal/common/eal_filesystem.h | 10 ++ > lib/eal/freebsd/eal.c | 22 ++ > lib/eal/linux/eal.c | 22 ++ > lib/eal/version.map | 3 +++ > 4 files changed, 57 insertions(+) 3 separate comments: 1/ How much code is portable between Linux and FreeBSD? I guess the path will be different? 2/ Please think about Windows stub. 3/ Instead of EAL, we should start lib/sysfs/ I have other ideas of sysfs functions for PMD use.
Re: [dpdk-dev] [PATCH] malloc: fix size annotation for NUMA-aware realloc
On Thu, Jun 10, 2021 at 2:09 PM David Marchand wrote: > > __rte_alloc_size is mapped to compiler alloc_size attribute. I get the following splat from dts. I don't see how this patch could have an impact. There is an odd mac address (00:00:00:00:51:14), so maybe a broken nic / firmware / forced mac address. But I don't think it is the reason of the failure since other tests pass. Can someone from DTS or net/i40e guys have a look? Thanks. 10/06/2021 15:48:52dut.172.18.0.20: x86_64-native-linux-gcc/app/dpdk-testpmd -l 4,5 -n 6 -a :18:00.0 -a :3b:00.0 --file-prefix=dpdk_90027_20210610154417 -- -i ... 10/06/2021 15:49:03dut.172.18.0.20: port stop all 10/06/2021 15:49:03dut.172.18.0.20: ... 10/06/2021 15:49:03dut.172.18.0.20: port config mtu 0 9000 10/06/2021 15:49:03dut.172.18.0.20: 10/06/2021 15:49:03dut.172.18.0.20: port config mtu 1 9000 10/06/2021 15:49:03dut.172.18.0.20: 10/06/2021 15:49:03dut.172.18.0.20: show port info 0 10/06/2021 15:49:03dut.172.18.0.20: ... 10/06/2021 15:49:03dut.172.18.0.20: port start all 10/06/2021 15:49:04dut.172.18.0.20: Port 0: 00:00:00:00:51:14 Port 1: 68:05:CA:34:88:48 Checking link statuses... Done 10/06/2021 15:49:04dut.172.18.0.20: set fwd mac 10/06/2021 15:49:04dut.172.18.0.20: 10/06/2021 15:49:04dut.172.18.0.20: start 10/06/2021 15:49:04dut.172.18.0.20: ... 10/06/2021 15:49:04 tester: echo -n '' > scapyResult.txt 10/06/2021 15:49:04 tester: 10/06/2021 15:49:04 tester: scapy 10/06/2021 15:49:04 tester: [39mINFO: Can't import matplotlib. Won't be able to plot. [0m [39mINFO: Can't import PyX. Won't be able to use psdump() or pdfdump(). [0m [33m [1mWARNING: IPython not available. Using standard Python shell instead. AutoCompletion, History are disabled. [0m [0m [32m [1m [0m [34m [1m [0m [32m [1m aSPY//YASa[0m [34m [1m [0m [32m [1m apCY//YCa [0m [34m [1m | [0m [32m [1msY//YSpcs scpCY//Pp [0m [34m [1m | Welcome to Scapy [0m [32m [1m ayp ayyySCP//Pp syY//C [0m [34m [1m | Version 2.4.4 [0m [32m [1m AYAsA///Ps cY//S [0m [34m [1m | [0m [32m [1m pY//p cSSps y//Y [0m [34m [1m | https://github.com/secdev/ [0m [32m [1m S///a pP///AC//Y [0m [34m [1m | [0m [32m [1m A//AcyPC [0m [34m [1m | Have fun! [0m [32m [1m p///AcsC///a [0m [34m [1m | [0m [32m [1m PYCpc A//A [0m [34m [1m | Craft me if you can. [0m [32m [1m scp///pSP///p p//Y [0m [34m [1m | -- IPv6 layer [0m [32m [1m sY/y caa S//P [0m [34m [1m | [0m [32m [1m cayCyayP//Ya pY/Ya [0m [32m [1msY/PsYYCc aC//Yp [0m [32m [1m sc sccaCY//PCypaapyCP//YSs [0m [32m [1m spCPY//YPSps [0m [32m [1m ccaacs [0m [32m [1m [0m 10/06/2021 15:49:06 tester: dutmac="00:00:00:00:51:14" 10/06/2021 15:49:06 tester: [34m [1m 10/06/2021 15:49:06 tester: sendp(Ether(dst=dutmac, src="52:00:00:00:00:00")/IP()/Raw(load="P"*8987), iface="enp134s0f0") 10/06/2021 15:49:06 tester: . Sent 1 packets. 10/06/2021 15:49:08 tester: exit() 10/06/2021 15:49:09 tester: 10/06/2021 15:49:14dut.172.18.0.20: show port stats 1 10/06/2021 15:49:14dut.172.18.0.20: NIC statistics for port 1 RX-packets: 7 RX-missed: 0 RX-bytes: 770 RX-errors: 0 RX-nombuf: 0 TX-packets: 4 TX-errors: 0 TX-bytes: 440 Throughput (since last show) Rx-pps:0 Rx-bps: 352 Tx-pps:0 Tx-bps: 352 10/06/2021 15:49:14dut.172.18.0.20: show port stats 0 10/06/2021 15:49:14dut.172.18.0.20: NIC statistics for port 0 RX-packets: 8 RX-missed: 0 RX-bytes: 9795 RX-errors: 0 RX-nombuf: 0 TX-packets: 4 TX-errors: 0 TX-bytes: 440 Throughput (since last show) Rx-pps:0 Rx-bps: 7736 Tx-pps:0 Tx-bps: 352 #
Re: [dpdk-dev] [PATCH] malloc: fix size annotation for NUMA-aware realloc
On Fri, Jun 11, 2021 at 9:26 AM David Marchand wrote: > > On Thu, Jun 10, 2021 at 2:09 PM David Marchand > wrote: > > > > __rte_alloc_size is mapped to compiler alloc_size attribute. > > I get the following splat from dts. There is the exact same output in last night next-net-intel test: https://lab.dpdk.org/results/dashboard/tarballs/15461/ -- David Marchand
Re: [dpdk-dev] [RFC 00/14] mlx5: support SubFunction
11/06/2021 07:14, Xia, Chenbo: > From: Thomas Monjalon > > 10/06/2021 12:33, Ferruh Yigit: > > > On 5/27/2021 2:37 PM, Xueming Li wrote: > > > > SubFunction [1] is a portion of the PCI device, a SF netdev has its > > own > > > > dedicated queues(txq, rxq). A SF shares PCI level resources with other > > > > SFs and/or with its parent PCI function. Auxiliary bus is the > > > > fundamental of SF. > > > > > > > > This patch set introduces SubFunction support for mlx5 PMD driver > > > > including class net, regex, vdpa and compress. > > > > > > > > > > There is already an mdev patch, originated from long ago. Aren't > > subfunctions > > > presented as mdev device? If so can't we use mdev for it? > > > > No unfortunately that's different. > > mlx5 SF is based on top of auxiliary bus in the kernel/sysfs. > > Just out of curiosity: > > Does SF use mdev before aux bus is introduced in kernel. I see some history > of it but am not sure: [1] seems SF was base on mdev. [2] seems BlueField > software v2.5 is using mdev for SF. I saw it yesterday and try to figure > out the history. Since you are here, guess you know something 😊 > > [1] > https://patchwork.ozlabs.org/project/netdev/cover/20191107160448.20962-1-pa...@mellanox.com/ > [2] https://docs.mellanox.com/display/BlueFieldSWv25011176/Mediated+Devices Kernel maintainers rejected the use of mdev for this purpose and suggested to use a real bus. You can follow the discussion here: https://lore.kernel.org/netdev/20191108205204.gb1277...@kroah.com/ Does Intel plan to use mdev for SF? For the sake of follow-up discussion, this is the official mdev doc: https://www.kernel.org/doc/Documentation/vfio-mediated-device.txt
[dpdk-dev] DPDK 21.08 NVIDIA Mellanox Roadmap
Below is NVIDIA Mellanox's roadmap for DPDK21.08, on which we are currently working: rte_flow new APIs: === [1] Extend rte_ipv4_hdr with ihl field separated from version field(while persevering the original API) Motivation: to allow efficient implementation of match on ihl field in ipv4. Please note that the combination field of version and Ihl is maintained. mlx5 PMD updates: == mlx5 PMD will support the rte_flow update changes listed above and below [2]Add non-default mode of rejecting duplicating flow rules Motivation: some at-scale applications may not keep a copy of all the inserted rules. At the same time they wish to avoid duplicated rules in the HW. For that we are adding support for non-default rejection of duplicated rule. When application wants to get an error message for duplicated rule a specific new devargs would needed to be used. [3] extend meter implantation Motivation: 1. currently each flow can execute one meter action. Some applications requires a connection(as manifested as rte rule) to be metered according to more than one meter. We are enhancing the meter implementation in our PMD to allow multiple meters to be cascaded to construct meter hierarchy so packet can be accounted for by several meters w/o using multiple flows and jump actions between them. 2. At the time we are extending the implementation to allow a single meter action to be shared by rte rules inserted with different ports. 3. We are enhancing the steering mechanism for meter to allow actions to be trigged by yellow color(the same actions allowed by green and red colors) [4] Extend flow dump output to include further information about the flows Motivation: current implementation of flow dump is very limited in its content. We are adding further information as part of the flow dump - counter and their metric(hits, bytes, id), modify_header(action type), encap/decap(index number) [5] improved rule insertion performance Motivation: in order to support at scale insertion of rules we are improving several aspects of the MLX5 PMD. Most noticeable are improvement in the memory allocation, set tag and mark actions. [6] Introduce Scalable Function(SF) support Motivation: we are introducing a new function called SF. As VFs resources are limited and dependent on the PCI bus we are adding SF with the same functionality but with fewer limitations. SFs share PCI resources with other SFs and/or with it parent PCI function but it's not a PCI device. In this released we are introducing SF support for net, regex, compress and vdpa classes. To support SFs we are also introducing auxiliary bus as the foundation for SFs. [7] Extend vxlan header matching to include last 8 bits Motivation: in order to provide the ability to match in steering rules on vxlan alert bit, we are extending the vxlan matching to support the last 8 bits of the header. New PMDs: == [8] Implement look aside AES-XTS encryption/decryption PMD over Bluefield-2 smartNic and connect6-DX to support existing rte_cryptodev and rte_crypto APIs testpmd updates: testpmd updated to support the changes listed above
Re: [dpdk-dev] [PATCH v1 0/8] use GCC's C11 atomic builtins for test
On Fri, Jun 4, 2021 at 11:46 AM Joyce Kong wrote: > > Since C11 memory model is adopted in DPDK now[1], use GCC's > atomic builtins in test cases. > > [1]https://www.dpdk.org/blog/2021/03/26/dpdk-adopts-the-c11-memory-model/ > > Joyce Kong (8): > test/ticketlock: use GCC atomic builtins for lcores sync > test/spinlock: use GCC atomic builtins for lcores sync > test/rwlock: use GCC atomic builtins for lcores sync > test/mcslock: use GCC atomic builtins for lcores sync > test/mempool: remove unused variable for lcores sync > test/mempool_perf: use GCC atomic builtins for lcores sync > test/service_cores: use GCC atomic builtins for lock sync > test/rcu_perf: use GCC atomic builtins for data sync Just a nit, use rte_wait_until_equal() instead of those sync loops. Rest lgtm, thanks. -- David Marchand
Re: [dpdk-dev] 19.11.9 patches review and test - V2
Hi Christian, Testing with dpdk v19.11.9-rc2 from Intel is almost finished, some build issues and telemetry issue are found. # Basic Intel(R) NIC testing * PF(i40e, ixgbe): test scenarios including rte_flow/TSO/Jumboframe/checksum offload/Tunnel, etc. Listed but not all. - Known issues as below: 1) https://bugs.dpdk.org/show_bug.cgi?id=731 – [dpdk-19.11.9] telemetry: python3 /root/dpdk/usertools/dpdk-telemetry-client.py prompt connection refused) Fixed commit is af68c1d699be6c369e296b775bdbf13ae18b79cc eal: fix hang in control thread creation 2) https://bugs.dpdk.org/show_bug.cgi?id=687: unit_tests_power/power_cpufreq: unit test failed. This issue is found in 21.05 and dev has patches to fix it but not merged into main. * VF(i40e,ixgbe): test scenarios including vf-rte_flow/TSO/Jumboframe/checksum offload/Tunnel, Listed but not all. - No new issues are found. * PF/VF(ice): test scenarios including switch features/Flow Director/Advanced RSS/ACL/DCF/Flexible Descriptor and so on, Listed but not all. - One 4 known issues is found, but won't fix on LTS19.11. [dpdk-19.11.7] userspace_ethtool/retrieve_eeprom: Dumped eeprom not same as linux dumped. Fixed patches are based on 4 ice share code, not be contained in LTS19.11. * Build or compile: * Build: cover the build test combination with different GCC/Clang and the popular OS revision such as Ubuntu20.04, CentOS8.3， SUSE15, Fedora34 and so on. Listed but not all. - Two new issues are found 1) https://bugs.dpdk.org/show_bug.cgi?id=732 [dpdk-19.11.9-rc2] DPDK build failed on Win10 2) https://bugs.dpdk.org/show_bug.cgi?id=728 [dpdk-19.11.9-rc2]When compiling dpdk with make or meson under SUSE Linux Enterprise Server 15 SP2, the compilation fails - Known issue is Fedora34 GCC11 and Clang12 build issue a.GCC11 issue is same as https://bugs.dpdk.org/show_bug.cgi?id=692 : Bug 692 - bnx2x build fail on Fedora 34 with gcc 11. This issue is found in 21.05 with Fedora34 GCC 11. Has patches to fix in 21.05 and merged into main. Applies below tree patches can build passed. Patches link: [v3,1/4] net/bnx2x: fix build with gcc11 - Patchwork (dpdk.org) [v3,2/4] net/bnx2x: fix build with gcc11 - Patchwork (dpdk.org) test/table: fix build with GCC 11 - Patchwork (dpdk.org) b.Clang12 issue: app/test/dpdk-test.p/test_cmdline_num.c.o build failed on Fedora34 with Clang12. Fixed commits are 5ac070cfed test/cmdline: silence clang 12 warning & 414245bbc5 test/cmdline: fix inputs array(Refer to Kevin's reply) * Intel NIC single core/NIC performance: test scenarios including PF/VF single core performance test(AVX2+AVX512) test and so on. Listed but not all. - All passed. No big data drop. # Basic cryptodev and virtio testing * Virtio: both function and performance test are covered. Such as PVP/Virtio_loopback/virtio-user loopback/virtio-net VM2VM perf testing, etc.. Listed but not all. - One known issues about The UDP fragmentation offload feature of Virtio-net device can’t be turned on in the VM, kernel issue, bugzilla has been submited: https://bugzilla.kernel.org/show_bug.cgi?id=207075, not fixed yet. * Cryptodev: - Function test: test scenarios including Cryptodev API testing/CompressDev ISA-L/QAT/ZLIB PMD Testing/FIPS, etc. Listed but not all. - All passed. - Performance test: test scenarios including Thoughput Performance /Cryptodev Latency, etc. Listed but not all. - No big data drop. Best regards, Yu Jiang >-Original Message- >From: dev On Behalf Of Christian Ehrhardt >Sent: Thursday, June 10, 2021 9:57 PM >To: Kevin Traynor >Cc: Ali Alnubani ; dpdk stable ; dev >; Abhishek Marathe ; >Akhil Goyal ; Walker, Benjamin >; David Christensen ; >Govindharajan, Hariprasad ; Hemant >Agrawal ; Stokes, Ian ; >Jerin Jacob ; Mcnamara, John >; Ju-Hyoung Lee ; Luca >Boccassi ; Pei Zhang ; Yu, PingX >; Xu, Qian Q ; Raslan Darawsheh >; NBU-Contact-Thomas Monjalon >; Peng, Yuan ; Chen, >Zhaoyan >Subject: Re: [dpdk-dev] 19.11.9 patches review and test - V2 > >On Thu, Jun 10, 2021 at 1:03 PM Kevin Traynor wrote: >> >> On 10/06/2021 11:29, Kevin Traynor wrote: >> > On 10/06/2021 11:05, Christian Ehrhardt wrote: >> >> On Thu, Jun 10, 2021 at 11:05 AM Ali Alnubani >wrote: >> >>> >> >>> Hi Christian, >> >>> >> -Original Message- >> From: Christian Ehrhardt >> Sent: Thursday, June 10, 2021 11:49 AM >> To: dpdk stable >> Cc: dev ; Abhishek Marathe >> ; Akhil Goyal >> ; Ali Alnubani ; Walker, >> Benjamin ; David Christensen >> ; Govindharajan, Hariprasad >> ; Hemant Agrawal >> ; Ian Stokes ; >> Jerin Jacob ; J
Re: [dpdk-dev] [PATCH] eal/arm: enable FreeBSD build
On Fri, Jun 4, 2021 at 7:49 AM Ruifeng Wang wrote: > > Build on FreeBSD on aarch64 failed with error: > lib/eal/arm/rte_cpuflags.c:86:9: error: unknown type name 'Elf64_auxv_t' > > The data type is used by OS Linux auxiliary vector read, and not used by > arch specific cpu flag API implementations. Hence remove it from Arm file. > > Reported-by: James Grant > Signed-off-by: Ruifeng Wang > Reviewed-by: Honnappa Nagarahalli This never worked, so this patch counts as enabling a new supported OS/arch. If we want FreeBSD support on ARM, we will need non regression tests in some CI. A release notes update is also needed. -- David Marchand
Re: [dpdk-dev] [dpdk-stable] [PATCH v2] bitmap: fix buffer overrun in bitmap init function
On Tue, Jun 8, 2021 at 12:27 PM Dumitrescu, Cristian
wrote:
> > Bitmap initialization function is allowed to memset()
> > caller-provided buffer with number of bytes exceeded
> > this buffer size. This happens due to wrong comparison
> > sign between buffer size and number of bytes required
> > to initialize bitmap.
> >
> > Fixes: 602c9ca33a4 ("sched: bitmap is now dynamically allocated")
> > Cc: sta...@dpdk.org
> >
> > Reported-by: Andy Moreton
> > Signed-off-by: Ivan Ilchenko
> > Reviewed-by: Andy Moreton
> > Signed-off-by: Andrew Rybchenko
> Acked-by: Cristian Dumitrescu
Applied, thanks.
--
David Marchand
Re: [dpdk-dev] [PATCH] app/testpmd: send failure logs to stderr
On 6/11/21 5:06 AM, Li, Xiaoyun wrote: > Hi > -Original Message- > From: Andrew Rybchenko > Sent: Friday, May 28, 2021 00:25 > To: Li, Xiaoyun > Cc: dev@dpdk.org > Subject: [PATCH] app/testpmd: send failure logs to stderr > > Running with stdout suppressed or redirected for further processing is very > confusing in the case of errors. > > Signed-off-by: Andrew Rybchenko > --- > > This patch looks good to me. > But what do you think about make it as a fix and backport to stable branches? > Anyway works for me. I have no strong opinion on the topic. @Ferruh, what do you think? > Acked-by: Xiaoyun Li
Re: [dpdk-dev] Define statement with UB prevents compilation using UBSAN
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger > Sent: Thursday, 10 June 2021 23.36 > > On Thu, 10 Jun 2021 16:51:37 -0400 > Owen Hilyard wrote: > > > Working backward to the define > > statement, AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY is defined > as > > > > #define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY (0x1 << 31) > > Why not (1u << 31)? Yes, this is better. You want the type of the defined constant to be uint32_t. It can also be defined in hexadecimal form as (0x1u << 31), or (0b1u << 31) in binary form. On the CPUs/compilers supported by DPDK, the exact type of an unsigned integer is uint32_t. If the CPU/compiler used 64 bits for integers, you would need additional type casting to get it down from 64 to 32 bits. If we were to be really pedantic, the other defined constants that fit in a signed integer, e.g. (1 << 30) should also be defined as (1u << 30) if they are supposed to be unsigned integers. However, not many people worry about signedness when writing code, especially if an unsigned value fits into a signed variable or constant. Thank you for your effort on this, Owen. Keep up the good work! :-)
Re: [dpdk-dev] [PATCH] malloc: fix size annotation for NUMA-aware realloc
On Thu, Jun 10, 2021 at 2:19 PM Maxime Coquelin wrote:
> > __rte_alloc_size is mapped to compiler alloc_size attribute.
> >
> > Quoting gcc documentation:
> > """
> > alloc_size
> > The alloc_size attribute is used to tell the compiler that the
> > function return value points to memory, where the size is given by
> > one or two of the functions parameters. GCC uses this information
> > to improve the correctness of __builtin_object_size.
> >
> > The function parameter(s) denoting the allocated size are specified
> > by one or two integer arguments supplied to the attribute.
> > The allocated size is either the value of the single function
> > argument specified or the product of the two function arguments
> > specified. Argument numbering starts at one.
> > """
> >
> > In rte_realloc_socket case, only 'size' matters.
> >
> > Note: this has been spotted by Maxime trying to use rte_realloc_socket
> > and compiling with gcc 11.
> >
> > Fixes: 17b347dab769 ("malloc: add alloc_size attribute to functions")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: David Marchand
> Tested-by: Maxime Coquelin
Applied.
--
David Marchand
Re: [dpdk-dev] [dpdk-stable] [PATCH v5] eal: arm: fix out of tree build
Hello Bruce,
On Wed, Jun 9, 2021 at 12:18 PM Michael Pfeiffer
wrote:
>
> Including various headers may fail for ARM builds with 'Platform must
> be built with RTE_FORCE_INTRINSICS' if rte_config.h is not included
> before. Move the error message after the includes to ensure rte_config.h
> is always included.
>
> Fixes: de966ccdcd7f ("eal/arm: add byte order operations for ARM")
> Fixes: 17d5fa0fa90d ("eal/arm: add atomic operations for ARMv7")
> Fixes: d708f01b7102 ("eal/arm: add atomic operations for ARMv8")
> Fixes: 2173fb61 ("mcslock: add MCS queued lock implementation")
> Fixes: 7860c3965483 ("eal/arm: add spinlock operations for ARM")
> Fixes: ca49b92079df ("ticketlock: enable generic ticketlock on all arch")
> Cc: sta...@dpdk.org
> Cc: ko...@rehivetech.com
> Cc: phil.y...@arm.com
> Cc: joyce.k...@arm.com
>
> Signed-off-by: Michael Pfeiffer
The header check currently compiles all headers with an implicit
"-include rte_config.h".
I suppose this is because it comes from the project level meson configuration.
Would there be a way to detect the issue fixed by this patch?
--
David Marchand
Re: [dpdk-dev] [dpdk-stable] [PATCH v5] eal: arm: fix out of tree build
On Fri, Jun 11, 2021 at 11:54:25AM +0200, David Marchand wrote:
> Hello Bruce,
>
> On Wed, Jun 9, 2021 at 12:18 PM Michael Pfeiffer
> wrote:
> >
> > Including various headers may fail for ARM builds with 'Platform must
> > be built with RTE_FORCE_INTRINSICS' if rte_config.h is not included
> > before. Move the error message after the includes to ensure rte_config.h
> > is always included.
> >
> > Fixes: de966ccdcd7f ("eal/arm: add byte order operations for ARM")
> > Fixes: 17d5fa0fa90d ("eal/arm: add atomic operations for ARMv7")
> > Fixes: d708f01b7102 ("eal/arm: add atomic operations for ARMv8")
> > Fixes: 2173fb61 ("mcslock: add MCS queued lock implementation")
> > Fixes: 7860c3965483 ("eal/arm: add spinlock operations for ARM")
> > Fixes: ca49b92079df ("ticketlock: enable generic ticketlock on all arch")
> > Cc: sta...@dpdk.org
> > Cc: ko...@rehivetech.com
> > Cc: phil.y...@arm.com
> > Cc: joyce.k...@arm.com
> >
> > Signed-off-by: Michael Pfeiffer
>
> The header check currently compiles all headers with an implicit
> "-include rte_config.h".
> I suppose this is because it comes from the project level meson configuration.
>
> Would there be a way to detect the issue fixed by this patch?
>
I'm not convinced that there is an issue here. For DPDK compiles
rte_config.h must always be included first, which is why it's included in
the cflags reported by pkg-config. If we do want to move away from having
rte_config as an omnipresent first include, we need to update many DPDK
headers to explicitly include it.
/Bruce
[dpdk-dev] [PATCH v2 1/2] examples/l2fwd: fix long option parsing
For l2fwd, --no-mac-updating and --mac-updating are treated as invalid
arguments.Rework long options parsing to let --no-mac-updating and
--mac-updating options work well.
Fixes: fa19eb20d212 ("examples/l2fwd: add forwarding port mapping option")
Cc: sta...@dpdk.org
Signed-off-by: SunChengLian
---
examples/l2fwd/main.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index ffb67bb901..a8fa091842 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -434,13 +434,14 @@ enum {
/* first long only option value must be >= 256, so that we won't
* conflict with short options */
- CMD_LINE_OPT_MIN_NUM = 256,
+ CMD_LINE_OPT_MAC_UPDATING_NUM = 256,
+ CMD_LINE_OPT_NO_MAC_UPDATING_NUM,
CMD_LINE_OPT_PORTMAP_NUM,
};
static const struct option lgopts[] = {
- { CMD_LINE_OPT_MAC_UPDATING, no_argument, &mac_updating, 1},
- { CMD_LINE_OPT_NO_MAC_UPDATING, no_argument, &mac_updating, 0},
+ { CMD_LINE_OPT_MAC_UPDATING, no_argument, 0,
CMD_LINE_OPT_MAC_UPDATING_NUM},
+ { CMD_LINE_OPT_NO_MAC_UPDATING, no_argument, 0,
CMD_LINE_OPT_NO_MAC_UPDATING_NUM},
{ CMD_LINE_OPT_PORTMAP_CONFIG, 1, 0, CMD_LINE_OPT_PORTMAP_NUM},
{NULL, 0, 0, 0}
};
@@ -502,6 +503,14 @@ l2fwd_parse_args(int argc, char **argv)
}
break;
+ case CMD_LINE_OPT_MAC_UPDATING_NUM:
+ mac_updating = 1;
+ break;
+
+ case CMD_LINE_OPT_NO_MAC_UPDATING_NUM:
+ mac_updating = 0;
+ break;
+
default:
l2fwd_usage(prgname);
return -1;
--
2.25.1
[dpdk-dev] [PATCH 1/2] crypto/octeontx2: increase metabuf pool
When used with crypto adapter, metabuf pool would be shared across
cores. Account for the same in pool size.
Signed-off-by: Anoob Joseph
---
drivers/crypto/octeontx2/otx2_cryptodev_ops.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
index 0cf8e80..12a2747 100644
--- a/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
+++ b/drivers/crypto/octeontx2/otx2_cryptodev_ops.c
@@ -45,12 +45,12 @@ qp_memzone_name_get(char *name, int size, int dev_id, int
qp_id)
static int
otx2_cpt_metabuf_mempool_create(const struct rte_cryptodev *dev,
struct otx2_cpt_qp *qp, uint8_t qp_id,
- int nb_elements)
+ unsigned int nb_elements)
{
char mempool_name[RTE_MEMPOOL_NAMESIZE];
struct cpt_qp_meta_info *meta_info;
+ int ret, max_mlen, mb_pool_sz;
struct rte_mempool *pool;
- int ret, max_mlen;
int asym_mlen = 0;
int lb_mlen = 0;
int sg_mlen = 0;
@@ -87,7 +87,9 @@ otx2_cpt_metabuf_mempool_create(const struct rte_cryptodev
*dev,
snprintf(mempool_name, RTE_MEMPOOL_NAMESIZE, "otx2_cpt_mb_%u:%u",
dev->data->dev_id, qp_id);
- pool = rte_mempool_create_empty(mempool_name, nb_elements, max_mlen,
+ mb_pool_sz = RTE_MAX(nb_elements, (METABUF_POOL_CACHE_SIZE *
rte_lcore_count()));
+
+ pool = rte_mempool_create_empty(mempool_name, mb_pool_sz, max_mlen,
METABUF_POOL_CACHE_SIZE, 0,
rte_socket_id(), 0);
--
2.7.4
[dpdk-dev] [PATCH 2/2] crypto/octeontx: increase metabuf pool
When used with crypto adapter, metabuf pool would be shared across
cores. Account for the same in pool size.
Signed-off-by: Anoob Joseph
---
drivers/crypto/octeontx/otx_cryptodev_hw_access.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/octeontx/otx_cryptodev_hw_access.c
b/drivers/crypto/octeontx/otx_cryptodev_hw_access.c
index 5229e7c..ab335c6 100644
--- a/drivers/crypto/octeontx/otx_cryptodev_hw_access.c
+++ b/drivers/crypto/octeontx/otx_cryptodev_hw_access.c
@@ -409,7 +409,7 @@ otx_cpt_deinit_device(void *dev)
static int
otx_cpt_metabuf_mempool_create(const struct rte_cryptodev *dev,
struct cpt_instance *instance, uint8_t qp_id,
- int nb_elements)
+ unsigned int nb_elements)
{
char mempool_name[RTE_MEMPOOL_NAMESIZE];
struct cpt_qp_meta_info *meta_info;
@@ -417,6 +417,7 @@ otx_cpt_metabuf_mempool_create(const struct rte_cryptodev
*dev,
int max_mlen = 0;
int sg_mlen = 0;
int lb_mlen = 0;
+ int mb_pool_sz;
int ret;
/*
@@ -453,7 +454,9 @@ otx_cpt_metabuf_mempool_create(const struct rte_cryptodev
*dev,
snprintf(mempool_name, RTE_MEMPOOL_NAMESIZE, "otx_cpt_mb_%u:%u",
dev->data->dev_id, qp_id);
- pool = rte_mempool_create_empty(mempool_name, nb_elements, max_mlen,
+ mb_pool_sz = RTE_MAX(nb_elements, (METABUF_POOL_CACHE_SIZE *
rte_lcore_count()));
+
+ pool = rte_mempool_create_empty(mempool_name, mb_pool_sz, max_mlen,
METABUF_POOL_CACHE_SIZE, 0,
rte_socket_id(), 0);
--
2.7.4
Re: [dpdk-dev] [dpdk-stable] [PATCH v5] eal: arm: fix out of tree build
Hi there,
On Fri, 2021-06-11 at 10:59 +0100, Bruce Richardson wrote:
> On Fri, Jun 11, 2021 at 11:54:25AM +0200, David Marchand wrote:
> > Hello Bruce,
> >
> > On Wed, Jun 9, 2021 at 12:18 PM Michael Pfeiffer
> > wrote:
> > >
> > > Including various headers may fail for ARM builds with 'Platform must
> > > be built with RTE_FORCE_INTRINSICS' if rte_config.h is not included
> > > before. Move the error message after the includes to ensure rte_config.h
> > > is always included.
> > >
> > > Fixes: de966ccdcd7f ("eal/arm: add byte order operations for ARM")
> > > Fixes: 17d5fa0fa90d ("eal/arm: add atomic operations for ARMv7")
> > > Fixes: d708f01b7102 ("eal/arm: add atomic operations for ARMv8")
> > > Fixes: 2173fb61 ("mcslock: add MCS queued lock implementation")
> > > Fixes: 7860c3965483 ("eal/arm: add spinlock operations for ARM")
> > > Fixes: ca49b92079df ("ticketlock: enable generic ticketlock on all arch")
> > > Cc: sta...@dpdk.org
> > > Cc: ko...@rehivetech.com
> > > Cc: phil.y...@arm.com
> > > Cc: joyce.k...@arm.com
> > >
> > > Signed-off-by: Michael Pfeiffer
> >
> > The header check currently compiles all headers with an implicit
> > "-include rte_config.h".
> > I suppose this is because it comes from the project level meson
> > configuration.
> >
> > Would there be a way to detect the issue fixed by this patch?
> >
> I'm not convinced that there is an issue here. For DPDK compiles
> rte_config.h must always be included first, which is why it's included in
> the cflags reported by pkg-config. If we do want to move away from having
> rte_config as an omnipresent first include, we need to update many DPDK
> headers to explicitly include it.
the issue came up in our (rather large) DPDK app. Our build process uses a
hand-crafted build system (based on ninja) for native and cross builds, i.e.
pkg-config is not involved. It basically throws "-isystem /include/dpdk" into the compiler and omits linking some of the DPDK libs
not used by us.
This worked fine for us, and has no issues for x86 targets. I guess because
most headers do include rte_config (or rte_common) at least transitively before
doing anything else. Anyway, if you regard "-include rte_config.h" as the way
to go, this is fine for me. Its a one-liner for us and we can probably drop the
patch then.
Regards
Michael
[dpdk-dev] [PATCH v2 2/2] examples/l2fwd: remove mac-updating option
The "mac-updating" option can be removed since the associated mac_updating
variable is set to 1 by default.
Signed-off-by: SunChengLian
---
examples/l2fwd/main.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index a8fa091842..65b290291d 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -434,13 +434,11 @@ enum {
/* first long only option value must be >= 256, so that we won't
* conflict with short options */
- CMD_LINE_OPT_MAC_UPDATING_NUM = 256,
- CMD_LINE_OPT_NO_MAC_UPDATING_NUM,
+ CMD_LINE_OPT_NO_MAC_UPDATING_NUM=256,
CMD_LINE_OPT_PORTMAP_NUM,
};
static const struct option lgopts[] = {
- { CMD_LINE_OPT_MAC_UPDATING, no_argument, 0,
CMD_LINE_OPT_MAC_UPDATING_NUM},
{ CMD_LINE_OPT_NO_MAC_UPDATING, no_argument, 0,
CMD_LINE_OPT_NO_MAC_UPDATING_NUM},
{ CMD_LINE_OPT_PORTMAP_CONFIG, 1, 0, CMD_LINE_OPT_PORTMAP_NUM},
{NULL, 0, 0, 0}
@@ -503,10 +501,6 @@ l2fwd_parse_args(int argc, char **argv)
}
break;
- case CMD_LINE_OPT_MAC_UPDATING_NUM:
- mac_updating = 1;
- break;
-
case CMD_LINE_OPT_NO_MAC_UPDATING_NUM:
mac_updating = 0;
break;
--
2.25.1
Re: [dpdk-dev] [PATCH] app/testpmd: send failure logs to stderr
On 6/11/2021 10:19 AM, Andrew Rybchenko wrote: > On 6/11/21 5:06 AM, Li, Xiaoyun wrote: >> Hi >> -Original Message- >> From: Andrew Rybchenko >> Sent: Friday, May 28, 2021 00:25 >> To: Li, Xiaoyun >> Cc: dev@dpdk.org >> Subject: [PATCH] app/testpmd: send failure logs to stderr >> >> Running with stdout suppressed or redirected for further processing is very >> confusing in the case of errors. >> >> Signed-off-by: Andrew Rybchenko >> --- >> >> This patch looks good to me. >> But what do you think about make it as a fix and backport to stable branches? >> Anyway works for me. > > I have no strong opinion on the topic. > > @Ferruh, what do you think? > Same here, no strong opinion. Sending errors to 'stderr' looks correct thing to do, but changing behavior in the LTS may cause some unexpected side affect, if it is scripted and testpmd output is parsed etc... For this possibility I would wait for the next LTS. And because of same reason perhaps a release note can be added. Also there is 'TESTPMD_LOG' macro for logs in testpmd, (as well as 'RTE_LOG' macro), I don't know if we should switch all logs, including 'printf', to 'TESTPMD_LOG' macro? Later stdout/sderr can be managed in rte_log level, instead of any specific logic for the testpmd. Even there was a defect for this in the rte_log level, that logs should go to stderr: https://bugs.dpdk.org/show_bug.cgi?id=8 >> Acked-by: Xiaoyun Li >
Re: [dpdk-dev] [dpdk-stable] [PATCH v5] eal: arm: fix out of tree build
> -Original Message-
> From: Michael Pfeiffer
> Sent: Friday, June 11, 2021 6:28 PM
> To: Bruce Richardson ; David Marchand
>
> Cc: Jan Viktorin ; Ruifeng Wang
> ; jer...@marvell.com; dev ;
> dpdk stable ; ko...@rehivetech.com; Phil Yang
> ; Joyce Kong
> Subject: Re: [dpdk-stable] [PATCH v5] eal: arm: fix out of tree build
>
> Hi there,
>
> On Fri, 2021-06-11 at 10:59 +0100, Bruce Richardson wrote:
> > On Fri, Jun 11, 2021 at 11:54:25AM +0200, David Marchand wrote:
> > > Hello Bruce,
> > >
> > > On Wed, Jun 9, 2021 at 12:18 PM Michael Pfeiffer
> > > wrote:
> > > >
> > > > Including various headers may fail for ARM builds with 'Platform
> > > > must be built with RTE_FORCE_INTRINSICS' if rte_config.h is not
> > > > included before. Move the error message after the includes to
> > > > ensure rte_config.h is always included.
> > > >
> > > > Fixes: de966ccdcd7f ("eal/arm: add byte order operations for ARM")
> > > > Fixes: 17d5fa0fa90d ("eal/arm: add atomic operations for ARMv7")
> > > > Fixes: d708f01b7102 ("eal/arm: add atomic operations for ARMv8")
> > > > Fixes: 2173fb61 ("mcslock: add MCS queued lock
> > > > implementation")
> > > > Fixes: 7860c3965483 ("eal/arm: add spinlock operations for ARM")
> > > > Fixes: ca49b92079df ("ticketlock: enable generic ticketlock on all
> > > > arch")
> > > > Cc: sta...@dpdk.org
> > > > Cc: ko...@rehivetech.com
> > > > Cc: phil.y...@arm.com
> > > > Cc: joyce.k...@arm.com
> > > >
> > > > Signed-off-by: Michael Pfeiffer
> > >
> > > The header check currently compiles all headers with an implicit
> > > "-include rte_config.h".
> > > I suppose this is because it comes from the project level meson
> > > configuration.
> > >
> > > Would there be a way to detect the issue fixed by this patch?
> > >
> > I'm not convinced that there is an issue here. For DPDK compiles
> > rte_config.h must always be included first, which is why it's included
> > in the cflags reported by pkg-config. If we do want to move away from
> > having rte_config as an omnipresent first include, we need to update
> > many DPDK headers to explicitly include it.
>
> the issue came up in our (rather large) DPDK app. Our build process uses a
> hand-crafted build system (based on ninja) for native and cross builds, i.e.
> pkg-config is not involved. It basically throws "-isystem prefix>/include/dpdk" into the compiler and omits linking some of the
> prefix>DPDK libs
> not used by us.
>
> This worked fine for us, and has no issues for x86 targets. I guess because
> most headers do include rte_config (or rte_common) at least transitively
As what I can find, no issues for x86 because it has been fixed in commit:
0d440d081ca1 ("lib: fix missing includes in exported headers")
> before doing anything else. Anyway, if you regard "-include rte_config.h" as
> the way to go, this is fine for me. Its a one-liner for us and we can probably
> drop the patch then.
>
> Regards
> Michael
Re: [dpdk-dev] [PATCH v1 0/8] use GCC's C11 atomic builtins for test
> > > > Since C11 memory model is adopted in DPDK now[1], use GCC's atomic > > builtins in test cases. > > > > [1]https://www.dpdk.org/blog/2021/03/26/dpdk-adopts-the-c11-memory- > mod > > el/ > > > > Joyce Kong (8): > > test/ticketlock: use GCC atomic builtins for lcores sync > > test/spinlock: use GCC atomic builtins for lcores sync > > test/rwlock: use GCC atomic builtins for lcores sync > > test/mcslock: use GCC atomic builtins for lcores sync > > test/mempool: remove unused variable for lcores sync > > test/mempool_perf: use GCC atomic builtins for lcores sync > > test/service_cores: use GCC atomic builtins for lock sync > > test/rcu_perf: use GCC atomic builtins for data sync > > Just a nit, use rte_wait_until_equal() instead of those sync loops. > Rest lgtm, thanks. > Thanks for your comment, I'll do the related changes. > > -- > David Marchand
Re: [dpdk-dev] [PATCH] eal/arm: enable FreeBSD build
> -Original Message- > From: David Marchand > Sent: Friday, June 11, 2021 4:59 PM > To: Ruifeng Wang > Cc: Jan Viktorin ; jer...@marvell.com; Bruce > Richardson ; dev ; nd > ; j.gr...@qub.ac.uk; tho...@monjalon.net; Honnappa > Nagarahalli > Subject: Re: [PATCH] eal/arm: enable FreeBSD build > > On Fri, Jun 4, 2021 at 7:49 AM Ruifeng Wang > wrote: > > > > Build on FreeBSD on aarch64 failed with error: > > lib/eal/arm/rte_cpuflags.c:86:9: error: unknown type name 'Elf64_auxv_t' > > > > The data type is used by OS Linux auxiliary vector read, and not used > > by arch specific cpu flag API implementations. Hence remove it from Arm > file. > > > > Reported-by: James Grant > > Signed-off-by: Ruifeng Wang > > Reviewed-by: Honnappa Nagarahalli > > This never worked, so this patch counts as enabling a new supported OS/arch. > > If we want FreeBSD support on ARM, we will need non regression tests in > some CI. Currently no plan to claim FreeBSD support on Arm. I'll update commit message to treat it as removal of useless code. > A release notes update is also needed. > > > -- > David Marchand
[dpdk-dev] [Bug 733] [dpdk-19.11.9-rc2] make and meson build failed on Fedora33 with CLang11.0.0
https://bugs.dpdk.org/show_bug.cgi?id=733 Bug ID: 733 Summary: [dpdk-19.11.9-rc2] make and meson build failed on Fedora33 with CLang11.0.0 Product: DPDK Version: 19.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: yux.ji...@intel.com Target Milestone: --- Environment: DPDK version: commit bb144e7a1c5e7709c74b3096179f6296e77923da (HEAD, tag: v19.11.9-rc2, origin/19.11) Author: Christian Ehrhardt Date: Fri Jun 4 07:46:13 2021 +0200 version: 19.11.9-rc2 Signed-off-by: Christian Ehrhardt OS version: Fedora 33 (Server Edition)/5.8.16-300.fc33.x86_64 clang version 11.0.0 (Fedora 11.0.0-3.fc33) Notes: 1, Make and meson build LTS19.11.6 also failed, should LTS19.11.9 support Clang10 or not? 2, Fedora32-kernel5.6.0-clang10.0.0 both meson and make build passed Test Setup: meson build cmd: rm -rf x86_64-native-linuxapp-clang CC=clang meson --werror -Denable_kmods=True -Dlibdir=lib --default-library=static x86_64-native-linuxapp-clang ninja -C x86_64-native-linuxapp-clang -j 60 make build cmd: export RTE_TARGET=x86_64-native-linuxapp-clang export RTE_SDK=`pwd` rm -rf x86_64-native-linuxapp-clang rm -rf ./app/test/test_resource_c.res.o rm -rf ./app/test/test_resource_tar.res.o rm -rf ./app/test/test_pci_sysfs.res.o make -j 30 install T=x86_64-native-linuxapp-clang MAKE_PAUSE=n Show the output from the previous commands: meson build failed log: [root@fedora33x86-64 dpdk]# ninja -C x86_64-native-linuxapp-clang ninja: Entering directory `x86_64-native-linuxapp-clang' [1873/2058] Linking target app/dpdk-proc-info FAILED: app/dpdk-proc-info clang -o app/dpdk-proc-info app/dpdk-proc-info.p/proc-info_main.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wl,--whole-archive -Wl,--start-group lib/librte_bpf.a lib/librte_flow_classify.a lib/librte_pipeline.a lib/librte_table.a lib/librte_port.a lib/librte_fib.a lib/librte_ipsec.a lib/librte_vhost.a lib/librte_stack.a lib/librte_security.a lib/librte_sched.a lib/librte_reorder.a lib/librte_rib.a lib/librte_rcu.a lib/librte_rawdev.a lib/librte_pdump.a lib/librte_power.a lib/librte_member.a lib/librte_lpm.a lib/librte_latencystats.a lib/librte_kni.a lib/librte_jobstats.a lib/librte_ip_frag.a lib/librte_gso.a lib/librte_gro.a lib/librte_eventdev.a lib/librte_efd.a lib/librte_distributor.a lib/librte_cryptodev.a lib/librte_compressdev.a lib/librte_cfgfile.a lib/librte_bitratestats.a lib/librte_bbdev.a lib/librte_acl.a lib/librte_timer.a lib/librte_hash.a lib/librte_metrics.a lib/librte_cmdline.a lib/librte_pci.a lib/librte_ethdev.a lib/librte_meter.a lib/librte_net.a lib/librte_mbuf.a lib/librte_mempool.a lib/librte_ring.a lib/librte_eal.a lib/librte_kvargs.a drivers/librte_common_cpt.a drivers/librte_common_dpaax.a drivers/librte_common_octeontx.a drivers/librte_common_octeontx2.a drivers/librte_bus_dpaa.a drivers/librte_bus_fslmc.a drivers/librte_bus_ifpga.a drivers/librte_bus_pci.a drivers/librte_bus_vdev.a drivers/librte_bus_vmbus.a drivers/librte_mempool_bucket.a drivers/librte_mempool_dpaa.a drivers/librte_mempool_dpaa2.a drivers/librte_mempool_octeontx.a drivers/librte_mempool_octeontx2.a drivers/librte_mempool_ring.a drivers/librte_mempool_stack.a drivers/librte_pmd_af_packet.a drivers/librte_pmd_ark.a drivers/librte_pmd_atlantic.a drivers/librte_pmd_avp.a drivers/librte_pmd_axgbe.a drivers/librte_pmd_bond.a drivers/librte_pmd_bnx2x.a drivers/librte_pmd_bnxt.a drivers/librte_pmd_cxgbe.a drivers/librte_pmd_dpaa.a drivers/librte_pmd_dpaa2.a drivers/librte_pmd_e1000.a drivers/librte_pmd_ena.a drivers/librte_pmd_enetc.a drivers/librte_pmd_enic.a drivers/librte_pmd_failsafe.a drivers/librte_pmd_fm10k.a drivers/librte_pmd_i40e.a drivers/librte_pmd_hinic.a drivers/librte_pmd_hns3.a drivers/librte_pmd_iavf.a drivers/librte_pmd_ice.a drivers/librte_pmd_ifc.a drivers/librte_pmd_ipn3ke.a drivers/librte_pmd_ixgbe.a drivers/librte_pmd_kni.a drivers/librte_pmd_liquidio.a drivers/librte_pmd_memif.a drivers/librte_pmd_netvsc.a drivers/librte_pmd_nfp.a drivers/librte_pmd_null.a drivers/librte_pmd_octeontx.a drivers/librte_pmd_octeontx2.a drivers/librte_pmd_pcap.a drivers/librte_pmd_pfe.a drivers/librte_pmd_qede.a drivers/librte_pmd_ring.a drivers/librte_pmd_sfc.a drivers/librte_pmd_softnic.a drivers/librte_pmd_tap.a drivers/librte_pmd_thunderx.a drivers/librte_pmd_vdev_netvsc.a drivers/librte_pmd_vhost.a drivers/librte_pmd_virtio.a drivers/librte_pmd_vmxnet3.a drivers/librte_rawdev_dpaa2_cmdif.a drivers/librte_rawdev_dpaa2_qdma.a drivers/librte_rawdev_ifpga.a drivers/librte_rawdev_ioat.a drivers/librte_rawdev_ntb.a drivers/librte_rawdev_octeontx2_dma.a drivers/librte_rawdev_skeleton.a drivers/librte_pmd_aesni_gcm.a drivers/librte_pmd_aesni_mb.a drivers/librte_pmd_caam_jr.a drivers/librte_pmd_ccp.a drivers/librte_pmd_dpaa_sec.a drivers/li
Re: [dpdk-dev] [PATCH] app/testpmd: send failure logs to stderr
On Fri, Jun 11, 2021 at 11:35:59AM +0100, Ferruh Yigit wrote: > On 6/11/2021 10:19 AM, Andrew Rybchenko wrote: > > On 6/11/21 5:06 AM, Li, Xiaoyun wrote: > >> Hi > >> -Original Message- > >> From: Andrew Rybchenko > >> Sent: Friday, May 28, 2021 00:25 > >> To: Li, Xiaoyun > >> Cc: dev@dpdk.org > >> Subject: [PATCH] app/testpmd: send failure logs to stderr > >> > >> Running with stdout suppressed or redirected for further processing is > >> very confusing in the case of errors. > >> > >> Signed-off-by: Andrew Rybchenko > >> --- > >> > >> This patch looks good to me. > >> But what do you think about make it as a fix and backport to stable > >> branches? > >> Anyway works for me. > > > > I have no strong opinion on the topic. > > > > @Ferruh, what do you think? > > > > Same here, no strong opinion. > Sending errors to 'stderr' looks correct thing to do, but changing behavior in > the LTS may cause some unexpected side affect, if it is scripted and testpmd > output is parsed etc... For this possibility I would wait for the next LTS. > There are really 3 options, though: * apply and backport * apply now * apply only to next LTS I would tend to support the middle option, because sending errors to stderr is the right thing to do as you say, and I don't think we need to wait for next LTS to make the change. However, since we don't want to change behaviour in the older LTS's, I'd suggest not backporting. /Bruce
Re: [dpdk-dev] Define statement with UB prevents compilation using UBSAN
Stephen Hemminger writes: > On Thu, 10 Jun 2021 16:51:37 -0400 > Owen Hilyard wrote: > >> Working backward to the define >> statement, AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY is defined as >> >> #define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY (0x1 << 31) > > Why not (1u << 31)? +1 CC'd the QLogic maintainers as well.
[dpdk-dev] DPDK Release Status Meeting 11/06/2021
Release status meeting minutes {Date}
=
:Date: 10 June 2021
:toc:
.Agenda:
* Release Dates
* Subtrees
* Roadmaps
* LTS
* Defects
* Opens
.Participants:
* Arm
* Canonical
* Intel
* Marvell
* Nvidia
* Red Hat
Release Dates
-
* `v21.08` dates
- Proposal/V1:Wednesday, 2 June (completed)
- -rc1: Monday, 5 July
- Release:Tuesday, 3 August
* Note: We need to hold to the early August release date since
several of the maintainers will be on holidays after that.
Subtrees
* main
- Started merging series from last release
** PCI bus update for resets with VF devices
- Thomas will start pulling branches today
- Marvell: Raw device driver for basebase/PHY
* next-net
- Andrew has started doing reviews
* next-crypto
- 4 new PMDs in this release
** CNXK
** MLX
** Intel QAT
** NXP baseband
- Reviews started
* next-eventdev
- CNXK eventdev driver update
* next-virtio
- 4 series from Intel around the async data - under review
- 1 series from Maxime - kernel vdpa support - get mac address
from hardware. Postponed from last series.
- Working on vhost user issue with numa reallocation
* next-net-brcm
- Should be a biggish release ~60 patches
* next-net-intel
- No update this week
* next-net-mlx
- Should be a small release for Mellanox
* next-net-mrvl
- CNXK ethernet driver (from last release).
- V3 should be merged last week.
LTS
---
* `v19.11` (next version is `v19.11.9`)
- 19.11.9 is in progress
- Needs an RC3 - triggered by kernel update in SuSE
- Tagged for release
- Waiting for tests
* `v20.11` (next version is `v20.11.2`)
- Tagged for release
* Distros
- v20.11 in Debian 11
- v20.11 in Ubuntu 21.04
Defects
---
* Bugzilla links, 'Bugs', added for hosted projects
- https://www.dpdk.org/hosted-projects/
Opens
-
* None
.DPDK Release Status Meetings
*
The DPDK Release Status Meeting is intended for DPDK Committers to discuss the
status of the master tree and sub-trees, and for project managers to track
progress or milestone dates.
The meeting occurs on every Thursdays at 8:30 UTC. on https://meet.jit.si/DPDK
If you wish to attend just send an email to "John McNamara
" for the invite.
*
[dpdk-dev] [PATCH v2] eal/arm: remove irrelevant code
Data types Elf32_auxv_t and Elf64_auxv_t are used by OS Linux
auxiliary vector read, and not used by arch specific cpu flag
API implementations. Hence remove them from Arm file.
Reported-by: James Grant
Signed-off-by: Ruifeng Wang
Reviewed-by: Honnappa Nagarahalli
---
v2:
Update commit message to remove implication of FreeBSD support.
lib/eal/arm/rte_cpuflags.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/eal/arm/rte_cpuflags.c b/lib/eal/arm/rte_cpuflags.c
index 845770f1e5..d84c9fc09f 100644
--- a/lib/eal/arm/rte_cpuflags.c
+++ b/lib/eal/arm/rte_cpuflags.c
@@ -48,7 +48,6 @@ struct feature_entry {
#ifdef RTE_ARCH_ARMv7
#define PLATFORM_STR "v7l"
-typedef Elf32_auxv_t _Elfx_auxv_t;
const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(SWP, REG_HWCAP,0)
@@ -83,7 +82,6 @@ const struct feature_entry rte_cpu_feature_table[] = {
#elif defined RTE_ARCH_ARM64
#define PLATFORM_STR "aarch64"
-typedef Elf64_auxv_t _Elfx_auxv_t;
const struct feature_entry rte_cpu_feature_table[] = {
FEAT_DEF(FP,REG_HWCAP,0)
--
2.25.1
[dpdk-dev] [PATCH] net/mlx5: fix switchdev mode recognition
The new kernels might add the switch_id attribute to the
Netlink replies and this caused the wrong recognition
of the E-Switch presence. The single uplink device was
erroneously recognized as master and it caused the
extending match for source vport index on all installed
flows, including the default ones, and adding extra hops
in the steering engine, that affected the maximal
throughput packet rate.
The extra check for the new device name format (it supposes
the new kernel) and the device is only one is added. If this
check succeeds the E-Switch presence is considered as wrongly
detected and overridden.
Fixes: 30a86157f6d5 ("net/mlx5: support PF representor")
Cc: sta...@dpdk.org
Signed-off-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/linux/mlx5_os.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
index 54e4a1fe60..92b3009786 100644
--- a/drivers/net/mlx5/linux/mlx5_os.c
+++ b/drivers/net/mlx5/linux/mlx5_os.c
@@ -2290,6 +2290,18 @@ mlx5_os_pci_probe_pf(struct rte_pci_device *pci_dev,
ret = -rte_errno;
goto exit;
}
+ /*
+* New kernels may add the switch_id attribute for the case
+* there is no E-Switch and we wrongly recognized the
+* only device as master. Override this if there is the
+* single device with single port and new device name
+* format present.
+*/
+ if (nd == 1 &&
+ list[0].info.name_type == MLX5_PHYS_PORT_NAME_TYPE_UPLINK) {
+ list[0].info.master = 0;
+ list[0].info.representor = 0;
+ }
}
MLX5_ASSERT(ns);
/*
--
2.18.1
[dpdk-dev] [PATCH] doc: fix SPDX tag
A stray character got added. Remove it.
Fixes: cb056611a8ed ("eal: rename lcore master and slave")
Cc: sta...@dpdk.org
Signed-off-by: Kevin Traynor
---
doc/guides/sample_app_ug/hello_world.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/guides/sample_app_ug/hello_world.rst
b/doc/guides/sample_app_ug/hello_world.rst
index 7cb9279e99..6ec93e0054 100644
--- a/doc/guides/sample_app_ug/hello_world.rst
+++ b/doc/guides/sample_app_ug/hello_world.rst
@@ -1,3 +1,3 @@
-o.. SPDX-License-Identifier: BSD-3-Clause
+.. SPDX-License-Identifier: BSD-3-Clause
Copyright(c) 2010-2014 Intel Corporation.
--
2.31.1
Re: [dpdk-dev] Define statement with UB prevents compilation using UBSAN
Seeing the discussion so far, do we want to change the single definition to be (0b1u << 31) so it works, or should we make this change in a wider scope (file, directory, project-wide). If we do make the change in a wider scope, should we only change instances where there is UB (1 << 31) or should we change all of the bitflags and similar constructs to uint32_t? If we change a lot, it may require special testing since I don't think every driver is tested on a regular basis, and making a change like this in a wide-reaching fashion has the potential to break a lot of things. On Fri, Jun 11, 2021 at 10:34 AM Aaron Conole wrote: > Stephen Hemminger writes: > > > On Thu, 10 Jun 2021 16:51:37 -0400 > > Owen Hilyard wrote: > > > >> Working backward to the define > >> statement, AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY is defined as > >> > >> #define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY (0x1 << 31) > > > > Why not (1u << 31)? > > +1 > > CC'd the QLogic maintainers as well. > >
Re: [dpdk-dev] [dts] [PATCH] malloc: fix size annotation for NUMA-aware realloc
That test suite has been disabled on the system. Someone of the Intel team should be looking at it soon, since stats_checks also has similar issues. On Fri, Jun 11, 2021 at 3:40 AM David Marchand wrote: > On Fri, Jun 11, 2021 at 9:26 AM David Marchand > wrote: > > > > On Thu, Jun 10, 2021 at 2:09 PM David Marchand > > wrote: > > > > > > __rte_alloc_size is mapped to compiler alloc_size attribute. > > > > I get the following splat from dts. > > There is the exact same output in last night next-net-intel test: > https://lab.dpdk.org/results/dashboard/tarballs/15461/ > > > -- > David Marchand > >
[dpdk-dev] [PATCH] eal: save error in string copy
From: Thomas Monjalon
Sets rte_errrno if the destination buffer is too small.
Signed-off-by: Thomas Monjalon
---
lib/eal/common/eal_common_string_fns.c | 4 +++-
lib/eal/common/eal_common_trace.c | 1 -
lib/eal/include/rte_string_fns.h | 5 ++---
lib/graph/node.c | 12 +++-
4 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/lib/eal/common/eal_common_string_fns.c
b/lib/eal/common/eal_common_string_fns.c
index 60c5dd66f9..ddd1891656 100644
--- a/lib/eal/common/eal_common_string_fns.c
+++ b/lib/eal/common/eal_common_string_fns.c
@@ -8,6 +8,7 @@
#include
#include
+#include
/* split string into tokens */
int
@@ -62,5 +63,6 @@ rte_strscpy(char *dst, const char *src, size_t dsize)
/* Not enough room in dst, set NUL and return error. */
if (res != 0)
dst[res - 1] = '\0';
- return -E2BIG;
+ rte_errno = E2BIG;
+ return -rte_errno;
}
diff --git a/lib/eal/common/eal_common_trace.c
b/lib/eal/common/eal_common_trace.c
index 24e27387b1..7bff1cd2ce 100644
--- a/lib/eal/common/eal_common_trace.c
+++ b/lib/eal/common/eal_common_trace.c
@@ -500,7 +500,6 @@ __rte_trace_point_register(rte_trace_point_t *handle, const
char *name,
/* Initialize the trace point */
if (rte_strscpy(tp->name, name, TRACE_POINT_NAME_SIZE) < 0) {
trace_err("name is too long");
- rte_errno = E2BIG;
goto free;
}
diff --git a/lib/eal/include/rte_string_fns.h b/lib/eal/include/rte_string_fns.h
index 8bac8243c9..bb43b2cba3 100644
--- a/lib/eal/include/rte_string_fns.h
+++ b/lib/eal/include/rte_string_fns.h
@@ -97,8 +97,6 @@ rte_strlcat(char *dst, const char *src, size_t size)
* Copy string src to buffer dst of size dsize.
* At most dsize-1 chars will be copied.
* Always NUL-terminates, unless (dsize == 0).
- * Returns number of bytes copied (terminating NUL-byte excluded) on success ;
- * negative errno on error.
*
* @param dst
* The destination string.
@@ -110,8 +108,9 @@ rte_strlcat(char *dst, const char *src, size_t size)
* Length in bytes of the destination buffer.
*
* @return
- * The number of bytes copied on success
+ * The number of bytes copied (terminating NUL-byte excluded) on success.
* -E2BIG if the destination buffer is too small.
+ * rte_errno is set.
*/
ssize_t
rte_strscpy(char *dst, const char *src, size_t dsize);
diff --git a/lib/graph/node.c b/lib/graph/node.c
index 873c9ab16d..86ec4316f9 100644
--- a/lib/graph/node.c
+++ b/lib/graph/node.c
@@ -86,10 +86,8 @@ __rte_node_register(const struct rte_node_register *reg)
}
/* Initialize the node */
- if (rte_strscpy(node->name, reg->name, RTE_NODE_NAMESIZE) < 0) {
- rte_errno = E2BIG;
+ if (rte_strscpy(node->name, reg->name, RTE_NODE_NAMESIZE) < 0)
goto free;
- }
node->flags = reg->flags;
node->process = reg->process;
node->init = reg->init;
@@ -98,10 +96,8 @@ __rte_node_register(const struct rte_node_register *reg)
node->parent_id = reg->parent_id;
for (i = 0; i < reg->nb_edges; i++) {
if (rte_strscpy(node->next_nodes[i], reg->next_nodes[i],
- RTE_NODE_NAMESIZE) < 0) {
- rte_errno = E2BIG;
+ RTE_NODE_NAMESIZE) < 0)
goto free;
- }
}
node->id = node_id++;
@@ -278,10 +274,8 @@ edge_update(struct node *node, struct node *prev,
rte_edge_t from,
/* Update the new nodes name */
for (i = from; i < max_edges; i++, count++) {
if (rte_strscpy(node->next_nodes[i], next_nodes[count],
- RTE_NODE_NAMESIZE) < 0) {
- rte_errno = E2BIG;
+ RTE_NODE_NAMESIZE) < 0)
goto restore;
- }
}
restore:
/* Update the linked list to point new node address in prev node */
--
2.25.1
Re: [dpdk-dev] [PATCH v9 07/10] eal: implement functions for mutex management
On Thu, Jun 10, 2021 at 01:37:17AM +0300, Dmitry Kozlyuk wrote:
> 2021-06-09 02:04 (UTC+0300), Dmitry Kozlyuk:
> > 2021-06-04 16:44 (UTC-0700), Narcisa Ana Maria Vasile:
> > [...]
> > > diff --git a/lib/eal/include/rte_thread_types.h
> > > b/lib/eal/include/rte_thread_types.h
> > > index d67b24a563..7bb0d2948c 100644
> > > --- a/lib/eal/include/rte_thread_types.h
> > > +++ b/lib/eal/include/rte_thread_types.h
> > > @@ -7,4 +7,8 @@
> > >
> > > #include
> > >
> > > +#define RTE_THREAD_MUTEX_INITIALIZER PTHREAD_MUTEX_INITIALIZER
> > > +
> > > +typedef pthread_mutex_t rte_thread_mutex_t;
> > > +
> > > #endif /* _RTE_THREAD_TYPES_H_ */
> > > diff --git a/lib/eal/windows/include/rte_windows_thread_types.h
> > > b/lib/eal/windows/include/rte_windows_thread_types.h
> > > index 60e6d94553..c6c8502bfb 100644
> > > --- a/lib/eal/windows/include/rte_windows_thread_types.h
> > > +++ b/lib/eal/windows/include/rte_windows_thread_types.h
> > > @@ -7,4 +7,13 @@
> > >
> > > #include
> > >
> > > +#define WINDOWS_MUTEX_INITIALIZER (void*)-1
> > > +#define RTE_THREAD_MUTEX_INITIALIZER
> > > {WINDOWS_MUTEX_INITIALIZER}
> > > +
> > > +struct thread_mutex_t {
> > > + void* mutex_id;
> > > +};
> > > +
> > > +typedef struct thread_mutex_t rte_thread_mutex_t;
> > > +
> > > #endif /* _RTE_THREAD_TYPES_H_ */
> >
> > In previous patches rte_thread content was made opaque and of equal size
> > for pthread (most implementations) and non-pthread variant.
> > AFAIU, we agree on the requirement of compatible ABI between variants,
> > that is, a compiled app can work with any threading variant of DPDK.
> > Above definition of `rte_thread_mutex_t` does not satisfy it.
> > Or do we only promise API compatibility?
> > This is the most important question now.
>
> From Windows community call 2021-06-10, for everyone's information.
>
> 1. Yes, binary compatibility is a requirement.
>
> 2. Static mutex initializer for Windows is tricky (an old topic).
> This patch proposes `rte_mutex` to hold a pointer to actual mutex
> and use NULL as static initializer, then allocate on first use.
> At the same time we want to use the same initializer for pthread variant.
> This means it would also need indirection, allocation, and tricky logic.
>
> My opinion:
>
> New threading API can just be without static initilizer.
> All it usages in DPDK could be converted to dynamic initialization
> either in appropriate function or using `RTE_INIT`.
> Maybe create a convenient macro to declare a static mutex and its
> initialization code, what do others think?
>
> RTE_STATIC_MUTEX(private_lock)
>
> Expanding to:
>
> static RTE_DECLARE_MUTEX(private_lock)
> RTE_DEFINE_MUTEX(private_lock)
>
>
> Expanding to:
>
> static rte_mutex private_lock;
>
> RTE_INIT(__rte_private_lock_init)
> {
> RTE_VERIFY(rte_thread_mutex_init(&private_lock));
> }
>
> As a bonus it removes the need of `rte_*_thread_types.h`.
Thank you Dmitry, I think this is the best and most elegant solution.
I will use a pointer to represent the mutex:
typedef struct rte_thread_mutex_tag {
void* mutex_id;
} rte_thread_mutex;
..and use the macro for static initializations as you described.
