Re: [PATCH 0/6] add support for CDX bus
Hello, On Fri, Apr 7, 2023 at 8:02 AM Nipun Gupta wrote: > > Support AMD CDX bus, for FPGA based CDX devices. The CDX > devices are memory mapped on system bus for embedded CPUs. > > It uses sysfs interface and the vfio-cdx driver to discover > and initialize the CDX devices. > > The patches are intended for DPDK 23.07 release, and have been sent > as an RFC as patches are yet to be merged in Linux. > > Linux CDX bus patches has been added into linux next: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/cdx > > VFIO patches are also submitted in upstream: > https://www.spinics.net/lists/kvm/msg310623.html Hard to tell just from this link what the status is. Has it been reviewed? When are you expecting this to get merged? > > CDX is a Hardware Architecture designed for AMD FPGA devices. It > consists of mechanism for interaction between FPGA, Firmware and > the APUs (Application CPUs). > Firmware resides on RPU (Realtime CPUs) which interacts with > the FPGA program manager and the APUs. The RPU provides memory-mapped > interface (RPU if) which is used to communicate with APUs. > > VFIO CDX driver provides the CDX device resources like MMIO and interrupts > to map to user-space. DPDK CDX bus uses sysfs interface and the vfio-cdx > driver to discover and initialize the CDX devices for user-space > applications. > > RFC patches in DPDK were submitted at: > http://patches.dpdk.org/project/dpdk/patch/20230124140746.594066-2-nipun.gu...@amd.com/ > > Changes RFC->v1: > - Marked few API's as internal which were not required > to be provided to user. Just a quick pass on this series. - There is an issue with the exported header rte_bus_cdx.h. All the bus specific / driver only parts must be moved to a dedicated bus_cdx_driver.h header (which must be listed in driver_sdk_headers). - To whom is the rte_cdx_dump symbol intended to? Is this for use by user applications? If so, the rte_bus_cdx.h can be kept, to export this symbol. But otherwise, everything in rte_bus_cdx.h can be moved to bus_cdx_driver.h. - Please remove the rte_ prefix for static symbols in *.c. -- David Marchand
Re: [PATCH v2] vfio: do not coalesce DMA mappings
Hello Nipun, Anatoly, On Fri, Apr 7, 2023 at 8:13 AM Nipun Gupta wrote: > > The patch probably shouldn't include the mailmap changes :) Mailmap changes can be done by the submitter. So Nipun did nothing wrong. > > I see in "git log" that all the mailmap changes are with the patch > submitted, probably as it shows checkpatch warning, so it seems this > should be fine? If a submitter includes the mailmap change in his patches, it is fine. Otherwise, the maintainer that merges the first patch of a new contributor will fix the mailmap at the same time. -- David Marchand
Re: [PATCH 0/6] add support for CDX bus
On 4/7/2023 12:48 PM, David Marchand wrote: Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. Hello, On Fri, Apr 7, 2023 at 8:02 AM Nipun Gupta wrote: Support AMD CDX bus, for FPGA based CDX devices. The CDX devices are memory mapped on system bus for embedded CPUs. It uses sysfs interface and the vfio-cdx driver to discover and initialize the CDX devices. The patches are intended for DPDK 23.07 release, and have been sent as an RFC as patches are yet to be merged in Linux. Linux CDX bus patches has been added into linux next: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/cdx VFIO patches are also submitted in upstream: https://www.spinics.net/lists/kvm/msg310623.html Hard to tell just from this link what the status is. Has it been reviewed? When are you expecting this to get merged? The CDX bus code has been merged and VFIO code is under review. Apart from this, we will soon have Open source Linux from AMD which has all the required patches for CDX in a week or so (I will provide the link once that is available). CDX is a Hardware Architecture designed for AMD FPGA devices. It consists of mechanism for interaction between FPGA, Firmware and the APUs (Application CPUs). Firmware resides on RPU (Realtime CPUs) which interacts with the FPGA program manager and the APUs. The RPU provides memory-mapped interface (RPU if) which is used to communicate with APUs. VFIO CDX driver provides the CDX device resources like MMIO and interrupts to map to user-space. DPDK CDX bus uses sysfs interface and the vfio-cdx driver to discover and initialize the CDX devices for user-space applications. RFC patches in DPDK were submitted at: http://patches.dpdk.org/project/dpdk/patch/20230124140746.594066-2-nipun.gu...@amd.com/ Changes RFC->v1: - Marked few API's as internal which were not required to be provided to user. Just a quick pass on this series. - There is an issue with the exported header rte_bus_cdx.h. All the bus specific / driver only parts must be moved to a dedicated bus_cdx_driver.h header (which must be listed in driver_sdk_headers). - To whom is the rte_cdx_dump symbol intended to? Is this for use by user applications? If so, the rte_bus_cdx.h can be kept, to export this symbol. But otherwise, everything in rte_bus_cdx.h can be moved to bus_cdx_driver.h. - Please remove the rte_ prefix for static symbols in *.c. Agree to this. Regards, Nipun -- David Marchand
[PATCH] doc: fix event timer adapter guide
From: Pavan Nikhilesh
Remove incorrect spec definition from programmers guide, it is
applications responsibility to set ev.event_ptr to a valid value.
Fixes: 30e7fbd62839 ("doc: add event timer adapter guide")
Signed-off-by: Pavan Nikhilesh
---
doc/guides/prog_guide/event_timer_adapter.rst | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/doc/guides/prog_guide/event_timer_adapter.rst
b/doc/guides/prog_guide/event_timer_adapter.rst
index 2a15ed8f5c..adeddbedfc 100644
--- a/doc/guides/prog_guide/event_timer_adapter.rst
+++ b/doc/guides/prog_guide/event_timer_adapter.rst
@@ -247,9 +247,7 @@ Note that it is necessary to initialize the event timer
state to
RTE_EVENT_TIMER_NOT_ARMED. Also note that we have saved a pointer to the
``conn`` object in the timer's event payload. This will allow us to locate
the connection object again once we dequeue the timer expiry event from the
-event device later. As a convenience, the application may specify no value for
-ev.event_ptr, and the adapter will by default set it to point at the event
-timer itself.
+event device later.
Now we can arm the event timer with ``rte_event_timer_arm_burst()``:
--
2.25.1
[PATCH] ring: fix the variable name error
Ring dequeue operation's parameters name should be 'cons_xx',
rather than 'prod_xxx'.
Fixes: 1fc73390bcf5 ("ring: refactor exported headers")
Cc: sta...@dpdk.org
Signed-off-by: Feifei Wang
Reviewed-by: Ruifeng Wang
---
lib/ring/rte_ring_elem_pvt.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/ring/rte_ring_elem_pvt.h b/lib/ring/rte_ring_elem_pvt.h
index e24e4492ff..4b80f58980 100644
--- a/lib/ring/rte_ring_elem_pvt.h
+++ b/lib/ring/rte_ring_elem_pvt.h
@@ -194,12 +194,12 @@ __rte_ring_dequeue_elems_32(struct rte_ring *r, const
uint32_t size,
}
static __rte_always_inline void
-__rte_ring_dequeue_elems_64(struct rte_ring *r, uint32_t prod_head,
+__rte_ring_dequeue_elems_64(struct rte_ring *r, uint32_t cons_head,
void *obj_table, uint32_t n)
{
unsigned int i;
const uint32_t size = r->size;
- uint32_t idx = prod_head & r->mask;
+ uint32_t idx = cons_head & r->mask;
uint64_t *ring = (uint64_t *)&r[1];
unaligned_uint64_t *obj = (unaligned_uint64_t *)obj_table;
if (likely(idx + n <= size)) {
@@ -227,12 +227,12 @@ __rte_ring_dequeue_elems_64(struct rte_ring *r, uint32_t
prod_head,
}
static __rte_always_inline void
-__rte_ring_dequeue_elems_128(struct rte_ring *r, uint32_t prod_head,
+__rte_ring_dequeue_elems_128(struct rte_ring *r, uint32_t cons_head,
void *obj_table, uint32_t n)
{
unsigned int i;
const uint32_t size = r->size;
- uint32_t idx = prod_head & r->mask;
+ uint32_t idx = cons_head & r->mask;
rte_int128_t *ring = (rte_int128_t *)&r[1];
rte_int128_t *obj = (rte_int128_t *)obj_table;
if (likely(idx + n <= size)) {
--
2.25.1
[PATCH 1/1] net/ixgbe: add a proper memory barrier for LoongArch
Segmentation fault has been observed while running the ixgbe_recv_pkts_lro() function to receive packets on the Loongson 3C5000 processor which has 64 cores and 4 NUMA nodes. Reason is the read ordering of the status and the rest of the descriptor fields in this function may not be correct on the LoongArch processor. We should add rte_rmb() to ensure the read ordering be correct. We also did the same thing in the ixgbe_recv_pkts() function. Signed-off-by: Min Zhou --- drivers/net/ixgbe/ixgbe_rxtx.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c index c9d6ca9efe..16391a42f9 100644 --- a/drivers/net/ixgbe/ixgbe_rxtx.c +++ b/drivers/net/ixgbe/ixgbe_rxtx.c @@ -1823,6 +1823,9 @@ ixgbe_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, staterr = rxdp->wb.upper.status_error; if (!(staterr & rte_cpu_to_le_32(IXGBE_RXDADV_STAT_DD))) break; +#if defined(RTE_ARCH_LOONGARCH) + rte_rmb(); +#endif rxd = *rxdp; /* @@ -2122,6 +2125,9 @@ ixgbe_recv_pkts_lro(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts, if (!(staterr & IXGBE_RXDADV_STAT_DD)) break; +#if defined(RTE_ARCH_LOONGARCH) + rte_rmb(); +#endif rxd = *rxdp; PMD_RX_LOG(DEBUG, "port_id=%u queue_id=%u rx_id=%u " -- 2.31.1
[Bug 1212] [dpdk-21.11.8]pvp_qemu_multi_paths_port_restart:perf_pvp_qemu_vector_rx_mac: performance drop about 23.5% when send small packets
https://bugs.dpdk.org/show_bug.cgi?id=1212 Bug ID: 1212 Summary: [dpdk-21.11.8]pvp_qemu_multi_paths_port_restart:perf_p vp_qemu_vector_rx_mac: performance drop about 23.5% when send small packets Product: DPDK Version: 20.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: vhost/virtio Assignee: dev@dpdk.org Reporter: weix.l...@intel.com Target Milestone: --- [Environment] DPDK version: Use make showversion or for a non-released version: git remote -v && git show-ref --heads 20.11.8-rc1 Other software versions: QEMU-7.0.0. OS: Ubuntu 22.04.1 LTS/Linux 5.15.45-051545-generic Compiler: gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04) Hardware platform: Intel(R) Xeon(R) Platinum 8280M CPU @ 2.70GHz NIC hardware: Intel Ethernet Controller XL710 for 40GbE QSFP+ 1583 NIC firmware: i40e-2.22.18/9.20 0x8000d893 1.3353.0 [Test Setup] Steps to reproduce List the steps to reproduce the issue. 1.Bind 1 NIC port to vfio-pci dpdk-devbind.py --force --bind=vfio-pci :af:00.0 2.Start vhost-user: x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 28,29,30 -n 4 -a :af:00.0 --file-prefix=vhost_2352949_20230407162534 --vdev 'net_vhost0,iface=vhost-net,queues=1' -- -i --nb-cores=1 --txd=1024 --rxd=1024 testpmd>set fwd mac testpmd>start 3.Start VM0 with QEMU-7.0.0 taskset -c 20,21,22,23,24,25,26,27 /home/QEMU/qemu-7.0.0/bin/qemu-system-x86_64 -name vm0 -enable-kvm -pidfile /tmp/.vm0.pid -daemonize -monitor unix:/tmp/vm0_monitor.sock,server,nowait -netdev user,id=nttsip1,hostfwd=tcp:10.239.252.220:6000-:22 -device e1000,netdev=nttsip1 -chardev socket,id=char0,path=./vhost-net -netdev type=vhost-user,id=netdev0,chardev=char0,vhostforce -device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=true,mrg_rxbuf=off,rx_queue_size=1024,tx_queue_size=1024 -cpu host -smp 8 -m 16384 -object memory-backend-file,id=mem,size=16384M,mem-path=/mnt/huge,share=on -numa node,memdev=mem -mem-prealloc -chardev socket,path=/tmp/vm0_qga0.sock,server,nowait,id=vm0_qga0 -device virtio-serial -device virtserialport,chardev=vm0_qga0,name=org.qemu.guest_agent.0 -vnc :4 -drive file=/home/image/ubuntu2004.img 4.SSH VM0 and bind virtio-net to vfio-pci: echo 0 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages echo 1024 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages mkdir -p /mnt/huge mount -t hugetlbfs nodev /mnt/hugemodprobe vfio-pci echo 1 > /sys/module/vfio/parameters/enable_unsafe_noiommu_mode dpdk-devbind.py --force --bind=vfio-pci :00:04.0 5.Start testpmd in VM0: x86_64-native-linuxapp-gcc/app/dpdk-testpmd -c 0x3 -n 3 -- -i --nb-cores=1 --txd=1024 --rxd=1024 testpmd>set fwd mac testpmd>start 6.Use pktgen to send packets, and record the throughput. Show the output from the previous commands. +--+--+--+++ | FrameSize(B) | Mode | Throughput(Mpps) | % linerate | Cycle | +==+==+==+++ | 64 | virtio0.95 vector_rx | 4.314| 7.247 | Before Restart | +--+--+--+++ | 128 | virtio0.95 vector_rx | 4.244| 12.563 | Before Restart | +--+--+--+++ | 256 | virtio0.95 vector_rx | 4.576| 25.262 | Before Restart | +--+--+--+++ | 512 | virtio0.95 vector_rx | 3.435| 36.544 | Before Restart | +--+--+--+++ | 1024 | virtio0.95 vector_rx | 2.695| 56.268 | Before Restart | +--+--+--+++ | 1280 | virtio0.95 vector_rx | 2.490| 64.731 | Before Restart | +--+--+--+++ | 1518 | virtio0.95 vector_rx | 2.248| 69.140 | Before Restart | +--+--+--+++ [Expected Result] Explain what is the expected result in text or as an example output: +--+--+--+++ | FrameSize(B) | Mode | Throughput(Mpps) | % linerate | Cycle | +==+==+==+++ | 64 | virtio0.95 vector_rx | 5.642| 9.478 | Before Restart | +--+--+--
Re: [PATCH] common/sfc_efx/base: support link status change v2 events
On 3/30/2023 8:16 AM, Andrew Rybchenko wrote: > On 3/28/23 19:51, Ivan Malov wrote: >> FW should send link status change events in either v1 or >> v2 format depending on the preference which the driver >> can express during CMD_DRV_ATTACH stage. At the moment, >> libefx does not request v2, so v1 events must arrive. >> However, FW does not honour this choice and always >> sends v2 events. So teach libefx to parse such and >> add v2 request to CMD_DRV_ATTACH, correspondingly. >> >> Signed-off-by: Ivan Malov >> Reviewed-by: Andy Moreton > > Acked-by: Andrew Rybchenko > > Applied to dpdk-next-net/main, thanks.
Clarify FEC capabilities
Hi, We are currently working on implementing the Forward Error Correction (FEC) feature in our driver, but we have encountered some difficulties in understanding the interpretation of the semantics of 'fec_capa', a bitmask of allowed FEC modes. Specifically, we are unclear about the meaning of various bit combinations. In rte_ethdev.h, 'fec_capa' is defined as follows: ``` * @param fec_capa * A bitmask of allowed FEC modes. If AUTO bit is set, other * bits specify FEC modes which may be negotiated. If AUTO * bit is clear, specify FEC modes to be used (only one valid * mode per speed may be set). ``` We have a few questions regarding this definition: * Is it possible for the AUTO bit to be set without any other bits? * Can both RS and BASER bits be set together without the AUTO bit? Based on our understanding, we have come up with the following interpretations for different bit combinations: * NOFEC overrides any other bits, and means "disable all FEC"; * AUTO on its own implies using cable requirements and link partner autoneg with firmware-default preferences for the cable type; * AUTO combined with either RS or BASER signifies using the specified FEC type if the cable and link partner support it; otherwise, autoneg/firmware-default is used; * RS or BASER alone means using the specified FEC type if the cable and link partner support it and either requests it; otherwise, no FEC is employed; * Both RS and BASER, with or without AUTO, indicate using FEC if the cable and link partner support it, preferring RS to BASER. We would greatly appreciate any assistance in clarifying our understanding and ensuring that our interpretations are accurate. Thank you in advance for your help. Sincerely, Denis
RE: [PATCH] app/crypto-perf: change buffer size based on optype
> -Original Message- > From: Tejasree Kondoj > Sent: Thursday 6 April 2023 09:16 > To: Akhil Goyal ; Fan Zhang > ; Power, Ciara > Cc: Anoob Joseph ; dev@dpdk.org > Subject: [PATCH] app/crypto-perf: change buffer size based on optype > > Adding digest size to buffer size in auth-then-cipher mode with auth_op set > to generate as cipher length includes digest size also. > > Signed-off-by: Tejasree Kondoj > --- > app/test-crypto-perf/cperf_options_parsing.c | 8 > 1 file changed, 8 insertions(+) > Acked-by: Ciara Power
RE: [PATCH] ring: fix the variable name error
> From: Feifei Wang [mailto:feifei.wa...@arm.com]
> Sent: Friday, 7 April 2023 10.48
>
> Ring dequeue operation's parameters name should be 'cons_xx',
> rather than 'prod_xxx'.
>
> Fixes: 1fc73390bcf5 ("ring: refactor exported headers")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Feifei Wang
> Reviewed-by: Ruifeng Wang
> ---
Acked-by: Morten Brørup
DPDK Release Status Meeting 2023-04-06
Release status meeting minutes 2023-04-06 = Agenda: * Release Dates * Subtrees * Roadmaps * LTS * Defects * Opens Participants: * AMD * ARM * Debian/Microsoft * Intel * Marvell * Nvidia * Red Hat Release Dates - The following are the proposed current dates for 23.07: * V1: 22 April 2023 * RC1: 31 May 2023 * RC2: 21 June 2023 * RC3: 28 June 2023 * Release: 12 July 2023 Subtrees * next-net * Deferred patches moved to new. * next-net-intel * No update * next-net-mlx * No update * next-net-mvl * Some work ongoing for this release. * next-eventdev * A few minor feature * next-baseband * No major features so far. * next-virtio * New series on guest notifications in slow path * VDU - Vhost VDPA in userspace. https://lwn.net/Articles/841054/ * next-crypto * Updates to PDCP * Patches for asymmetric crypto * Rte_security patch for out of place inline IPsec * main * A lot of patches to improve the Windows port * New version of lock annotation support * Patches from ARM for PMU * Memarea feature * CDX bus patches from AMD * Call for updates to the external Roadmap: https://core.dpdk.org/roadmap/ * Retrospective: * Bonding PMD: there is a gap in maintenance. Proposed Schedule for 2023 -- See also http://core.dpdk.org/roadmap/#dates 23.07 * Proposal deadline (RFC/v1 patches): 22 April 2023 * API freeze (-rc1): 31 May 2023 * PMD features freeze (-rc2): 21 June 2023 * Builtin applications features freeze (-rc3): 28 June 2023 * Release: 12 July 2023 23.11 * Proposal deadline (RFC/v1 patches): 12 August 2023 * API freeze (-rc1): 29 September 2023 * PMD features freeze (-rc2): 20 October 2023 * Builtin applications features freeze (-rc3): 27 October 2023 * Release: 15 November 2023 LTS --- Next LTS releases will be: * 22.11.1 * 21.11.4 * On track for RC1 * 20.11.8 * RC1 sent and first test report received * 19.11.15 * CVE and critical fixes only. * Distros * v20.11 in Debian 11 * Ubuntu 22.04 contains 21.11 Defects --- * Bugzilla links, 'Bugs', added for hosted projects * https://www.dpdk.org/hosted-projects/ 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 Thursday at 9:30 UTC over Jitsi on https://meet.jit.si/DPDK You don't need an invite to join the meeting but if you want a calendar reminder just send an email to "John McNamara john.mcnam...@intel.com" for the invite.
[Bug 1213] [Windows] BSOD when shutting down testpmd
https://bugs.dpdk.org/show_bug.cgi?id=1213 Bug ID: 1213 Summary: [Windows] BSOD when shutting down testpmd Product: DPDK Version: 22.11 Hardware: All OS: Windows Status: UNCONFIRMED Severity: major Priority: Normal Component: core Assignee: dev@dpdk.org Reporter: a.polle...@deltacast.tv Target Milestone: --- Hello, When shutting down the testpmd command I get a BSOD (PROCESS_HAS_LOCKED_PAGES): This testpmd allocate 40 queues RX and 40 queues TX. The total number of mbuf is set to 700. This command is supposed to allocate +- 40GB of memory in total for the 80 queues. .\dpdk-testpmd.exe -l 1-5 -n 4 -a :5e:00.0 -- --socket-num=0 --burst=16 --txd=1024 --rxd=1024 --mbcache=512 --txq=40 --rxq=40 --nb-cores=4 --txpkts=1500 -i --forward-mode=flowgen --eth-peer=0,01:00:5e:00:00:05 --tx-ip=10.10.1.14,239.0.0.5 --tx-udp=42500,42500 --total-num-mbuf=700 This testpmd command is working properly until you call quit in the interactive command line. When the application shutdown the machine freeze and show a BSOD (PROCESS_HAS_LOCKED_PAGES). When analysing the minidump generated, we see that some page are found in the process that have been terminated. In the bellow comment you'll find the minidump analyze. Could you try to reproduce it on your side ? The problem doesn't seem to be linked to some out of memory issues. (The server have a total of 384 GB of ram and should handle easily 40GB of allocation) SETUP: CPU : 2x Intel Xeon platinum 8268 RAM: 6x memory channel - 192GB on each numa OS: Windows Server 2022 21H2 NIC: Intel E810 100G Dual port DPDK version: 22.11 -- You are receiving this mail because: You are the assignee for the bug.
Re: [PATCH] net/hns3: fix build warning
On 4/4/2023 9:22 AM, Dongdong Liu wrote: > Hi Jerin > > Many thanks for fixing the warning. > On 2023/4/4 14:55, jer...@marvell.com wrote: >> From: Jerin Jacob >> >> aarch64 gcc 12.2.0 build complain with below warning[1]. >> Move the new_link initialization upwards to fix the warning. >> >> Compiling C object >> drivers/libtmp_rte_net_hns3.a.p/net_hns3_hns3_ethdev.c.o >> drivers/net/hns3/hns3_ethdev.c: In function ‘hns3_dev_link_update’: >> drivers/net/hns3/hns3_ethdev.c:2249:1: warning: ‘new_link’ may be >> used uninitialized [-Wmaybe-uninitialized] > It looks like a false positive from the logic of the code. > Anyway, this warning can be fixed by this patch, so > Acked-by: Dongdong Liu > Agree that it looks false positive. Moving memset upwards does unnecessary memset for some case but this can be OK for control path function. Applied to dpdk-next-net/main, thanks.
Re: [PATCH v2 1/5] telemetry: fix autotest failures on Alpine
On Wed, Apr 05, 2023 at 04:44:10PM +0100, Bruce Richardson wrote:
> On Alpine linux, the telemetry_data_autotest was failing for the
> test where we had dictionaries embedded in other dictionaries up
> to three levels deep. Indications are that this issue is due to
> excess data being stored on the stack, so replace stack-allocated
> buffer data with dynamically allocated data in the case where we
> are doing recursive processing of telemetry data structures into
> json.
>
> Bugzilla ID: 1177
> Fixes: c933bb5177ca ("telemetry: support array values in data object")
> Fixes: d2671e642a8e ("telemetry: support dict of dicts")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Bruce Richardson
>
> ---
Acked-by: Tyler Retzlaff
(one observation below)
> V2:
> set '\0' in newly malloc'ed buffer to ensure it always has valid
> string data.
> ---
> lib/telemetry/telemetry.c | 21 ++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/lib/telemetry/telemetry.c b/lib/telemetry/telemetry.c
> index 7bceadcee7..728a0bffd4 100644
> --- a/lib/telemetry/telemetry.c
> +++ b/lib/telemetry/telemetry.c
> @@ -208,7 +208,11 @@ container_to_json(const struct rte_tel_data *d, char
> *out_buf, size_t buf_len)
> break;
> case RTE_TEL_CONTAINER:
> {
> - char temp[buf_len];
> + char *temp = malloc(buf_len);
> + if (temp == NULL)
> + break;
> + *temp = '\0'; /* ensure valid string */
> +
> const struct container *cont =
> &v->value.container;
> if (container_to_json(cont->data,
> @@ -219,6 +223,7 @@ container_to_json(const struct rte_tel_data *d, char
> *out_buf, size_t buf_len)
> v->name, temp);
> if (!cont->keep)
> rte_tel_data_free(cont->data);
> + free(temp);
> break;
> }
> }
> @@ -275,7 +280,11 @@ output_json(const char *cmd, const struct rte_tel_data
> *d, int s)
> break;
> case RTE_TEL_CONTAINER:
> {
> - char temp[buf_len];
> + char *temp = malloc(buf_len);
> + if (temp == NULL)
> + break;
> + *temp = '\0'; /* ensure valid string */
> +
> const struct container *cont =
> &v->value.container;
> if (container_to_json(cont->data,
> @@ -286,6 +295,7 @@ output_json(const char *cmd, const struct rte_tel_data
> *d, int s)
> v->name, temp);
> if (!cont->keep)
> rte_tel_data_free(cont->data);
> + free(temp);
not expressing a preference just noticing that when
RTE_TEL_CONTAINER cases are the last case in the switch sometimes there
is an explicit break; and sometimes not.
> }
> }
> }
> @@ -311,7 +321,11 @@ output_json(const char *cmd, const struct rte_tel_data
> *d, int s)
> buf_len, used,
> d->data.array[i].uval);
> else if (d->type == TEL_ARRAY_CONTAINER) {
> - char temp[buf_len];
> + char *temp = malloc(buf_len);
> + if (temp == NULL)
> + break;
> + *temp = '\0'; /* ensure valid string */
> +
> const struct container *rec_data =
> &d->data.array[i].container;
> if (container_to_json(rec_data->data,
> @@ -321,6 +335,7 @@ output_json(const char *cmd, const struct rte_tel_data
> *d, int s)
> buf_len, used, temp);
> if (!rec_data->keep)
> rte_tel_data_free(rec_data->data);
> + free(temp);
> }
> break;
> }
> --
> 2.37.2
Re: [PATCH v3 1/5] telemetry: fix autotest failures on Alpine
On Wed, Apr 05, 2023 at 05:03:22PM +0100, Bruce Richardson wrote:
> On Alpine linux, the telemetry_data_autotest was failing for the
> test where we had dictionaries embedded in other dictionaries up
> to three levels deep. Indications are that this issue is due to
> excess data being stored on the stack, so replace stack-allocated
> buffer data with dynamically allocated data in the case where we
> are doing recursive processing of telemetry data structures into
> json.
>
> Bugzilla ID: 1177
> Fixes: c933bb5177ca ("telemetry: support array values in data object")
> Fixes: d2671e642a8e ("telemetry: support dict of dicts")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Bruce Richardson
>
> ---
Acked-by: Tyler Retzlaff
(ack on latest version)
Re: [PATCH v3 2/5] telemetry: remove variable length array in printf fn
On Wed, Apr 05, 2023 at 05:03:23PM +0100, Bruce Richardson wrote: > The json_snprintf function, used to add json characters on to a buffer, > leaving the buffer unmodified in case of error, used a variable length > array to store the data temporarily while checking for overflow. VLAs > can be unsafe, and are unsupported by some compilers, so remove use of > the VLA. > > For the normal case where there is only a small amount of existing text > in the buffer (<4 chars) to be preserved, save that off temporarily to a > local array, and restore on error. To handle cases where there is more > than a few characters in the buffer, we use the existing logic of doing > the print to a temporary buffer initially and then copying. In this > case, though we use malloc-allocated buffer rather than VLA. > > Within the unit tests, the "telemetry_data_autotests" test cases - which > mimic real telemetry use - all exercise the first path. The > telemetry_json_autotest cases work directly with generating json, and > use uninitialized buffers so also test the second, malloc-allocated > buffer, cases. > > Signed-off-by: Bruce Richardson > > --- Acked-by: Tyler Retzlaff
Re: [PATCH v3 3/5] telemetry: split out body of json string format fn
On Wed, Apr 05, 2023 at 05:03:24PM +0100, Bruce Richardson wrote: > To enable further rework to (efficiently) avoid using variable-length > arrays, we first separate out the body of the __json_format_str > function. This means that the actual VLA buffer is in the wrapper > function, and means we can reuse the actual writing code in multiple > code paths without duplication. > > Signed-off-by: Bruce Richardson > --- Acked-by: Tyler Retzlaff
Re: [PATCH v3 4/5] telemetry: rename local variables
On Wed, Apr 05, 2023 at 05:03:25PM +0100, Bruce Richardson wrote:
> In the newly separated out function, rename "tmp" to "buf" to have more
> meaningful variable names.
>
> Signed-off-by: Bruce Richardson
>
> ---
Acked-by: Tyler Retzlaff
(with suggestions)
>
> When committing, this patch can be merged with the previous. I've kept
> them separate for now, as it makes reviewing a lot easier.
> ---
> lib/telemetry/telemetry_json.h | 32
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/lib/telemetry/telemetry_json.h b/lib/telemetry/telemetry_json.h
> index aada523a27..c087b833eb 100644
> --- a/lib/telemetry/telemetry_json.h
> +++ b/lib/telemetry/telemetry_json.h
> @@ -84,44 +84,44 @@ static const char control_chars[0x20] = {
> * directly, but returns 0 on overflow. Otherwise returns number of chars
> written to buffer.
> */
> static inline int
> -__json_format_str_to_buf(char *tmp, const int len,
> +__json_format_str_to_buf(char *buf, const int len,
> const char *prefix, const char *str, const char *suffix)
does it cascade rubbish into the caller if `len` is made to be type
`size_t` instead of `int`?
> {
> - int tmpidx = 0;
> + int bufidx = 0;
>
> - while (*prefix != '\0' && tmpidx < len)
> - tmp[tmpidx++] = *prefix++;
> - if (tmpidx >= len)
> + while (*prefix != '\0' && bufidx < len)
> + buf[bufidx++] = *prefix++;
> + if (bufidx >= len)
> return 0;
>
> while (*str != '\0') {
> if (*str < (int)RTE_DIM(control_chars)) {
> int idx = *str; /* compilers don't like char type as
> index */
should be `size_t` instead of `int` type for idx.
> if (control_chars[idx] != 0) {
> - tmp[tmpidx++] = '\\';
> - tmp[tmpidx++] = control_chars[idx];
> + buf[bufidx++] = '\\';
> + buf[bufidx++] = control_chars[idx];
> }
> } else if (*str == '"' || *str == '\\') {
> - tmp[tmpidx++] = '\\';
> - tmp[tmpidx++] = *str;
> + buf[bufidx++] = '\\';
> + buf[bufidx++] = *str;
> } else
> - tmp[tmpidx++] = *str;
> + buf[bufidx++] = *str;
> /* we always need space for (at minimum) closing quote and null
> character.
>* Ensuring at least two free characters also means we can
> always take an
>* escaped character like "\n" without overflowing
>*/
> - if (tmpidx > len - 2)
> + if (bufidx > len - 2)
> return 0;
> str++;
> }
>
> - while (*suffix != '\0' && tmpidx < len)
> - tmp[tmpidx++] = *suffix++;
> - if (tmpidx >= len)
> + while (*suffix != '\0' && bufidx < len)
> + buf[bufidx++] = *suffix++;
> + if (bufidx >= len)
> return 0;
>
> - tmp[tmpidx] = '\0';
> - return tmpidx;
> + buf[bufidx] = '\0';
> + return bufidx;
> }
>
> /**
> --
> 2.37.2
Re: [PATCH v3 5/5] telemetry: remove VLA in json string format function
On Wed, Apr 05, 2023 at 05:03:26PM +0100, Bruce Richardson wrote: > Since variable length arrays (VLAs) are potentially insecure and > unsupported by some compilers, rework the code to remove their use. As > with previous changes to remove VLAs in the telemetry code, this > function uses two methods to avoid modifying the buffer when adding to > it fails: > * if there are only a few characters in the buffer, save them off to > restore on failure, then use the buffer as-is, > * otherwise use malloc rather than a VLA to allocate a temporary buffer > and copy from that on success only. > > Signed-off-by: Bruce Richardson > --- Acked-by: Tyler Retzlaff
[PATCH 0/7] add setting and querying of LLRS FEC mode
This patchset include some bugfixes for hns3 fec and add setting and querying of LLRS FEC mode. Jie Hai (7): net/hns3: fix fec mode for 200G ports net/hns3: fix fec mode check error net/hns3: fix missing FEC capability ethdev: introduce low latency RS FEC app/testpmd: add setting and querying of LLRS FEC mode net/hns3: add LLRS FEC mode support for 200G ports net/hns3: support getting current FEC capability from firmware app/test-pmd/cmdline.c | 5 +- app/test-pmd/config.c | 4 + doc/guides/rel_notes/release_23_07.rst | 3 + doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +- drivers/net/hns3/hns3_cmd.c | 1 + drivers/net/hns3/hns3_cmd.h | 11 +- drivers/net/hns3/hns3_ethdev.c | 216 ++-- drivers/net/hns3/hns3_ethdev.h | 2 + lib/ethdev/rte_ethdev.h | 1 + 9 files changed, 129 insertions(+), 116 deletions(-) -- 2.22.0
[PATCH 1/7] net/hns3: fix fec mode for 200G ports
From: Jie Hai
The hardware does not support NOFEC for 200G ports. So delete this
bit.
Fixes: 9bf2ea8dbc65 ("net/hns3: support FEC")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
Signed-off-by: Dongdong Liu
---
drivers/net/hns3/hns3_ethdev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index a872cb8dd7..fbf2e5aa6c 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -83,8 +83,7 @@ static const struct rte_eth_fec_capa speed_fec_capa_tbl[] = {
RTE_ETH_FEC_MODE_CAPA_MASK(AUTO) |
RTE_ETH_FEC_MODE_CAPA_MASK(RS) },
- { RTE_ETH_SPEED_NUM_200G, RTE_ETH_FEC_MODE_CAPA_MASK(NOFEC) |
- RTE_ETH_FEC_MODE_CAPA_MASK(AUTO) |
+ { RTE_ETH_SPEED_NUM_200G, RTE_ETH_FEC_MODE_CAPA_MASK(AUTO) |
RTE_ETH_FEC_MODE_CAPA_MASK(RS) }
};
--
2.22.0
[PATCH 2/7] net/hns3: fix fec mode check error
From: Jie Hai
The function is_fec_mode_one_bit_set() is used to check whether
the binary of the mode from user only contains one '1'. But it
uses the bytes number this mode variable occupied to calculate
the count. So this patch uses __builtin_popcount() to replace it.
This patch also extracts the code for verifying mode parameter into
a function.
Fixes: 9bf2ea8dbc65 ("net/hns3: support FEC")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
Signed-off-by: Dongdong Liu
---
drivers/net/hns3/hns3_ethdev.c | 50 --
1 file changed, 24 insertions(+), 26 deletions(-)
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index fbf2e5aa6c..9968518b2d 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -6166,52 +6166,50 @@ get_current_speed_fec_cap(struct hns3_hw *hw, struct
rte_eth_fec_capa *fec_capa)
return cur_capa;
}
-static bool
-is_fec_mode_one_bit_set(uint32_t mode)
-{
- int cnt = 0;
- uint8_t i;
-
- for (i = 0; i < sizeof(mode); i++)
- if (mode >> i & 0x1)
- cnt++;
-
- return cnt == 1 ? true : false;
-}
-
static int
-hns3_fec_set(struct rte_eth_dev *dev, uint32_t mode)
+hns3_fec_mode_valid(struct rte_eth_dev *dev, uint32_t mode)
{
#define FEC_CAPA_NUM 2
struct hns3_adapter *hns = dev->data->dev_private;
struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(hns);
- struct hns3_pf *pf = &hns->pf;
struct rte_eth_fec_capa fec_capa[FEC_CAPA_NUM];
- uint32_t cur_capa;
uint32_t num = FEC_CAPA_NUM;
+ uint32_t cur_capa;
int ret;
- ret = hns3_fec_get_capability(dev, fec_capa, num);
- if (ret < 0)
- return ret;
-
- /* HNS3 PMD only support one bit set mode, e.g. 0x1, 0x4 */
- if (!is_fec_mode_one_bit_set(mode)) {
- hns3_err(hw, "FEC mode(0x%x) not supported in HNS3 PMD, "
-"FEC mode should be only one bit set", mode);
+ if (__builtin_popcount(mode) != 1) {
+ hns3_err(hw, "FEC mode(0x%x) should be only one bit set", mode);
return -EINVAL;
}
+ ret = hns3_fec_get_capability(dev, fec_capa, num);
+ if (ret < 0)
+ return ret;
/*
* Check whether the configured mode is within the FEC capability.
* If not, the configured mode will not be supported.
*/
cur_capa = get_current_speed_fec_cap(hw, fec_capa);
- if (!(cur_capa & mode)) {
- hns3_err(hw, "unsupported FEC mode = 0x%x", mode);
+ if ((cur_capa & mode) == 0) {
+ hns3_err(hw, "unsupported FEC mode(0x%x)", mode);
return -EINVAL;
}
+ return 0;
+}
+
+static int
+hns3_fec_set(struct rte_eth_dev *dev, uint32_t mode)
+{
+ struct hns3_adapter *hns = dev->data->dev_private;
+ struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(hns);
+ struct hns3_pf *pf = &hns->pf;
+ int ret;
+
+ ret = hns3_fec_mode_valid(dev, mode);
+ if (ret != 0)
+ return ret;
+
rte_spinlock_lock(&hw->lock);
ret = hns3_set_fec_hw(hw, mode);
if (ret) {
--
2.22.0
[PATCH 3/7] net/hns3: fix missing FEC capability
From: Jie Hai
Currently, FEC capabilities are reported based on the device ID.
And a device ID is bound to only one or two rates. So some cases
hns3 driver only reports the FEC capabilities corresponding to
the rate. But hns3 supports speed switching function, which causes
the FEC capabilities of other rates are not reported. So this patch
reports the FEC capabilities by the speed capabilities of the
network port.
Fixes: 9bf2ea8dbc65 ("net/hns3: support FEC")
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
Signed-off-by: Dongdong Liu
---
drivers/net/hns3/hns3_ethdev.c | 129 -
1 file changed, 45 insertions(+), 84 deletions(-)
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 9968518b2d..80cdcc83bf 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -60,6 +60,13 @@ enum hns3_evt_cause {
HNS3_VECTOR0_EVENT_OTHER,
};
+#define HNS3_SPEEDS_SUPP_FEC (RTE_ETH_LINK_SPEED_10G | \
+ RTE_ETH_LINK_SPEED_25G | \
+ RTE_ETH_LINK_SPEED_40G | \
+ RTE_ETH_LINK_SPEED_50G | \
+ RTE_ETH_LINK_SPEED_100G | \
+ RTE_ETH_LINK_SPEED_200G)
+
static const struct rte_eth_fec_capa speed_fec_capa_tbl[] = {
{ RTE_ETH_SPEED_NUM_10G, RTE_ETH_FEC_MODE_CAPA_MASK(NOFEC) |
RTE_ETH_FEC_MODE_CAPA_MASK(AUTO) |
@@ -5927,56 +5934,27 @@ hns3_reset_service(void *param)
hns3_msix_process(hns, reset_level);
}
-static unsigned int
-hns3_get_speed_capa_num(uint16_t device_id)
+static uint32_t
+hns3_get_speed_fec_capa(struct rte_eth_fec_capa *speed_fec_capa,
+ uint32_t speed_capa)
{
- unsigned int num;
-
- switch (device_id) {
- case HNS3_DEV_ID_25GE:
- case HNS3_DEV_ID_25GE_RDMA:
- num = 2;
- break;
- case HNS3_DEV_ID_100G_RDMA_MACSEC:
- case HNS3_DEV_ID_200G_RDMA:
- num = 1;
- break;
- default:
- num = 0;
- break;
- }
+ uint32_t speed_bit;
+ uint32_t num = 0;
+ uint32_t i;
- return num;
-}
+ for (i = 0; i < RTE_DIM(speed_fec_capa_tbl); i++) {
+ speed_bit =
+ rte_eth_speed_bitflag(speed_fec_capa_tbl[i].speed,
+ RTE_ETH_LINK_FULL_DUPLEX);
+ if ((speed_capa & speed_bit) == 0)
+ continue;
-static int
-hns3_get_speed_fec_capa(struct rte_eth_fec_capa *speed_fec_capa,
- uint16_t device_id)
-{
- switch (device_id) {
- case HNS3_DEV_ID_25GE:
- /* fallthrough */
- case HNS3_DEV_ID_25GE_RDMA:
- speed_fec_capa[0].speed = speed_fec_capa_tbl[1].speed;
- speed_fec_capa[0].capa = speed_fec_capa_tbl[1].capa;
-
- /* In HNS3 device, the 25G NIC is compatible with 10G rate */
- speed_fec_capa[1].speed = speed_fec_capa_tbl[0].speed;
- speed_fec_capa[1].capa = speed_fec_capa_tbl[0].capa;
- break;
- case HNS3_DEV_ID_100G_RDMA_MACSEC:
- speed_fec_capa[0].speed = speed_fec_capa_tbl[4].speed;
- speed_fec_capa[0].capa = speed_fec_capa_tbl[4].capa;
- break;
- case HNS3_DEV_ID_200G_RDMA:
- speed_fec_capa[0].speed = speed_fec_capa_tbl[5].speed;
- speed_fec_capa[0].capa = speed_fec_capa_tbl[5].capa;
- break;
- default:
- return -ENOTSUP;
+ speed_fec_capa[num].speed = speed_fec_capa_tbl[i].speed;
+ speed_fec_capa[num].capa = speed_fec_capa_tbl[i].capa;
+ num++;
}
- return 0;
+ return num;
}
static int
@@ -5985,28 +5963,28 @@ hns3_fec_get_capability(struct rte_eth_dev *dev,
unsigned int num)
{
struct hns3_hw *hw = HNS3_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
- uint16_t device_id = pci_dev->id.device_id;
- unsigned int capa_num;
- int ret;
+ unsigned int speed_num;
+ uint32_t speed_capa;
- capa_num = hns3_get_speed_capa_num(device_id);
- if (capa_num == 0) {
- hns3_err(hw, "device(0x%x) is not supported by hns3 PMD",
-device_id);
+ speed_capa = hns3_get_speed_capa(hw);
+ /* speed_num counts number of speed capabilities */
+ speed_num = __builtin_popcount(speed_capa & HNS3_SPEEDS_SUPP_FEC);
+ if (speed_num == 0)
return -ENOTSUP;
- }
- if (speed_fec_capa == NULL || num < capa_num)
- return capa_num;
+ if (speed_fec_capa == NULL)
+ return speed_num;
- ret = hns3_get_speed_fec_capa(speed_fec_capa, device_id)
[PATCH 4/7] ethdev: introduce low latency RS FEC
From: Jie Hai
This patch introduces LLRS (low latency Reed Solomon FEC).
LLRS supports for 25 Gbps, 50 Gbps, 100 Gbps, 200 Gbps and
400 Gbps Ethernet networks.
Signed-off-by: Jie Hai
Signed-off-by: Dongdong Liu
---
doc/guides/rel_notes/release_23_07.rst | 3 +++
lib/ethdev/rte_ethdev.h| 1 +
2 files changed, 4 insertions(+)
diff --git a/doc/guides/rel_notes/release_23_07.rst
b/doc/guides/rel_notes/release_23_07.rst
index a9b1293689..dcc4c84907 100644
--- a/doc/guides/rel_notes/release_23_07.rst
+++ b/doc/guides/rel_notes/release_23_07.rst
@@ -55,6 +55,9 @@ New Features
Also, make sure to start the actual text at the margin.
===
+* **Added LLRS FEC mode in ethdev.**
+
+ Added RTE_ETH_FEC_LLRS to rte_eth_fec_mode.
Removed Items
-
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 99fe9e238b..bea847fcc3 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1916,6 +1916,7 @@ enum rte_eth_fec_mode {
RTE_ETH_FEC_AUTO, /**< FEC autonegotiation modes */
RTE_ETH_FEC_BASER, /**< FEC using common algorithm */
RTE_ETH_FEC_RS, /**< FEC using RS algorithm */
+ RTE_ETH_FEC_LLRS, /**< FEC using LLRS algorithm */
};
/* Translate from FEC mode to FEC capa */
--
2.22.0
[PATCH 5/7] app/testpmd: add setting and querying of LLRS FEC mode
From: Jie Hai
This patch supports setting and querying of LLRS FEC mode.
Signed-off-by: Jie Hai
Signed-off-by: Dongdong Liu
---
app/test-pmd/cmdline.c | 5 -
app/test-pmd/config.c | 4
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +-
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 7b20bef4e9..38fa0f507c 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -11973,6 +11973,9 @@ cmd_show_fec_mode_parsed(void *parsed_result,
case RTE_ETH_FEC_MODE_CAPA_MASK(RS):
strlcpy(buf, "rs", sizeof(buf));
break;
+ case RTE_ETH_FEC_MODE_CAPA_MASK(LLRS):
+ strlcpy(buf, "llrs", sizeof(buf));
+ break;
default:
return;
}
@@ -12068,7 +12071,7 @@ cmd_set_port_fec_mode_parsed(
static cmdline_parse_inst_t cmd_set_fec_mode = {
.f = cmd_set_port_fec_mode_parsed,
.data = NULL,
- .help_str = "set port fec_mode auto|off|rs|baser",
+ .help_str = "set port fec_mode auto|off|rs|baser|llrs",
.tokens = {
(void *)&cmd_set_port_fec_mode_set,
(void *)&cmd_set_port_fec_mode_port,
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 096c218c12..f306d678f9 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -170,6 +170,10 @@ static const struct {
.mode = RTE_ETH_FEC_RS,
.name = "rs",
},
+ {
+ .mode = RTE_ETH_FEC_LLRS,
+ .name = "llrs",
+ },
};
static const struct {
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 8f23847859..fa1cea3ed6 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1800,7 +1800,7 @@ Set fec mode
Set fec mode for a specific port::
- testpmd> set port (port_id) fec_mode auto|off|rs|baser
+ testpmd> set port (port_id) fec_mode auto|off|rs|baser|llrs
Config Sample actions list
~~
--
2.22.0
[PATCH 7/7] net/hns3: support getting current FEC capability from firmware
From: Jie Hai
Obtain the supported FEC capability from the firmware to
enhance code compatibility.
Cc: sta...@dpdk.org
Signed-off-by: Jie Hai
Signed-off-by: Dongdong Liu
---
drivers/net/hns3/hns3_cmd.h| 9 -
drivers/net/hns3/hns3_ethdev.c | 29 +
drivers/net/hns3/hns3_ethdev.h | 2 ++
3 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index a86f5116e4..fcf9bd90cb 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -789,6 +789,12 @@ struct hns3_sfp_type {
#define HNS3_FIBER_LINK_SPEED_10M_BIT BIT(7)
#define HNS3_FIBER_LINK_SPEED_200G_BIT BIT(8)
+#define HNS3_FIBER_FEC_AUTO_BITBIT(0)
+#define HNS3_FIBER_FEC_BASER_BIT BIT(1)
+#define HNS3_FIBER_FEC_RS_BIT BIT(2)
+#define HNS3_FIBER_FEC_LLRS_BITBIT(3)
+#define HNS3_FIBER_FEC_NOFEC_BIT BIT(4)
+
struct hns3_sfp_info_cmd {
uint32_t sfp_speed;
uint8_t query_type; /* 0: sfp speed, 1: active */
@@ -798,7 +804,8 @@ struct hns3_sfp_info_cmd {
uint8_t autoneg_ability;
uint32_t supported_speed; /* speed supported by current media */
uint32_t module_type;
- uint8_t rsv1[8];
+ uint8_t fec_ability; /* supported fec modes, see HNS3_FIBER_FEC_XXX_BIT
*/
+ uint8_t rsv1[7];
};
#define HNS3_MAC_CFG_FEC_AUTO_EN_B 0
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 8f998947c6..7a6c1308ac 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -4013,6 +4013,7 @@ hns3_get_sfp_info(struct hns3_hw *hw, struct hns3_mac
*mac_info)
mac_info->support_autoneg = resp->autoneg_ability;
mac_info->link_autoneg = (resp->autoneg == 0) ?
RTE_ETH_LINK_FIXED
: RTE_ETH_LINK_AUTONEG;
+ mac_info->fec_capa = resp->fec_ability;
} else {
mac_info->query_type = HNS3_DEFAULT_QUERY;
}
@@ -4095,6 +4096,7 @@ hns3_update_fiber_link_info(struct hns3_hw *hw)
mac->supported_speed = mac_info.supported_speed;
mac->support_autoneg = mac_info.support_autoneg;
mac->link_autoneg = mac_info.link_autoneg;
+ mac->fec_capa = mac_info.fec_capa;
return 0;
}
@@ -6124,11 +6126,38 @@ hns3_set_fec_hw(struct hns3_hw *hw, uint32_t mode)
return ret;
}
+static uint32_t
+hns3_parse_hw_fec_capa(uint8_t hw_fec_capa)
+{
+ const struct {
+ uint32_t hw_fec_capa;
+ uint32_t fec_capa;
+ } fec_capa_map[] = {
+ { HNS3_FIBER_FEC_AUTO_BIT, RTE_ETH_FEC_MODE_CAPA_MASK(AUTO) },
+ { HNS3_FIBER_FEC_BASER_BIT, RTE_ETH_FEC_MODE_CAPA_MASK(BASER) },
+ { HNS3_FIBER_FEC_RS_BIT, RTE_ETH_FEC_MODE_CAPA_MASK(RS) },
+ { HNS3_FIBER_FEC_LLRS_BIT, RTE_ETH_FEC_MODE_CAPA_MASK(LLRS) },
+ { HNS3_FIBER_FEC_NOFEC_BIT, RTE_ETH_FEC_MODE_CAPA_MASK(NOFEC) },
+ };
+ uint32_t capa = 0;
+ uint32_t i;
+
+ for (i = 0; i < RTE_DIM(fec_capa_map); i++) {
+ if ((hw_fec_capa & fec_capa_map[i].hw_fec_capa) != 0)
+ capa |= fec_capa_map[i].fec_capa;
+ }
+
+ return capa;
+}
+
static uint32_t
hns3_get_current_speed_fec_cap(struct hns3_mac *mac)
{
uint32_t i;
+ if (mac->fec_capa != 0)
+ return hns3_parse_hw_fec_capa(mac->fec_capa);
+
for (i = 0; i < RTE_DIM(speed_fec_capa_tbl); i++) {
if (mac->link_speed == speed_fec_capa_tbl[i].speed)
return speed_fec_capa_tbl[i].capa;
diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
index 9acc5a3d7e..ec73792d4f 100644
--- a/drivers/net/hns3/hns3_ethdev.h
+++ b/drivers/net/hns3/hns3_ethdev.h
@@ -214,6 +214,8 @@ struct hns3_mac {
uint32_t advertising; /* advertised capability in the local part */
uint32_t lp_advertising; /* advertised capability in the link partner */
uint8_t support_autoneg;
+ /* current supported fec modes. see HNS3_FIBER_FEC_XXX_BIT */
+ uint32_t fec_capa;
};
struct hns3_fake_queue_data {
--
2.22.0
[PATCH 6/7] net/hns3: add LLRS FEC mode support for 200G ports
From: Jie Hai
This patch supports the query and configuration of LLRS FEC mode.
Signed-off-by: Jie Hai
Signed-off-by: Dongdong Liu
---
drivers/net/hns3/hns3_cmd.c| 1 +
drivers/net/hns3/hns3_cmd.h| 2 ++
drivers/net/hns3/hns3_ethdev.c | 21 -
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/net/hns3/hns3_cmd.c b/drivers/net/hns3/hns3_cmd.c
index bdfc85f934..a574191ba9 100644
--- a/drivers/net/hns3/hns3_cmd.c
+++ b/drivers/net/hns3/hns3_cmd.c
@@ -637,6 +637,7 @@ hns3_firmware_compat_config(struct hns3_hw *hw, bool
is_init)
if (is_init) {
hns3_set_bit(compat, HNS3_LINK_EVENT_REPORT_EN_B, 1);
hns3_set_bit(compat, HNS3_NCSI_ERROR_REPORT_EN_B, 0);
+ hns3_set_bit(compat, HNS3_LLRS_FEC_EN_B, 1);
if (hns3_dev_get_support(hw, COPPER))
hns3_set_bit(compat, HNS3_FIRMWARE_PHY_DRIVER_EN_B, 1);
}
diff --git a/drivers/net/hns3/hns3_cmd.h b/drivers/net/hns3/hns3_cmd.h
index eb394c9dec..a86f5116e4 100644
--- a/drivers/net/hns3/hns3_cmd.h
+++ b/drivers/net/hns3/hns3_cmd.h
@@ -665,6 +665,7 @@ enum hns3_promisc_type {
#define HNS3_LINK_EVENT_REPORT_EN_B0
#define HNS3_NCSI_ERROR_REPORT_EN_B1
#define HNS3_FIRMWARE_PHY_DRIVER_EN_B 2
+#define HNS3_LLRS_FEC_EN_B 5
struct hns3_firmware_compat_cmd {
uint32_t compat;
uint8_t rsv[20];
@@ -806,6 +807,7 @@ struct hns3_sfp_info_cmd {
#define HNS3_MAC_FEC_OFF 0
#define HNS3_MAC_FEC_BASER 1
#define HNS3_MAC_FEC_RS2
+#define HNS3_MAC_FEC_LLRS 3
/* Configure FEC mode, opcode:0x031A */
struct hns3_config_fec_cmd {
diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 80cdcc83bf..8f998947c6 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -47,11 +47,6 @@
#define HNS3_RESET_WAIT_MS 100
#define HNS3_RESET_WAIT_CNT200
-/* FEC mode order defined in HNS3 hardware */
-#define HNS3_HW_FEC_MODE_NOFEC 0
-#define HNS3_HW_FEC_MODE_BASER 1
-#define HNS3_HW_FEC_MODE_RS 2
-
enum hns3_evt_cause {
HNS3_VECTOR0_EVENT_RST,
HNS3_VECTOR0_EVENT_MBX,
@@ -91,7 +86,8 @@ static const struct rte_eth_fec_capa speed_fec_capa_tbl[] = {
RTE_ETH_FEC_MODE_CAPA_MASK(RS) },
{ RTE_ETH_SPEED_NUM_200G, RTE_ETH_FEC_MODE_CAPA_MASK(AUTO) |
- RTE_ETH_FEC_MODE_CAPA_MASK(RS) }
+ RTE_ETH_FEC_MODE_CAPA_MASK(RS) |
+ RTE_ETH_FEC_MODE_CAPA_MASK(LLRS) }
};
static enum hns3_reset_level hns3_get_reset_level(struct hns3_adapter *hns,
@@ -6059,15 +6055,18 @@ hns3_fec_get_internal(struct hns3_hw *hw, uint32_t
*fec_capa)
* to be converted.
*/
switch (resp->active_fec) {
- case HNS3_HW_FEC_MODE_NOFEC:
+ case HNS3_MAC_FEC_OFF:
tmp_fec_capa = RTE_ETH_FEC_MODE_CAPA_MASK(NOFEC);
break;
- case HNS3_HW_FEC_MODE_BASER:
+ case HNS3_MAC_FEC_BASER:
tmp_fec_capa = RTE_ETH_FEC_MODE_CAPA_MASK(BASER);
break;
- case HNS3_HW_FEC_MODE_RS:
+ case HNS3_MAC_FEC_RS:
tmp_fec_capa = RTE_ETH_FEC_MODE_CAPA_MASK(RS);
break;
+ case HNS3_MAC_FEC_LLRS:
+ tmp_fec_capa = RTE_ETH_FEC_MODE_CAPA_MASK(LLRS);
+ break;
default:
tmp_fec_capa = RTE_ETH_FEC_MODE_CAPA_MASK(NOFEC);
break;
@@ -6108,6 +6107,10 @@ hns3_set_fec_hw(struct hns3_hw *hw, uint32_t mode)
hns3_set_field(req->fec_mode, HNS3_MAC_CFG_FEC_MODE_M,
HNS3_MAC_CFG_FEC_MODE_S, HNS3_MAC_FEC_RS);
break;
+ case RTE_ETH_FEC_MODE_CAPA_MASK(LLRS):
+ hns3_set_field(req->fec_mode, HNS3_MAC_CFG_FEC_MODE_M,
+ HNS3_MAC_CFG_FEC_MODE_S, HNS3_MAC_FEC_LLRS);
+ break;
case RTE_ETH_FEC_MODE_CAPA_MASK(AUTO):
hns3_set_bit(req->fec_mode, HNS3_MAC_CFG_FEC_AUTO_EN_B, 1);
break;
--
2.22.0
