[dpdk-dev] [PATCH v3 0/4] add Rx buffer size for rxq info structure
In common practice, PMD configure the Rx buffer size which indicate the buffer length could be used for HW in receiving packets according to the data room size of the object in mempool. But in fact, the final value is related to the specifications of HW, and its values will affect the number of fragments in receiving packets when scatter is enabled. By the way, some PMDs may force to enable scatter when the MTU is bigger than the HW Rx buffer size. At present, we have no way to expose relevant information to upper layer users. So, add a field named rx_buf_size in rte_eth_rxq_info to indicate the buffer size used in receiving packets for HW. And this field is optional, so there is no need to forcibly update all PMDs. This patchset also update testpmd, proc-info tools and add hns3 PMD implementation. Chengchang Tang (4): ethdev: add a field for rxq info structure app/testpmd: add Rx buffer size display in queue info query app/procinfo: add Rx buffer size to --show-port net/hns3: add Rx buffer size to Rx qinfo query app/proc-info/main.c | 2 ++ app/test-pmd/config.c | 1 + drivers/net/hns3/hns3_rxtx.c | 2 ++ lib/librte_ethdev/rte_ethdev.h | 2 ++ 4 files changed, 7 insertions(+) -- 2.7.4
[dpdk-dev] [PATCH v3 2/4] app/testpmd: add Rx buffer size display in queue info query
Add Rx buffer size to queue info querry cmd so that the user can get the
buffer length used by HW queue for receiving packets.
Signed-off-by: Chengchang Tang
Reviewed-by: Wei Hu (Xavier)
---
app/test-pmd/config.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 30bee33..b432ac6 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -452,6 +452,7 @@ rx_queue_infos_display(portid_t port_id, uint16_t queue_id)
(qinfo.conf.rx_deferred_start != 0) ? "on" : "off");
printf("\nRX scattered packets: %s",
(qinfo.scattered_rx != 0) ? "on" : "off");
+ printf("\nRX buffer size: %hu", qinfo.rx_buf_size);
printf("\nNumber of RXDs: %hu", qinfo.nb_desc);
if (rte_eth_rx_burst_mode_get(port_id, queue_id, &mode) == 0)
--
2.7.4
[dpdk-dev] [PATCH v3 1/4] ethdev: add a field for rxq info structure
Add a field named rx_buf_size in rte_eth_rxq_info to indicate the buffer
size used in receiving packets for HW.
In this way, upper-layer users can get this information by calling
rte_eth_rx_queue_info_get.
Signed-off-by: Chengchang Tang
Reviewed-by: Wei Hu (Xavier)
Acked-by: Andrew Rybchenko
---
lib/librte_ethdev/rte_ethdev.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 70295d7..9fed5cb 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -1420,6 +1420,8 @@ struct rte_eth_rxq_info {
struct rte_eth_rxconf conf; /**< queue config parameters. */
uint8_t scattered_rx; /**< scattered packets RX supported. */
uint16_t nb_desc; /**< configured number of RXDs. */
+ /**< buffer size used for hardware when receive packets. */
+ uint16_t rx_buf_size;
} __rte_cache_min_aligned;
/**
--
2.7.4
[dpdk-dev] [PATCH v3 3/4] app/procinfo: add Rx buffer size to --show-port
Add Rx buffer size to show_port function to display it in the port PMD
information so that the user can get the buffer length used by HW queue
of receiving packets.
Signed-off-by: Chengchang Tang
---
app/proc-info/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/app/proc-info/main.c b/app/proc-info/main.c
index abeca4a..e840dea 100644
--- a/app/proc-info/main.c
+++ b/app/proc-info/main.c
@@ -711,11 +711,13 @@ show_port(void)
if (ret == 0) {
printf("\t -- queue %d rx scatter %d"
" descriptors %d"
+ " rx buffer size %d"
" offloads 0x%"PRIx64
" mempool socket %d\n",
j,
queue_info.scattered_rx,
queue_info.nb_desc,
+ queue_info.rx_buf_size,
queue_info.conf.offloads,
queue_info.mp->socket_id);
}
--
2.7.4
[dpdk-dev] [PATCH v3 4/4] net/hns3: add Rx buffer size to Rx qinfo query
Report hns3 PMD configured Rx buffer size in Rx queue information query. Signed-off-by: Chengchang Tang Reviewed-by: Wei Hu (Xavier) --- drivers/net/hns3/hns3_rxtx.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/hns3/hns3_rxtx.c b/drivers/net/hns3/hns3_rxtx.c index fc1a256..d67c5ad 100644 --- a/drivers/net/hns3/hns3_rxtx.c +++ b/drivers/net/hns3/hns3_rxtx.c @@ -2830,6 +2830,8 @@ hns3_rxq_info_get(struct rte_eth_dev *dev, uint16_t queue_id, qinfo->mp = rxq->mb_pool; qinfo->nb_desc = rxq->nb_rx_desc; qinfo->scattered_rx = dev->data->scattered_rx; + /* Report the HW Rx buffer length to user */ + qinfo->rx_buf_size = rxq->rx_buf_len; /* * If there are no available Rx buffer descriptors, incoming packets -- 2.7.4
[dpdk-dev] i40e_rxtx_vec_avx2 code review
Jeff, Beilei, Looking closer at i40e_rxtx_vec_avx2.c, I noticed: 1. i40e_rxq_rearm() uses RTE_I40E_DESCS_PER_LOOP, while all other functions in the file use RTE_I40E_DESCS_PER_LOOP_AVX. It may be correct, but please check. 2. The function descriptions of i40e_recv_pkts_vec_avx2(), i40e_recv_scattered_burst_vec_avx2() and i40e_recv_scattered_pkts_vec_avx2() refer to RTE_I40E_DESCS_PER_LOOP, but they should be referring to RTE_I40E_DESCS_PER_LOOP_AVX. 3. RTE_I40E_DESCS_PER_LOOP_AVX is defined in the file, unlike RTE_I40E_DESCS_PER_LOOP, which is defined in the i40e_rxtx.h header file. Your choice, just mentioning it. Med venlig hilsen / kind regards - Morten Brørup
Re: [dpdk-dev] [PATCH v3 01/11] drivers/baseband: add PMD for ACC100
Hi, > -Original Message- > From: dev On Behalf Of Nicolas Chautru > Sent: Wednesday, August 19, 2020 8:25 > To: dev@dpdk.org; akhil.go...@nxp.com > Cc: Richardson, Bruce ; Chautru, Nicolas > > Subject: [dpdk-dev] [PATCH v3 01/11] drivers/baseband: add PMD for > ACC100 > > Add stubs for the ACC100 PMD > > Signed-off-by: Nicolas Chautru > --- > config/common_base | 4 + > doc/guides/bbdevs/acc100.rst | 233 > + > doc/guides/bbdevs/index.rst| 1 + > doc/guides/rel_notes/release_20_11.rst | 6 + > drivers/baseband/Makefile | 2 + > drivers/baseband/acc100/Makefile | 25 +++ > drivers/baseband/acc100/meson.build| 6 + > drivers/baseband/acc100/rte_acc100_pmd.c | 175 > drivers/baseband/acc100/rte_acc100_pmd.h | 37 > .../acc100/rte_pmd_bbdev_acc100_version.map| 3 + > drivers/baseband/meson.build | 2 +- > mk/rte.app.mk | 1 + > 12 files changed, 494 insertions(+), 1 deletion(-) create mode 100644 > doc/guides/bbdevs/acc100.rst create mode 100644 > drivers/baseband/acc100/Makefile create mode 100644 > drivers/baseband/acc100/meson.build > create mode 100644 drivers/baseband/acc100/rte_acc100_pmd.c > create mode 100644 drivers/baseband/acc100/rte_acc100_pmd.h > create mode 100644 > drivers/baseband/acc100/rte_pmd_bbdev_acc100_version.map > > diff --git a/config/common_base b/config/common_base index > fbf0ee7..218ab16 100644 > --- a/config/common_base > +++ b/config/common_base > @@ -584,6 +584,10 @@ CONFIG_RTE_LIBRTE_PMD_BBDEV_NULL=y > # > CONFIG_RTE_LIBRTE_PMD_BBDEV_TURBO_SW=y > > +# Compile PMD for ACC100 bbdev device > +# > +CONFIG_RTE_LIBRTE_PMD_BBDEV_ACC100=y > + > # > # Compile PMD for Intel FPGA LTE FEC bbdev device # diff --git > a/doc/guides/bbdevs/acc100.rst b/doc/guides/bbdevs/acc100.rst new file > mode 100644 index 000..f87ee09 > --- /dev/null > +++ b/doc/guides/bbdevs/acc100.rst > @@ -0,0 +1,233 @@ > +.. SPDX-License-Identifier: BSD-3-Clause > +Copyright(c) 2020 Intel Corporation > + > +Intel(R) ACC100 5G/4G FEC Poll Mode Driver > +== > + > +The BBDEV ACC100 5G/4G FEC poll mode driver (PMD) supports an > +implementation of a VRAN FEC wireless acceleration function. > +This device is also known as Mount Bryce. > + > +Features > + > + > +ACC100 5G/4G FEC PMD supports the following features: > + > +- LDPC Encode in the DL (5GNR) > +- LDPC Decode in the UL (5GNR) > +- Turbo Encode in the DL (4G) > +- Turbo Decode in the UL (4G) > +- 16 VFs per PF (physical device) > +- Maximum of 128 queues per VF > +- PCIe Gen-3 x16 Interface > +- MSI > +- SR-IOV > + > +ACC100 5G/4G FEC PMD supports the following BBDEV capabilities: > + > +* For the LDPC encode operation: > + - ``RTE_BBDEV_LDPC_CRC_24B_ATTACH`` : set to attach CRC24B to CB(s) > + - ``RTE_BBDEV_LDPC_RATE_MATCH`` : if set then do not do Rate Match > bypass > + - ``RTE_BBDEV_LDPC_INTERLEAVER_BYPASS`` : if set then bypass > +interleaver > + > +* For the LDPC decode operation: > + - ``RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK`` : check CRC24B from CB(s) > + - ``RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE`` : disable early > termination > + - ``RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP`` : drops CRC24B bits > appended while decoding > + - ``RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE`` : provides an input for > HARQ combining > + - ``RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE`` : provides an input > for HARQ combining > + - ``RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE`` : HARQ > memory input is internal > + - ``RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE`` : HARQ > memory output is internal > + - ``RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_LOOPBACK`` : > loopback data to/from HARQ memory > + - ``RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_FILLERS`` : HARQ > memory includes the fillers bits > + - ``RTE_BBDEV_LDPC_DEC_SCATTER_GATHER`` : supports scatter-gather > for input/output data > + - ``RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION`` : supports > compression of the HARQ input/output > + - ``RTE_BBDEV_LDPC_LLR_COMPRESSION`` : supports LLR input > +compression > + > +* For the turbo encode operation: > + - ``RTE_BBDEV_TURBO_CRC_24B_ATTACH`` : set to attach CRC24B to CB(s) > + - ``RTE_BBDEV_TURBO_RATE_MATCH`` : if set then do not do Rate Match > bypass > + - ``RTE_BBDEV_TURBO_ENC_INTERRUPTS`` : set for encoder dequeue > interrupts > + - ``RTE_BBDEV_TURBO_RV_INDEX_BYPASS`` : set to bypass RV index > + - ``RTE_BBDEV_TURBO_ENC_SCATTER_GATHER`` : supports scatter- > gather > +for input/output data > + > +* For the turbo decode operation: > + - ``RTE_BBDEV_TURBO_CRC_TYPE_24B`` : check CRC24B from CB(s) > + - ``RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE`` : perform subblock > de-inter
Re: [dpdk-dev] [PATCH v3 02/11] baseband/acc100: add register definition file
Hi,
> -Original Message-
> From: dev On Behalf Of Nicolas Chautru
> Sent: Wednesday, August 19, 2020 8:25
> To: dev@dpdk.org; akhil.go...@nxp.com
> Cc: Richardson, Bruce ; Chautru, Nicolas
>
> Subject: [dpdk-dev] [PATCH v3 02/11] baseband/acc100: add register
> definition file
>
> Add in the list of registers for the device and related
> HW specs definitions.
>
> Signed-off-by: Nicolas Chautru
> ---
> drivers/baseband/acc100/acc100_pf_enum.h | 1068
> ++
> drivers/baseband/acc100/acc100_vf_enum.h | 73 ++
> drivers/baseband/acc100/rte_acc100_pmd.h | 490 ++
> 3 files changed, 1631 insertions(+)
> create mode 100644 drivers/baseband/acc100/acc100_pf_enum.h
> create mode 100644 drivers/baseband/acc100/acc100_vf_enum.h
>
> diff --git a/drivers/baseband/acc100/acc100_pf_enum.h
> b/drivers/baseband/acc100/acc100_pf_enum.h
> new file mode 100644
> index 000..a1ee416
> --- /dev/null
> +++ b/drivers/baseband/acc100/acc100_pf_enum.h
> @@ -0,0 +1,1068 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2017 Intel Corporation
> + */
> +
> +#ifndef ACC100_PF_ENUM_H
> +#define ACC100_PF_ENUM_H
> +
> +/*
> + * ACC100 Register mapping on PF BAR0
> + * This is automatically generated from RDL, format may change with new
> RDL
> + * Release.
> + * Variable names are as is
> + */
> +enum {
> + HWPfQmgrEgressQueuesTemplate = 0x0007FE00,
> + HWPfQmgrIngressAq = 0x0008,
> + HWPfQmgrArbQAvail = 0x00A00010,
> + HWPfQmgrArbQBlock = 0x00A00014,
> + HWPfQmgrAqueueDropNotifEn = 0x00A00024,
> + HWPfQmgrAqueueDisableNotifEn = 0x00A00028,
> + HWPfQmgrSoftReset = 0x00A00038,
> + HWPfQmgrInitStatus= 0x00A0003C,
> + HWPfQmgrAramWatchdogCount = 0x00A00040,
> + HWPfQmgrAramWatchdogCounterEn = 0x00A00044,
> + HWPfQmgrAxiWatchdogCount = 0x00A00048,
> + HWPfQmgrAxiWatchdogCounterEn = 0x00A0004C,
> + HWPfQmgrProcessWatchdogCount = 0x00A00050,
> + HWPfQmgrProcessWatchdogCounterEn = 0x00A00054,
> + HWPfQmgrProcessUl4GWatchdogCounter= 0x00A00058,
> + HWPfQmgrProcessDl4GWatchdogCounter= 0x00A0005C,
> + HWPfQmgrProcessUl5GWatchdogCounter= 0x00A00060,
> + HWPfQmgrProcessDl5GWatchdogCounter= 0x00A00064,
> + HWPfQmgrProcessMldWatchdogCounter = 0x00A00068,
> + HWPfQmgrMsiOverflowUpperVf= 0x00A00070,
> + HWPfQmgrMsiOverflowLowerVf= 0x00A00074,
> + HWPfQmgrMsiWatchdogOverflow = 0x00A00078,
> + HWPfQmgrMsiOverflowEnable = 0x00A0007C,
> + HWPfQmgrDebugAqPointerMemGrp = 0x00A00100,
> + HWPfQmgrDebugOutputArbQFifoGrp= 0x00A00140,
> + HWPfQmgrDebugMsiFifoGrp = 0x00A00180,
> + HWPfQmgrDebugAxiWdTimeoutMsiFifo = 0x00A001C0,
> + HWPfQmgrDebugProcessWdTimeoutMsiFifo = 0x00A001C4,
> + HWPfQmgrDepthLog2Grp = 0x00A00200,
> + HWPfQmgrTholdGrp = 0x00A00300,
> + HWPfQmgrGrpTmplateReg0Indx= 0x00A00600,
> + HWPfQmgrGrpTmplateReg1Indx= 0x00A00680,
> + HWPfQmgrGrpTmplateReg2indx= 0x00A00700,
> + HWPfQmgrGrpTmplateReg3Indx= 0x00A00780,
> + HWPfQmgrGrpTmplateReg4Indx= 0x00A00800,
> + HWPfQmgrVfBaseAddr= 0x00A01000,
> + HWPfQmgrUl4GWeightRrVf= 0x00A02000,
> + HWPfQmgrDl4GWeightRrVf= 0x00A02100,
> + HWPfQmgrUl5GWeightRrVf= 0x00A02200,
> + HWPfQmgrDl5GWeightRrVf= 0x00A02300,
> + HWPfQmgrMldWeightRrVf = 0x00A02400,
> + HWPfQmgrArbQDepthGrp = 0x00A02F00,
> + HWPfQmgrGrpFunction0 = 0x00A02F40,
> + HWPfQmgrGrpFunction1 = 0x00A02F44,
> + HWPfQmgrGrpPriority = 0x00A02F48,
> + HWPfQmgrWeightSync= 0x00A03000,
> + HWPfQmgrAqEnableVf= 0x00A1,
> + HWPfQmgrAqResetVf = 0x00A2,
> + HWPfQmgrRingSizeVf= 0x00A20004,
> + HWPfQmgrGrpDepthLog20Vf = 0x00A20008,
> + HWPfQmgrGrpDepthLog21Vf = 0x00A2000C,
> + HWPfQmgrGrpFunction0Vf= 0x00A20010,
> + HWPfQmgrGrpFunction1Vf= 0x00A20014,
> + HWPfDmaConfig0Reg = 0x00B8,
> + HWPfDmaConfig1Reg = 0x00B80004,
> + HWPfDmaQmgrAddrReg= 0x00B80008,
> + HWPfDmaSoftResetReg = 0x00B8000C,
> + HWPfDmaAxcacheReg = 0x00B80010,
> + HWPfDmaVersionReg = 0x00B80014,
> + HWPfDmaFrameThreshol
Re: [dpdk-dev] [RFC] ethdev: rte_eth_rx_burst() requirements fornb_pkts
> From: Morten Brørup > Sent: Friday, August 28, 2020 12:51 PM > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bruce Richardson > > Sent: Friday, August 28, 2020 12:07 PM > > > > On Fri, Aug 28, 2020 at 11:03:59AM +0200, Morten Brørup wrote: > > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bruce > > Richardson > > > > > > > > > > > > > > Right. For now then, it seems like just documenting a minimum burst > > > > size is > > > > reasonable. > > > > > > I agree. It is so far from the spirit of DPDK to call > > rte_eth_rx_burst() with a small nb_pkts that the driver developers > > didn't even consider it. The API documentation needs fixing, not the > > drivers. > > > > > > It doesn't take care of your example 4 packet latency sensitive > > application, though. Which BTW also doesn’t work today on drivers with > > vector support. So it might not be a real world scenario anyway. :-) > > > > > AFAIK, 8 is the smallest burst guaranteed to work everywhere, but I > > think > > just about everything bar the AVX2 i40e code path also supports 4 as a > > burst size. Therefore adjusting to 4 as min-burst might well be > > reasonable. > > > > /Bruce > > There must be a reason the i40e AVX2 driver chose to step up to 8 from the > previous convention of 4. > > Considering Intel's stance on the controversial vector instructions, a > larger numbers seems more future proof. HPC benefits from the vector > instructions, and DPDK seems to benefit from them too. Let's not prevent > that. > > Since I don't have insight into Intel's (or any other CPU vendors') plans > for future vector instructions, I will assume that 8 suffices for the > foreseeable future, and thus I am leaning towards 8 rather than 4. > nb_pkts must be >= 8 and divisible by 8. Alternatively to being divisible by 8, would there be any benefit in requiring that it is a power-of-two? -Morten
Re: [dpdk-dev] [PATCH v3 04/11] baseband/acc100: add queue configuration
Hi,
> -Original Message-
> From: dev On Behalf Of Nicolas Chautru
> Sent: Wednesday, August 19, 2020 8:25
> To: dev@dpdk.org; akhil.go...@nxp.com
> Cc: Richardson, Bruce ; Chautru, Nicolas
>
> Subject: [dpdk-dev] [PATCH v3 04/11] baseband/acc100: add queue
> configuration
>
> Adding function to create and configure queues for the device. Still no
> capability.
>
> Signed-off-by: Nicolas Chautru
> ---
> drivers/baseband/acc100/rte_acc100_pmd.c | 420
> ++-
> drivers/baseband/acc100/rte_acc100_pmd.h | 45
> 2 files changed, 464 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> b/drivers/baseband/acc100/rte_acc100_pmd.c
> index 7807a30..7a21c57 100644
> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> @@ -26,6 +26,22 @@
> RTE_LOG_REGISTER(acc100_logtype, pmd.bb.acc100, NOTICE); #endif
>
> +/* Write to MMIO register address */
> +static inline void
> +mmio_write(void *addr, uint32_t value)
> +{
> + *((volatile uint32_t *)(addr)) = rte_cpu_to_le_32(value); }
> +
> +/* Write a register of a ACC100 device */ static inline void
> +acc100_reg_write(struct acc100_device *d, uint32_t offset, uint32_t
> +payload) {
> + void *reg_addr = RTE_PTR_ADD(d->mmio_base, offset);
> + mmio_write(reg_addr, payload);
> + usleep(1000);
> +}
> +
> /* Read a register of a ACC100 device */ static inline uint32_t
> acc100_reg_read(struct acc100_device *d, uint32_t offset) @@ -36,6 +52,22
> @@
> return rte_le_to_cpu_32(ret);
> }
>
> +/* Basic Implementation of Log2 for exact 2^N */ static inline uint32_t
> +log2_basic(uint32_t value) {
> + return (value == 0) ? 0 : __builtin_ctz(value); }
> +
> +/* Calculate memory alignment offset assuming alignment is 2^N */
> +static inline uint32_t calc_mem_alignment_offset(void
> +*unaligned_virt_mem, uint32_t alignment) {
> + rte_iova_t unaligned_phy_mem =
> rte_malloc_virt2iova(unaligned_virt_mem);
> + return (uint32_t)(alignment -
> + (unaligned_phy_mem & (alignment-1))); }
> +
> /* Calculate the offset of the enqueue register */ static inline uint32_t
> queue_offset(bool pf_device, uint8_t vf_id, uint8_t qgrp_id, uint16_t aq_id)
> @@ -204,10 +236,393 @@
> acc100_conf->q_dl_5g.aq_depth_log2);
> }
>
> +static void
> +free_base_addresses(void **base_addrs, int size) {
> + int i;
> + for (i = 0; i < size; i++)
> + rte_free(base_addrs[i]);
> +}
> +
> +static inline uint32_t
> +get_desc_len(void)
> +{
> + return sizeof(union acc100_dma_desc);
> +}
> +
> +/* Allocate the 2 * 64MB block for the sw rings */ static int
> +alloc_2x64mb_sw_rings_mem(struct rte_bbdev *dev, struct acc100_device
> *d,
> + int socket)
> +{
> + uint32_t sw_ring_size = ACC100_SIZE_64MBYTE;
> + d->sw_rings_base = rte_zmalloc_socket(dev->device->driver-
> >name,
> + 2 * sw_ring_size, RTE_CACHE_LINE_SIZE, socket);
> + if (d->sw_rings_base == NULL) {
> + rte_bbdev_log(ERR, "Failed to allocate memory for %s:%u",
> + dev->device->driver->name,
> + dev->data->dev_id);
> + return -ENOMEM;
> + }
> + memset(d->sw_rings_base, 0, ACC100_SIZE_64MBYTE);
> + uint32_t next_64mb_align_offset = calc_mem_alignment_offset(
> + d->sw_rings_base, ACC100_SIZE_64MBYTE);
> + d->sw_rings = RTE_PTR_ADD(d->sw_rings_base,
> next_64mb_align_offset);
> + d->sw_rings_phys = rte_malloc_virt2iova(d->sw_rings_base) +
> + next_64mb_align_offset;
> + d->sw_ring_size = MAX_QUEUE_DEPTH * get_desc_len();
> + d->sw_ring_max_depth = d->sw_ring_size / get_desc_len();
> +
> + return 0;
> +}
Why not a common alloc memory function but special function for different
memory size?
> +/* Attempt to allocate minimised memory space for sw rings */ static
> +void alloc_sw_rings_min_mem(struct rte_bbdev *dev, struct
> acc100_device
> +*d,
> + uint16_t num_queues, int socket)
> +{
> + rte_iova_t sw_rings_base_phy, next_64mb_align_addr_phy;
> + uint32_t next_64mb_align_offset;
> + rte_iova_t sw_ring_phys_end_addr;
> + void *base_addrs[SW_RING_MEM_ALLOC_ATTEMPTS];
> + void *sw_rings_base;
> + int i = 0;
> + uint32_t q_sw_ring_size = MAX_QUEUE_DEPTH * get_desc_len();
> + uint32_t dev_sw_ring_size = q_sw_ring_size * num_queues;
> +
> + /* Find an aligned block of memory to store sw rings */
> + while (i < SW_RING_MEM_ALLOC_ATTEMPTS) {
> + /*
> + * sw_ring allocated memory is guaranteed to be aligned to
> + * q_sw_ring_size at the condition that the requested size is
> + * less than the page size
> + */
> + sw_rings_base = rte_zmalloc_socket(
> + dev->device->driver->name,
> +
Re: [dpdk-dev] [PATCH v3 05/11] baseband/acc100: add LDPC processing functions
Hi,
> -Original Message-
> From: dev On Behalf Of Nicolas Chautru
> Sent: Wednesday, August 19, 2020 8:25
> To: dev@dpdk.org; akhil.go...@nxp.com
> Cc: Richardson, Bruce ; Chautru, Nicolas
>
> Subject: [dpdk-dev] [PATCH v3 05/11] baseband/acc100: add LDPC
> processing functions
>
> Adding LDPC decode and encode processing operations
>
> Signed-off-by: Nicolas Chautru
> ---
> drivers/baseband/acc100/rte_acc100_pmd.c | 1625
> +-
> drivers/baseband/acc100/rte_acc100_pmd.h |3 +
> 2 files changed, 1626 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> b/drivers/baseband/acc100/rte_acc100_pmd.c
> index 7a21c57..5f32813 100644
> --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> @@ -15,6 +15,9 @@
> #include
> #include
> #include
> +#ifdef RTE_BBDEV_OFFLOAD_COST
> +#include
> +#endif
>
> #include
> #include
> @@ -449,7 +452,6 @@
> return 0;
> }
>
> -
> /**
> * Report a ACC100 queue index which is free
> * Return 0 to 16k for a valid queue_idx or -1 when no queue is available
> @@ -634,6 +636,46 @@
> struct acc100_device *d = dev->data->dev_private;
>
> static const struct rte_bbdev_op_cap bbdev_capabilities[] = {
> + {
> + .type = RTE_BBDEV_OP_LDPC_ENC,
> + .cap.ldpc_enc = {
> + .capability_flags =
> + RTE_BBDEV_LDPC_RATE_MATCH |
> + RTE_BBDEV_LDPC_CRC_24B_ATTACH
> |
> +
> RTE_BBDEV_LDPC_INTERLEAVER_BYPASS,
> + .num_buffers_src =
> +
> RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> + .num_buffers_dst =
> +
> RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> + }
> + },
> + {
> + .type = RTE_BBDEV_OP_LDPC_DEC,
> + .cap.ldpc_dec = {
> + .capability_flags =
> + RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK |
> + RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP |
> +
> RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE |
> +
> RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE |
> +#ifdef ACC100_EXT_MEM
> +
> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE |
> +
> RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE |
> +#endif
> +
> RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE |
> + RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS
> |
> + RTE_BBDEV_LDPC_DECODE_BYPASS |
> + RTE_BBDEV_LDPC_DEC_SCATTER_GATHER |
> +
> RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION |
> + RTE_BBDEV_LDPC_LLR_COMPRESSION,
> + .llr_size = 8,
> + .llr_decimals = 1,
> + .num_buffers_src =
> +
> RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> + .num_buffers_hard_out =
> +
> RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> + .num_buffers_soft_out = 0,
> + }
> + },
> RTE_BBDEV_END_OF_CAPABILITIES_LIST()
> };
>
> @@ -669,9 +711,14 @@
> dev_info->cpu_flag_reqs = NULL;
> dev_info->min_alignment = 64;
> dev_info->capabilities = bbdev_capabilities;
> +#ifdef ACC100_EXT_MEM
> dev_info->harq_buffer_size = d->ddr_size;
> +#else
> + dev_info->harq_buffer_size = 0;
> +#endif
> }
>
> +
> static const struct rte_bbdev_ops acc100_bbdev_ops = {
> .setup_queues = acc100_setup_queues,
> .close = acc100_dev_close,
> @@ -696,6 +743,1577 @@
> {.device_id = 0},
> };
>
> +/* Read flag value 0/1 from bitmap */
> +static inline bool
> +check_bit(uint32_t bitmap, uint32_t bitmask)
> +{
> + return bitmap & bitmask;
> +}
> +
> +static inline char *
> +mbuf_append(struct rte_mbuf *m_head, struct rte_mbuf *m, uint16_t len)
> +{
> + if (unlikely(len > rte_pktmbuf_tailroom(m)))
> + return NULL;
> +
> + char *tail = (char *)m->buf_addr + m->data_off + m->data_len;
> + m->data_len = (uint16_t)(m->data_len + len);
> + m_head->pkt_len = (m_head->pkt_len + len);
> + return tail;
> +}
Is it reasonable to direct add data_len of rte_mbuf?
> +/* Compute value of k0.
> + * Based on 3GPP 38.212 Table 5.4.2.1-2
> + * Starting position of different redundancy versions, k0
> + */
> +static inline uint16_t
> +get_k0(uint16_t n_cb, uint16_t z_c, uint8_t bg, uint8_t rv_index)
> +{
> + if (rv_index == 0)
> + return 0;
> + uint16_t n = (bg == 1 ? N_ZC_1 : N_ZC_2) * z_c;
> + if (n_cb == n) {
> + if (rv_index == 1)
> + return (bg == 1 ? K0_1_1 : K0_1_2) * z_c;
> + else if (rv_index == 2)
> + return (bg == 1 ? K0_2_1 : K0_2_2) * z_c;
> + else
> + return (bg == 1 ? K0_3_1 : K0_3_2) *
Re: [dpdk-dev] [PATCH] net/virtio: fix wrong variable assignment in helper macro
On 8/14/20 12:21 PM, Vipul Ashri wrote:
> Inside Macro ASSIGN_UNLESS_EQUAL(var, val), assignment to var is always
> failing as assignment done using var_ having local scope only.
> This leads to TX packets not going out and found broken due to cleanup
> malfunctioning. This patch fixes the wrong variable assignment.
>
> Fixes: 57f90f894588 ("net/virtio: reuse packed ring functions")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Vipul Ashri
> ---
> drivers/net/virtio/virtqueue.h | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
> index 105a9c00c..20c95471e 100644
> --- a/drivers/net/virtio/virtqueue.h
> +++ b/drivers/net/virtio/virtqueue.h
> @@ -607,10 +607,8 @@ virtqueue_notify(struct virtqueue *vq)
>
> /* avoid write operation when necessary, to lessen cache issues */
> #define ASSIGN_UNLESS_EQUAL(var, val) do { \
> - typeof(var) var_ = (var); \
> - typeof(val) val_ = (val); \
> - if ((var_) != (val_)) \
> - (var_) = (val_);\
> + if ((var) != (val)) \
> + (var) = (val); \
Good catch. As I understand the old code tries to avoid
processing of var and val expressions twice. It looks it
could be kept for val at least. Just keep if condition as in
old code and fix the last line above:
(var) = val_;
Since var_ and val_are local variables there is no necessity
to enclose it in parenthesis (but does not harm if done).
var_ may be really removed since since resulting code will
use it only once.
Re: [dpdk-dev] [PATCH v2] mempool: enhance dump function to print ops name
On 8/17/20 2:15 PM, Hemant Agrawal wrote:
> Enhance the dump function to also print the ops index
> and associated mempool ops name
>
> Signed-off-by: Hemant Agrawal
Acked-by: Andrew Rybchenko
with a nit below
> ---
> lib/librte_mempool/rte_mempool.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/lib/librte_mempool/rte_mempool.c
> b/lib/librte_mempool/rte_mempool.c
> index 7774f0c8da..10c5cb708f 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -1266,6 +1266,7 @@ rte_mempool_dump(FILE *f, struct rte_mempool *mp)
> unsigned lcore_id;
> #endif
> struct rte_mempool_memhdr *memhdr;
> + struct rte_mempool_ops *ops;
> unsigned common_count;
> unsigned cache_count;
> size_t mem_len = 0;
> @@ -1288,6 +1289,10 @@ rte_mempool_dump(FILE *f, struct rte_mempool *mp)
>
> fprintf(f, " private_data_size=%"PRIu32"\n", mp->private_data_size);
>
> + fprintf(f, " ops_index=%d\n", mp->ops_index);
> + ops = rte_mempool_get_ops(mp->ops_index);
> + fprintf(f, " ops_name: <%s>\n", ops ? ops->name : "NA");
DPDK coding style suggests to use explicit comparison vs NULL, i.e.
ops != NULL ? ops->name : "NA"
> +
> STAILQ_FOREACH(memhdr, &mp->mem_list, next)
> mem_len += memhdr->len;
> if (mem_len != 0) {
Re: [dpdk-dev] [PATCH] net: calculate checksums for packets with IPv4 options
On 8/21/20 2:32 PM, Michael Pfeiffer wrote:
> Currently, rte_ipv4_cksum() and rte_ipv4_udptcp_cksum() assume all IPv4
> headers have sizeof(struct rte_ipv4_hdr) bytes. This is not true for
> those (rare) packets with IPv4 options. Thus, both IPv4 and TCP/UDP
> checksums are calculated wrong.
>
> This patch fixes the issue by using the actual IPv4 header length from
> the packet's IHL field.
>
> Signed-off-by: Michael Pfeiffer
> ---
> lib/librte_net/rte_ip.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/lib/librte_net/rte_ip.h b/lib/librte_net/rte_ip.h
> index fcd1eb342..6c3ff2603 100644
> --- a/lib/librte_net/rte_ip.h
> +++ b/lib/librte_net/rte_ip.h
> @@ -269,7 +269,7 @@ static inline uint16_t
> rte_ipv4_cksum(const struct rte_ipv4_hdr *ipv4_hdr)
> {
> uint16_t cksum;
> - cksum = rte_raw_cksum(ipv4_hdr, sizeof(struct rte_ipv4_hdr));
> + cksum = rte_raw_cksum(ipv4_hdr, (ipv4_hdr->version_ihl & 0xf) * 4);
> return (uint16_t)~cksum;
> }
>
> @@ -311,7 +311,7 @@ rte_ipv4_phdr_cksum(const struct rte_ipv4_hdr *ipv4_hdr,
> uint64_t ol_flags)
> } else {
> psd_hdr.len = rte_cpu_to_be_16(
> (uint16_t)(rte_be_to_cpu_16(ipv4_hdr->total_length)
> - - sizeof(struct rte_ipv4_hdr)));
> + - ((ipv4_hdr->version_ihl & 0xf) * 4)));
> }
> return rte_raw_cksum(&psd_hdr, sizeof(psd_hdr));
> }
> @@ -319,8 +319,8 @@ rte_ipv4_phdr_cksum(const struct rte_ipv4_hdr *ipv4_hdr,
> uint64_t ol_flags)
> /**
> * Process the IPv4 UDP or TCP checksum.
> *
> - * The IPv4 header should not contains options. The IP and layer 4
> - * checksum must be set to 0 in the packet by the caller.
> + * The IP and layer 4 checksum must be set to 0 in the packet by
> + * the caller.
> *
> * @param ipv4_hdr
> * The pointer to the contiguous IPv4 header.
> @@ -339,7 +339,7 @@ rte_ipv4_udptcp_cksum(const struct rte_ipv4_hdr
> *ipv4_hdr, const void *l4_hdr)
> if (l3_len < sizeof(struct rte_ipv4_hdr))
> return 0;
>
> - l4_len = l3_len - sizeof(struct rte_ipv4_hdr);
> + l4_len = l3_len - ((ipv4_hdr->version_ihl & 0xf) * 4);
Previous if condition guarantees that the result will be not
negative (and make huge l4_len), so it looks like it should be
updated as well. I think it makes sense to introduce
additional variable with calculated IPv4 header length.
>
> cksum = rte_raw_cksum(l4_hdr, l4_len);
> cksum += rte_ipv4_phdr_cksum(ipv4_hdr, 0);
>
Re: [dpdk-dev] [PATCH 1/7] ethdev: remove legacy descriptor status check API
On 8/24/20 12:40 PM, Ferruh Yigit wrote: > Removing 'rte_eth_rx_descriptor_done()' API and relevant > 'rx_descriptor_done' function pointer from 'struct eth_dev_ops'. > > Deprecation notice is to deprecate the API in 20.11 and remove one year > later, this is useful to prevent new applications use the API but keep > the support for old application. But since 20.11 have the ABI break and > most of the applications need to re-compile anyway will prevent them to > use the API, the affect will be same as removing the API. So removing it > in the 20.11 to reduce the churn. > > 'rx_descriptor_done' implementations removed from PMDs. > > Signed-off-by: Ferruh Yigit Reviewed-by: Andrew Rybchenko Thanks for working on it.
Re: [dpdk-dev] [PATCH 2/7] ethdev: move inline device operations
On 8/24/20 12:40 PM, Ferruh Yigit wrote:
> This patch is a preparation to hide the 'struct eth_dev_ops' from
> applications by moving some device operations from 'struct eth_dev_ops'
> to 'struct rte_eth_dev'.
>
> Mentioned ethdev APIs are in the data path and implemented as inline
> because of performance reasons.
>
> Exposing 'struct eth_dev_ops' to applications is bad because it is a
> contract between ethdev and PMDs, not really needs to be known by
> applications, also changes in the struct causing ABI breakages which
> shouldn't.
>
> To be able to both keep APIs inline and hide the 'struct eth_dev_ops',
> moving device operations used in ethdev inline APIs to 'struct
> rte_eth_dev' to the same level with Rx/Tx burst functions.
>
> The list of dev_ops moved:
> eth_rx_queue_count_t rx_queue_count;
> eth_rx_descriptor_status_t rx_descriptor_status;
> eth_tx_descriptor_status_t tx_descriptor_status;
>
> Signed-off-by: Ferruh Yigit
Reviewed-by: Andrew Rybchenko
doc/guides/nics/features.rst should be updated since it says
that status callbacks live in eth_dev_ops.
plus an net/sfc-related nit below:
[snip]
> diff --git a/drivers/net/sfc/sfc_ethdev.c b/drivers/net/sfc/sfc_ethdev.c
> index 65e0ff7d48..0b06bf91a0 100644
> --- a/drivers/net/sfc/sfc_ethdev.c
> +++ b/drivers/net/sfc/sfc_ethdev.c
[snip]
> @@ -1962,6 +1959,9 @@ sfc_eth_dev_set_ops(struct rte_eth_dev *dev)
> dev->tx_pkt_burst = dp_tx->pkt_burst;
>
> dev->dev_ops = &sfc_eth_dev_ops;
> + dev->rx_queue_count = sfc_rx_queue_count;
> + dev->rx_descriptor_status = sfc_rx_descriptor_status;
> + dev->tx_descriptor_status = sfc_tx_descriptor_status;
May I ask to put it just after dev->tx_pkt_burst = ... line
since these callbacks go before dev_ops in the structure.
>
> return 0;
>
> @@ -2001,9 +2001,6 @@ sfc_eth_dev_clear_ops(struct rte_eth_dev *dev)
>
> static const struct eth_dev_ops sfc_eth_dev_secondary_ops = {
> .dev_supported_ptypes_get = sfc_dev_supported_ptypes_get,
> - .rx_queue_count = sfc_rx_queue_count,
> - .rx_descriptor_status = sfc_rx_descriptor_status,
> - .tx_descriptor_status = sfc_tx_descriptor_status,
> .reta_query = sfc_dev_rss_reta_query,
> .rss_hash_conf_get = sfc_dev_rss_hash_conf_get,
> .rxq_info_get = sfc_rx_queue_info_get,
> @@ -2069,6 +2066,9 @@ sfc_eth_dev_secondary_init(struct rte_eth_dev *dev,
> uint32_t logtype_main)
> dev->tx_pkt_prepare = dp_tx->pkt_prepare;
> dev->tx_pkt_burst = dp_tx->pkt_burst;
> dev->dev_ops = &sfc_eth_dev_secondary_ops;
> + dev->rx_queue_count = sfc_rx_queue_count;
> + dev->rx_descriptor_status = sfc_rx_descriptor_status;
> + dev->tx_descriptor_status = sfc_tx_descriptor_status;
Same here.
[snip]
Re: [dpdk-dev] [PATCH 3/7] ethdev: make device operations struct private
On 8/24/20 12:40 PM, Ferruh Yigit wrote: > Hiding the 'struct eth_dev_ops' from applications. > > Removing relevant deprecation notice. > > Signed-off-by: Ferruh Yigit Acked-by: Andrew Rybchenko
Re: [dpdk-dev] [PATCH 4/7] ethdev: mark internal functions
On 8/24/20 12:40 PM, Ferruh Yigit wrote: > Some ethdev functions are for drivers only, not for applications. > > Since we have '__rte_internal' tag available now, marking internal > functions with it and moving functions to INTERNAL section in linker > script. > This is also good for documenting the internal functions. > > Some internal APIs seems marked as experimental, but it doesn't make > sense to have internals APIs as experimental, updating their tag and > doxygen comments. > > Signed-off-by: Ferruh Yigit Acked-by: Andrew Rybchenko with a nit below [snip] > diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h > index 2ce186610b..ce2e0ec0e4 100644 > --- a/lib/librte_ethdev/rte_ethdev.h > +++ b/lib/librte_ethdev/rte_ethdev.h > @@ -1723,8 +1723,7 @@ rte_eth_find_next_of(uint16_t port_id_start, > */ > __rte_experimental > uint16_t > -rte_eth_find_next_sibling(uint16_t port_id_start, > - uint16_t ref_port_id); > +rte_eth_find_next_sibling(uint16_t port_id_start, uint16_t ref_port_id); Looks unrelated [snip]
Re: [dpdk-dev] [PATCH 5/7] ethdev: use hairpin helper functions
On 8/24/20 12:40 PM, Ferruh Yigit wrote: > Hairpin helper functions were not used by drivers, but it was used only > local to ethdev. They are: > 'rte_eth_dev_is_rx_hairpin_queue()' > 'rte_eth_dev_is_tx_hairpin_queue()' > > Exposing them as internal APIs and update mlx5 driver (only user of > hairpin) to use them. > > Signed-off-by: Ferruh Yigit Acked-by: Andrew Rybchenko
Re: [dpdk-dev] [PATCH 6/7] ethdev: remove invalid symbols from map file
On 8/24/20 12:40 PM, Ferruh Yigit wrote:
> These are sturct type names, not object names. Removing them from .map
> file.
>
> Fixes: 9d41beed24b0 ("lib: provide initial versioning")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Ferruh Yigit
Reviewed-by: Andrew Rybchenko
Re: [dpdk-dev] [PATCH 7/7] ethdev: remove underscore prefix from internal API
On 8/24/20 12:40 PM, Ferruh Yigit wrote:
> '_rte_eth_dev_callback_process()' & '_rte_eth_dev_reset()' internal APIs
> has unconventional underscore ('_') prefix.
> Although this is not documented most probably this is to mark them as
> internal. Since we have '__rte_internal' flag to mark this, removing '_'
> from API names.
>
> For '_rte_eth_dev_reset()', there is already a public API named
> 'rte_eth_dev_reset()', so renaming '_rte_eth_dev_reset()' to
> 'rte_eth_dev_internal_reset'.
>
> Signed-off-by: Ferruh Yigit
Acked-by: Andrew Rybchenko
Re: [dpdk-dev] [PATCH] rte_log: make rte_logs private
On 8/28/20 1:54 AM, Stephen Hemminger wrote: > As announced in earlier releases, rte_logs can now be made > internal to eal_common_log. > > Signed-off-by: Stephen Hemminger Acked-by: Andrew Rybchenko
Re: [dpdk-dev] [PATCH v6 1/3] ethdev: add level support for RSS offload types
On 8/21/20 2:03 PM, kirankum...@marvell.com wrote:
> From: Kiran Kumar K
>
> This patch reserves 2 bits as input selection to select Inner and
> outer layers for RSS computation. It is combined with existing
> ETH_RSS_* to choose Inner or outer layers for L2, L3 and L4.
> This functionality already exists in rte_flow through level parameter in
> RSS action configuration rte_flow_action_rss.
>
> Signed-off-by: Kiran Kumar K
> ---
> V7 Changes:
> * Split ethdev and testpmd changes into seperate patches.
>
> lib/librte_ethdev/rte_ethdev.h | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
> index 70295d7ab..2a3a76d37 100644
> --- a/lib/librte_ethdev/rte_ethdev.h
> +++ b/lib/librte_ethdev/rte_ethdev.h
> @@ -552,6 +552,33 @@ struct rte_eth_rss_conf {
> #define RTE_ETH_RSS_L3_PRE64(1ULL << 53)
> #define RTE_ETH_RSS_L3_PRE96(1ULL << 52)
>
> +/*
> + * We use the following macros to combine with the above layers to choose
> + * inner and outer layers or both for RSS computation.
> + * Note: Default is 0: inner layers, 1: outer layers, 2: both
> + * bit 50 and 51 are reserved for this.
> + */
> +
> +/**
> + * Level 0, It basically stands for the innermost encapsulation level RSS
> + * can be performed on according to PMD and device capabilities.
> + */
> +#define ETH_RSS_LEVEL_INNER(0ULL << 50)
You're trying to refer to struct rte_flow_action_rss level definition
when values are chosen, but I think it is
inaccurate. Primary definition of the level==0 is PMD default,
not inner. Definition says that typically it is the innermost
encapsulation level RSS can be performed on according to PMD
and device capabilities. But it is secondary, primary
definition is "PMD default". Basically unspecified by the
caller (structure memset to 0) results in default behaviour.
> +/**
> + * Level 1, It basically stands for the outermost encapsulation level RSS
> + * can be performed on according to PMD and device capabilities.
> + */
> +#define ETH_RSS_LEVEL_OUTER(1ULL << 50)
> +/**
> + * Level 2, It basically stands for the both inner and outermost
> + * encapsulation level RSS can be performed on according to PMD and
> + * device capabilities.
> + */
> +#define ETH_RSS_LEVEL_INNER_OUTER (2ULL << 50)
Level equal to 2 is the first after the outermost inner level.
Level equal to 3 is the second after the outermost inner level
and so on.
If we really try to follow level definition from
rte_flow_action_rss, the problem is that these defines
are used to define RSS hashing capabilities in
dev_info.flow_type_rss_offloads. Support for level
up to 3 levels, does not mean that we can hash on any,
it could be either outermost or innermost level, but
not the middle level, if 3 levels are present.
Or just innermost recognized: either the first one
if no tunnels recognized, the second if two levels
are recognized, or the third one if three levels are
recognized.
Sorry, that I'm not proposing any solution right now.
Just need more time to thing about it.
You're welcome to try to cover these requirements.
> +#define ETH_RSS_LEVEL_MASK (3ULL << 50)
> +
> +#define ETH_RSS_LEVEL(rss_hf) ((rss_hf & ETH_RSS_LEVEL_MASK) >> 50)
> +
> /**
> * For input set change of hash filter, if SRC_ONLY and DST_ONLY of
> * the same level are used simultaneously, it is the same case as
> --
> 2.25.1
>
Re: [dpdk-dev] [PATCH v3 02/11] baseband/acc100: add register definition file
Hi Rosen,
> From: Xu, Rosen
>
> Hi,
>
> > -Original Message-
> > From: dev On Behalf Of Nicolas Chautru
> > Sent: Wednesday, August 19, 2020 8:25
> > To: dev@dpdk.org; akhil.go...@nxp.com
> > Cc: Richardson, Bruce ; Chautru, Nicolas
> >
> > Subject: [dpdk-dev] [PATCH v3 02/11] baseband/acc100: add register
> > definition file
> >
> > Add in the list of registers for the device and related
> > HW specs definitions.
> >
> > Signed-off-by: Nicolas Chautru
> > ---
> > drivers/baseband/acc100/acc100_pf_enum.h | 1068
> > ++
> > drivers/baseband/acc100/acc100_vf_enum.h | 73 ++
> > drivers/baseband/acc100/rte_acc100_pmd.h | 490 ++
> > 3 files changed, 1631 insertions(+)
> > create mode 100644 drivers/baseband/acc100/acc100_pf_enum.h
> > create mode 100644 drivers/baseband/acc100/acc100_vf_enum.h
> >
> > diff --git a/drivers/baseband/acc100/acc100_pf_enum.h
> > b/drivers/baseband/acc100/acc100_pf_enum.h
> > new file mode 100644
> > index 000..a1ee416
> > --- /dev/null
> > +++ b/drivers/baseband/acc100/acc100_pf_enum.h
> > @@ -0,0 +1,1068 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(c) 2017 Intel Corporation
> > + */
> > +
> > +#ifndef ACC100_PF_ENUM_H
> > +#define ACC100_PF_ENUM_H
> > +
> > +/*
> > + * ACC100 Register mapping on PF BAR0
> > + * This is automatically generated from RDL, format may change with new
> > RDL
> > + * Release.
> > + * Variable names are as is
> > + */
> > +enum {
> > + HWPfQmgrEgressQueuesTemplate = 0x0007FE00,
> > + HWPfQmgrIngressAq = 0x0008,
> > + HWPfQmgrArbQAvail = 0x00A00010,
> > + HWPfQmgrArbQBlock = 0x00A00014,
> > + HWPfQmgrAqueueDropNotifEn = 0x00A00024,
> > + HWPfQmgrAqueueDisableNotifEn = 0x00A00028,
> > + HWPfQmgrSoftReset = 0x00A00038,
> > + HWPfQmgrInitStatus= 0x00A0003C,
> > + HWPfQmgrAramWatchdogCount = 0x00A00040,
> > + HWPfQmgrAramWatchdogCounterEn = 0x00A00044,
> > + HWPfQmgrAxiWatchdogCount = 0x00A00048,
> > + HWPfQmgrAxiWatchdogCounterEn = 0x00A0004C,
> > + HWPfQmgrProcessWatchdogCount = 0x00A00050,
> > + HWPfQmgrProcessWatchdogCounterEn = 0x00A00054,
> > + HWPfQmgrProcessUl4GWatchdogCounter= 0x00A00058,
> > + HWPfQmgrProcessDl4GWatchdogCounter= 0x00A0005C,
> > + HWPfQmgrProcessUl5GWatchdogCounter= 0x00A00060,
> > + HWPfQmgrProcessDl5GWatchdogCounter= 0x00A00064,
> > + HWPfQmgrProcessMldWatchdogCounter = 0x00A00068,
> > + HWPfQmgrMsiOverflowUpperVf= 0x00A00070,
> > + HWPfQmgrMsiOverflowLowerVf= 0x00A00074,
> > + HWPfQmgrMsiWatchdogOverflow = 0x00A00078,
> > + HWPfQmgrMsiOverflowEnable = 0x00A0007C,
> > + HWPfQmgrDebugAqPointerMemGrp = 0x00A00100,
> > + HWPfQmgrDebugOutputArbQFifoGrp= 0x00A00140,
> > + HWPfQmgrDebugMsiFifoGrp = 0x00A00180,
> > + HWPfQmgrDebugAxiWdTimeoutMsiFifo = 0x00A001C0,
> > + HWPfQmgrDebugProcessWdTimeoutMsiFifo = 0x00A001C4,
> > + HWPfQmgrDepthLog2Grp = 0x00A00200,
> > + HWPfQmgrTholdGrp = 0x00A00300,
> > + HWPfQmgrGrpTmplateReg0Indx= 0x00A00600,
> > + HWPfQmgrGrpTmplateReg1Indx= 0x00A00680,
> > + HWPfQmgrGrpTmplateReg2indx= 0x00A00700,
> > + HWPfQmgrGrpTmplateReg3Indx= 0x00A00780,
> > + HWPfQmgrGrpTmplateReg4Indx= 0x00A00800,
> > + HWPfQmgrVfBaseAddr= 0x00A01000,
> > + HWPfQmgrUl4GWeightRrVf= 0x00A02000,
> > + HWPfQmgrDl4GWeightRrVf= 0x00A02100,
> > + HWPfQmgrUl5GWeightRrVf= 0x00A02200,
> > + HWPfQmgrDl5GWeightRrVf= 0x00A02300,
> > + HWPfQmgrMldWeightRrVf = 0x00A02400,
> > + HWPfQmgrArbQDepthGrp = 0x00A02F00,
> > + HWPfQmgrGrpFunction0 = 0x00A02F40,
> > + HWPfQmgrGrpFunction1 = 0x00A02F44,
> > + HWPfQmgrGrpPriority = 0x00A02F48,
> > + HWPfQmgrWeightSync= 0x00A03000,
> > + HWPfQmgrAqEnableVf= 0x00A1,
> > + HWPfQmgrAqResetVf = 0x00A2,
> > + HWPfQmgrRingSizeVf= 0x00A20004,
> > + HWPfQmgrGrpDepthLog20Vf = 0x00A20008,
> > + HWPfQmgrGrpDepthLog21Vf = 0x00A2000C,
> > + HWPfQmgrGrpFunction0Vf= 0x00A20010,
> > + HWPfQmgrGrpFunction1Vf= 0x00A20014,
> > + HWPfDmaConfig0Reg = 0x00B8,
> > + HWPfDmaConfig1Reg = 0x00B80004,
> > + HWPfDmaQmgrAddrReg= 0x00B80008,
> > + HWPfDmaSoftResetReg = 0x00B8000C,
> > + HWPfDmaAxcacheReg
Re: [dpdk-dev] [PATCH v3 04/11] baseband/acc100: add queue configuration
Hi,
> From: Xu, Rosen
>
> Hi,
>
> > -Original Message-
> > From: dev On Behalf Of Nicolas Chautru
> > Sent: Wednesday, August 19, 2020 8:25
> > To: dev@dpdk.org; akhil.go...@nxp.com
> > Cc: Richardson, Bruce ; Chautru, Nicolas
> >
> > Subject: [dpdk-dev] [PATCH v3 04/11] baseband/acc100: add queue
> > configuration
> >
> > Adding function to create and configure queues for the device. Still
> > no capability.
> >
> > Signed-off-by: Nicolas Chautru
> > ---
> > drivers/baseband/acc100/rte_acc100_pmd.c | 420
> > ++-
> > drivers/baseband/acc100/rte_acc100_pmd.h | 45
> > 2 files changed, 464 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> > b/drivers/baseband/acc100/rte_acc100_pmd.c
> > index 7807a30..7a21c57 100644
> > --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> > +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> > @@ -26,6 +26,22 @@
> > RTE_LOG_REGISTER(acc100_logtype, pmd.bb.acc100, NOTICE); #endif
> >
> > +/* Write to MMIO register address */
> > +static inline void
> > +mmio_write(void *addr, uint32_t value) {
> > + *((volatile uint32_t *)(addr)) = rte_cpu_to_le_32(value); }
> > +
> > +/* Write a register of a ACC100 device */ static inline void
> > +acc100_reg_write(struct acc100_device *d, uint32_t offset, uint32_t
> > +payload) {
> > + void *reg_addr = RTE_PTR_ADD(d->mmio_base, offset);
> > + mmio_write(reg_addr, payload);
> > + usleep(1000);
> > +}
> > +
> > /* Read a register of a ACC100 device */ static inline uint32_t
> > acc100_reg_read(struct acc100_device *d, uint32_t offset) @@ -36,6
> > +52,22 @@
> > return rte_le_to_cpu_32(ret);
> > }
> >
> > +/* Basic Implementation of Log2 for exact 2^N */ static inline
> > +uint32_t log2_basic(uint32_t value) {
> > + return (value == 0) ? 0 : __builtin_ctz(value); }
> > +
> > +/* Calculate memory alignment offset assuming alignment is 2^N */
> > +static inline uint32_t calc_mem_alignment_offset(void
> > +*unaligned_virt_mem, uint32_t alignment) {
> > + rte_iova_t unaligned_phy_mem =
> > rte_malloc_virt2iova(unaligned_virt_mem);
> > + return (uint32_t)(alignment -
> > + (unaligned_phy_mem & (alignment-1))); }
> > +
> > /* Calculate the offset of the enqueue register */ static inline
> > uint32_t queue_offset(bool pf_device, uint8_t vf_id, uint8_t qgrp_id,
> > uint16_t aq_id) @@ -204,10 +236,393 @@
> > acc100_conf->q_dl_5g.aq_depth_log2);
> > }
> >
> > +static void
> > +free_base_addresses(void **base_addrs, int size) {
> > + int i;
> > + for (i = 0; i < size; i++)
> > + rte_free(base_addrs[i]);
> > +}
> > +
> > +static inline uint32_t
> > +get_desc_len(void)
> > +{
> > + return sizeof(union acc100_dma_desc); }
> > +
> > +/* Allocate the 2 * 64MB block for the sw rings */ static int
> > +alloc_2x64mb_sw_rings_mem(struct rte_bbdev *dev, struct acc100_device
> > *d,
> > + int socket)
> > +{
> > + uint32_t sw_ring_size = ACC100_SIZE_64MBYTE;
> > + d->sw_rings_base = rte_zmalloc_socket(dev->device->driver-
> > >name,
> > + 2 * sw_ring_size, RTE_CACHE_LINE_SIZE, socket);
> > + if (d->sw_rings_base == NULL) {
> > + rte_bbdev_log(ERR, "Failed to allocate memory for %s:%u",
> > + dev->device->driver->name,
> > + dev->data->dev_id);
> > + return -ENOMEM;
> > + }
> > + memset(d->sw_rings_base, 0, ACC100_SIZE_64MBYTE);
> > + uint32_t next_64mb_align_offset = calc_mem_alignment_offset(
> > + d->sw_rings_base, ACC100_SIZE_64MBYTE);
> > + d->sw_rings = RTE_PTR_ADD(d->sw_rings_base,
> > next_64mb_align_offset);
> > + d->sw_rings_phys = rte_malloc_virt2iova(d->sw_rings_base) +
> > + next_64mb_align_offset;
> > + d->sw_ring_size = MAX_QUEUE_DEPTH * get_desc_len();
> > + d->sw_ring_max_depth = d->sw_ring_size / get_desc_len();
> > +
> > + return 0;
> > +}
>
> Why not a common alloc memory function but special function for different
> memory size?
This is a bit convoluted but due to the fact the first attempt method which is
optimal (minimum) may not always find aligned memory.
>
> > +/* Attempt to allocate minimised memory space for sw rings */ static
> > +void alloc_sw_rings_min_mem(struct rte_bbdev *dev, struct
> > acc100_device
> > +*d,
> > + uint16_t num_queues, int socket)
> > +{
> > + rte_iova_t sw_rings_base_phy, next_64mb_align_addr_phy;
> > + uint32_t next_64mb_align_offset;
> > + rte_iova_t sw_ring_phys_end_addr;
> > + void *base_addrs[SW_RING_MEM_ALLOC_ATTEMPTS];
> > + void *sw_rings_base;
> > + int i = 0;
> > + uint32_t q_sw_ring_size = MAX_QUEUE_DEPTH * get_desc_len();
> > + uint32_t dev_sw_ring_size = q_sw_ring_size * num_queues;
> > +
> > + /* Find an aligned block of memory to store sw rings */
> > + while (i < SW_RING_MEM_ALLOC_ATTEMPTS) {
> > + /*
> > +* sw_ring alloca
Re: [dpdk-dev] Using valgrind with DPDK app
Hello, I have exactly the same problem as you. I have also downloaded, compiled and installed the very last version of valgrind (v3.17). As soon as the mempool is created, the program gets stuck. If valgrind cannot be used with DPDK (I am using v18.11.5) as memory leak debugger, there must be other tool to do it. Which one? Thanks for your attention El vie., 10 jul. 2020 a las 16:59, Montorsi, Francesco (< fmonto...@empirix.com>) escribió: > Hi all, > I would like to know if it's possible to run my DPDK application (I'm > using DPDK 19.11) under Valgrind. > I tried but it gets stuck apparently while accessing hugepages: > > > AL: Detected memory type: socket_id:0 hugepage_sz:1073741824 > EAL: Detected memory type: socket_id:1 hugepage_sz:1073741824 > EAL: Creating 4 segment lists: n_segs:32 socket_id:0 hugepage_sz:1073741824 > EAL: Ask a virtual area of 0x1000 bytes > EAL: Virtual area found at 0x100033000 (size = 0x1000) > EAL: Memseg list allocated: 0x10kB at socket 0 > EAL: Ask a virtual area of 0x8 bytes > EAL: Virtual area found at 0x14000 (size = 0x8) > EAL: Ask a virtual area of 0x1000 bytes > EAL: Virtual area found at 0x94000 (size = 0x1000) > EAL: Memseg list allocated: 0x10kB at socket 0 > EAL: Ask a virtual area of 0x8 bytes > EAL: WARNING! Base virtual address hint (0xa80001000 != 0x104000) not > respected! > EAL:This may cause issues with mapping memory into secondary processes > EAL: Virtual area found at 0x104000 (size = 0x8) > EAL: Ask a virtual area of 0x1000 bytes > EAL: Virtual area found at 0xac0001000 (size = 0x1000) > EAL: Memseg list allocated: 0x10kB at socket 0 > EAL: Ask a virtual area of 0x8 bytes > > > I've seen there was some attempt a few years ago: > http://mails.dpdk.org/archives/dev/2016-February/033108.html > has anything changed since that? > > Also I see that Luca has created a project here > https://github.com/bluca/valgrind-dpdk > but seems like there were no changes since 3 years... I wonder if that > works or not with recent DPDK versions... > > Thanks for any hint, > > Francesco Montorsi > > > > -- Victor
Re: [dpdk-dev] [PATCH v3 05/11] baseband/acc100: add LDPC processing functions
Hi Rosen,
> From: Xu, Rosen
>
> Hi,
>
> > -Original Message-
> > From: dev On Behalf Of Nicolas Chautru
> > Sent: Wednesday, August 19, 2020 8:25
> > To: dev@dpdk.org; akhil.go...@nxp.com
> > Cc: Richardson, Bruce ; Chautru, Nicolas
> >
> > Subject: [dpdk-dev] [PATCH v3 05/11] baseband/acc100: add LDPC
> > processing functions
> >
> > Adding LDPC decode and encode processing operations
> >
> > Signed-off-by: Nicolas Chautru
> > ---
> > drivers/baseband/acc100/rte_acc100_pmd.c | 1625
> > +-
> > drivers/baseband/acc100/rte_acc100_pmd.h |3 +
> > 2 files changed, 1626 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/baseband/acc100/rte_acc100_pmd.c
> > b/drivers/baseband/acc100/rte_acc100_pmd.c
> > index 7a21c57..5f32813 100644
> > --- a/drivers/baseband/acc100/rte_acc100_pmd.c
> > +++ b/drivers/baseband/acc100/rte_acc100_pmd.c
> > @@ -15,6 +15,9 @@
> > #include
> > #include
> > #include
> > +#ifdef RTE_BBDEV_OFFLOAD_COST
> > +#include
> > +#endif
> >
> > #include
> > #include
> > @@ -449,7 +452,6 @@
> > return 0;
> > }
> >
> > -
> > /**
> > * Report a ACC100 queue index which is free
> > * Return 0 to 16k for a valid queue_idx or -1 when no queue is available
> > @@ -634,6 +636,46 @@
> > struct acc100_device *d = dev->data->dev_private;
> >
> > static const struct rte_bbdev_op_cap bbdev_capabilities[] = {
> > + {
> > + .type = RTE_BBDEV_OP_LDPC_ENC,
> > + .cap.ldpc_enc = {
> > + .capability_flags =
> > + RTE_BBDEV_LDPC_RATE_MATCH |
> > + RTE_BBDEV_LDPC_CRC_24B_ATTACH
> > |
> > +
> > RTE_BBDEV_LDPC_INTERLEAVER_BYPASS,
> > + .num_buffers_src =
> > +
> > RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> > + .num_buffers_dst =
> > +
> > RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> > + }
> > + },
> > + {
> > + .type = RTE_BBDEV_OP_LDPC_DEC,
> > + .cap.ldpc_dec = {
> > + .capability_flags =
> > + RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK |
> > + RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP |
> > +
> > RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE |
> > +
> > RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE |
> > +#ifdef ACC100_EXT_MEM
> > +
> > RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_IN_ENABLE |
> > +
> > RTE_BBDEV_LDPC_INTERNAL_HARQ_MEMORY_OUT_ENABLE |
> > +#endif
> > +
> > RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE |
> > + RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS
> > |
> > + RTE_BBDEV_LDPC_DECODE_BYPASS |
> > + RTE_BBDEV_LDPC_DEC_SCATTER_GATHER |
> > +
> > RTE_BBDEV_LDPC_HARQ_6BIT_COMPRESSION |
> > + RTE_BBDEV_LDPC_LLR_COMPRESSION,
> > + .llr_size = 8,
> > + .llr_decimals = 1,
> > + .num_buffers_src =
> > +
> > RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> > + .num_buffers_hard_out =
> > +
> > RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
> > + .num_buffers_soft_out = 0,
> > + }
> > + },
> > RTE_BBDEV_END_OF_CAPABILITIES_LIST()
> > };
> >
> > @@ -669,9 +711,14 @@
> > dev_info->cpu_flag_reqs = NULL;
> > dev_info->min_alignment = 64;
> > dev_info->capabilities = bbdev_capabilities;
> > +#ifdef ACC100_EXT_MEM
> > dev_info->harq_buffer_size = d->ddr_size;
> > +#else
> > + dev_info->harq_buffer_size = 0;
> > +#endif
> > }
> >
> > +
> > static const struct rte_bbdev_ops acc100_bbdev_ops = {
> > .setup_queues = acc100_setup_queues,
> > .close = acc100_dev_close,
> > @@ -696,6 +743,1577 @@
> > {.device_id = 0},
> > };
> >
> > +/* Read flag value 0/1 from bitmap */
> > +static inline bool
> > +check_bit(uint32_t bitmap, uint32_t bitmask)
> > +{
> > + return bitmap & bitmask;
> > +}
> > +
> > +static inline char *
> > +mbuf_append(struct rte_mbuf *m_head, struct rte_mbuf *m, uint16_t len)
> > +{
> > + if (unlikely(len > rte_pktmbuf_tailroom(m)))
> > + return NULL;
> > +
> > + char *tail = (char *)m->buf_addr + m->data_off + m->data_len;
> > + m->data_len = (uint16_t)(m->data_len + len);
> > + m_head->pkt_len = (m_head->pkt_len + len);
> > + return tail;
> > +}
>
> Is it reasonable to direct add data_len of rte_mbuf?
>
Do you suggest to add directly without checking there is enough room in the
mbuf? We cannot rely on the application providing mbuf with enough tailroom.
In case you ask about the 2 mbufs, this is because this function is used to
also support segmented memory made of multiple mbufs segments.
Note that this function is also used in other existing bbdev PMDs. In case you
believe there is a better way to do this, we can certainly discuss and change
these in se
Re: [dpdk-dev] [PATCH] net/virtio: fix wrong variable assignment in helper macro
On 8/29/20 2:22 PM, Andrew Rybchenko wrote:
> On 8/14/20 12:21 PM, Vipul Ashri wrote:
>> Inside Macro ASSIGN_UNLESS_EQUAL(var, val), assignment to var is always
>> failing as assignment done using var_ having local scope only.
>> This leads to TX packets not going out and found broken due to cleanup
>> malfunctioning. This patch fixes the wrong variable assignment.
>>
>> Fixes: 57f90f894588 ("net/virtio: reuse packed ring functions")
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Vipul Ashri
>> ---
>> drivers/net/virtio/virtqueue.h | 6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
>> index 105a9c00c..20c95471e 100644
>> --- a/drivers/net/virtio/virtqueue.h
>> +++ b/drivers/net/virtio/virtqueue.h
>> @@ -607,10 +607,8 @@ virtqueue_notify(struct virtqueue *vq)
>>
>> /* avoid write operation when necessary, to lessen cache issues */
>> #define ASSIGN_UNLESS_EQUAL(var, val) do { \
>> -typeof(var) var_ = (var); \
>> -typeof(val) val_ = (val); \
>> -if ((var_) != (val_)) \
>> -(var_) = (val_);\
>> +if ((var) != (val)) \
>> +(var) = (val); \
>
> Good catch. As I understand the old code tries to avoid
> processing of var and val expressions twice. It looks it
> could be kept for val at least. Just keep if condition as in
> old code and fix the last line above:
> (var) = val_;
> Since var_ and val_are local variables there is no necessity
> to enclose it in parenthesis (but does not harm if done).
> var_ may be really removed since since resulting code will
> use it only once.
I think there is a solution to avoid multiple evaluations of parameters:
// var is definitely an lvalue, so its address can definitely be taken
#define ASSIGN_UNLESS_EQUAL(var, val) do { \
typeof(var) *const var_ = &(var); \
typeof(val) const val_ = (val);\
if (*var_ != val_) \
*var_ = val_; \
} while (0)
The solution relies on the compiler optimizer. Here is the comparison of
what the variants are compiled into:
https://godbolt.org/z/nnvq5q
