Re: [PATCH v2] net/virtio: fixed missing next flag when sending packets in packed mode

[Maxime Coquelin]

Hi,

Thanks for investigating the issue and proposing a fix!

On 10/10/23 04:08, liufengjiang.0426 wrote:

When the packets is sent in packed mode, and the packets data and
virtio-header are divided into two desc, set the next flag of
virtio-header desc


Fix the warning that a single line of commit log exceeds 75 chars


The changelog should not be part of the commit message.



Bugzilla ID: 1295
Fixes: 892dc798fa9c ("net/virtio: implement Tx path for packed queues")

Signed-off-by: liufengjiang.0426 


Could you please sign-off with your full name?



---


The changelog should be placed here.


  drivers/net/virtio/virtqueue.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/net/virtio/virtqueue.h b/drivers/net/virtio/virtqueue.h
index 9d4aba11a3..4e9f2d0358 100644
--- a/drivers/net/virtio/virtqueue.h
+++ b/drivers/net/virtio/virtqueue.h
@@ -672,6 +672,7 @@ virtqueue_enqueue_xmit_packed(struct virtnet_tx *txvq, 
struct rte_mbuf *cookie,
 */
start_dp[idx].addr = txvq->hdr_mem + 
RTE_PTR_DIFF(&txr[idx].tx_hdr, txr);
start_dp[idx].len = vq->hw->vtnet_hdr_size;
+   head_flags |= VRING_DESC_F_NEXT;
hdr = (struct virtio_net_hdr *)&txr[idx].tx_hdr;
idx++;
if (idx >= vq->vq_nentries) {


Otherwise, the fix look good to me.
With above small changes, it will be good for me.

Thanks,
Maxime

回复: [PATCH v3 1/8] ethdev: add member notification for bonding port

[Long Wu]

> Hi Chaoyong,
> 
> some comments as below.
> 
> 
> 在 2023/10/8 9:50, Chaoyong He 写道:
> > From: Long Wu 
> >
> > Bonding PMD does not let member ports know the bonding port's 
> > information, like how many member ports the bonding port has, what 
> > mode the bonding port is in and so on.
> >
> > Add the notification interface for bonding port to let member port 
> > know it is added to a bonding port and what the bonding port's 
> > configuration is. If so the member ports have chance to achieve its 
> > bond-flow-offlod or other private bonding functions.
> "its bond-flow-offlod or other private bonding functions"
> I wonder that what PMDs can do with this.
> Can you give an example in PMD to help others review?

After this patch series, I will send out nfp PMD code about "its 
bond-flow-offlod or other private bonding functions ".
I can explain here:
"bond-flow" means the flow rule's destination port is a bonding port.
Now DPDK can use bonding port as the source port in a flow rule and member 
ports can offload this flow.
But member ports cannot offload a flow that its destination port is a bonding 
port.
Because the member ports don't know the bonding port. (Of course, some PMDs has 
its self-function to let member ports know the bonding port but it doesn't a 
general "DPDK" way).
After this "notify patch", DPDK can do "bond-flow-offload", also "other private 
bonding functions"(like hardware balance policy, primary port changing and so 
on) can work.

> >
> > Signed-off-by: Long Wu 
> > Reviewed-by: James Hershaw 
> > Reviewed-by: Chaoyong He 
> > ---
> >   drivers/net/bonding/eth_bond_private.h |  1 +
> >   drivers/net/bonding/rte_eth_bond.h | 46 
> >   drivers/net/bonding/rte_eth_bond_api.c | 73
> ++
> >   drivers/net/bonding/rte_eth_bond_pmd.c | 27 --
> >   drivers/net/bonding/version.map|  3 ++
> >   lib/ethdev/ethdev_driver.h | 18 +++
> >   6 files changed, 165 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/bonding/eth_bond_private.h
> > b/drivers/net/bonding/eth_bond_private.h
> > index e688894210..f69e85c199 100644
> > --- a/drivers/net/bonding/eth_bond_private.h
> > +++ b/drivers/net/bonding/eth_bond_private.h
> > @@ -180,6 +180,7 @@ struct bond_dev_private {
> > uint8_t member_update_idx;
> >
> > bool kvargs_processing_is_done;
> > +   bool notify_member; /**< Enable member notification of bonding port.
> > +*/
> >
> > uint32_t candidate_max_rx_pktlen;
> > uint32_t max_rx_pktlen;
> > diff --git a/drivers/net/bonding/rte_eth_bond.h
> > b/drivers/net/bonding/rte_eth_bond.h
> > index f10165f2c6..737beca446 100644
> > --- a/drivers/net/bonding/rte_eth_bond.h
> > +++ b/drivers/net/bonding/rte_eth_bond.h
> > @@ -351,6 +351,52 @@ rte_eth_bond_link_up_prop_delay_set(uint16_t
> bonding_port_id,
> >   int
> >   rte_eth_bond_link_up_prop_delay_get(uint16_t bonding_port_id);
> >
> > +/**
> > + * Set the flag of whether bonding port notifies member ports.
> > + *
> > + * @param bonding_port_id
> > + *   Port ID of bonding device.
> > + * @param notify_member
> > + *   Flag of whether bonding port notifies member ports.
> > + *
> > + * @return
> > + *   0 on success, negative value otherwise.
> > + */
> > +__rte_experimental
> > +int
> > +rte_eth_bond_notify_member_flag_set(uint16_t bonding_port_id, bool 
> > +notify_member);
> s/notify_membe/notify in input?
> because function name reveals the meaning already.

Thank you, you are right.

> > +
> > +/**
> > + * Get the flag of whether bonding port notifies member ports.
> > + *
> > + * @param bonding_port_id
> > + *   Port ID of bonding device.
> > + * @param notify_member
> > + *   Flag of whether bonding port notifies member ports.
> > + *
> > + * @return
> > + *   0 on success, negative value otherwise.
> > + */
> > +__rte_experimental
> > +int
> > +rte_eth_bond_notify_member_flag_get(uint16_t bonding_port_id, bool 
> > +*notify_member);
> > +
> > +/**
> > + * Notify the member ports of bonding port's information.
> > + *
> > + * This interface is called in the following functions:
> > + * - bond_ethdev_lsc_event_callback()
> > + * - bond_ethdev_configure()
> Is this interface used just  in these cases?
> If so I don't think it should be a API in eth_dev_op.

Sorry I'm a bit confused.
Do you mean "rte_eth_bond_notify_members" this interface? This interface is 
called in 3 functions.

> > ...
> > +   struct rte_eth_dev *member_dev[RTE_MAX_ETHPORTS];
> > +
> > +   if (valid_bonding_port_id(bonding_port_id) != 0)
> > +   return -EINVAL;
> > +
> > +   bond_dev = &rte_eth_devices[bonding_port_id];
> > +   internals = bond_dev->data->dev_private;
> > +
> > +   for (i = 0; i < internals->member_count; i++) {
> > +   member_port_id = internals->members[i].port_id;
> > +   member_dev[i] = &rte_eth_devices[member_port_id];
> > +   if (*member_dev[i]->dev_ops->bond_notify_member == NULL)
> > +   return -ENOTSU

Re: [PATCH v5 08/12] baseband/acc: add FEC capabilities for the VRB2 variant

[Maxime Coquelin]

On 10/5/23 21:49, Nicolas Chautru wrote:

New implementation for some of the FEC features
specific to the VRB2 variant.

Signed-off-by: Nicolas Chautru 
---
  drivers/baseband/acc/rte_vrb_pmd.c | 370 +
  1 file changed, 328 insertions(+), 42 deletions(-)

diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index b36dd6ccd8..dab61fd5df 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -1235,6 +1235,94 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)
};
  
  	static const struct rte_bbdev_op_cap vrb2_bbdev_capabilities[] = {

+   {
+   .type = RTE_BBDEV_OP_TURBO_DEC,
+   .cap.turbo_dec = {
+   .capability_flags =
+   RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE |
+   RTE_BBDEV_TURBO_CRC_TYPE_24B |
+   RTE_BBDEV_TURBO_DEC_CRC_24B_DROP |
+   RTE_BBDEV_TURBO_EQUALIZER |
+   RTE_BBDEV_TURBO_SOFT_OUT_SATURATE |
+   RTE_BBDEV_TURBO_HALF_ITERATION_EVEN |
+   RTE_BBDEV_TURBO_CONTINUE_CRC_MATCH |
+   RTE_BBDEV_TURBO_SOFT_OUTPUT |
+   RTE_BBDEV_TURBO_EARLY_TERMINATION |
+   RTE_BBDEV_TURBO_DEC_INTERRUPTS |
+   RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN |
+   RTE_BBDEV_TURBO_NEG_LLR_1_BIT_SOFT_OUT |
+   RTE_BBDEV_TURBO_MAP_DEC |
+   RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP |
+   RTE_BBDEV_TURBO_DEC_SCATTER_GATHER,
+   .max_llr_modulus = INT8_MAX,
+   .num_buffers_src =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   .num_buffers_hard_out =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   .num_buffers_soft_out =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   }
+   },
+   {
+   .type = RTE_BBDEV_OP_TURBO_ENC,
+   .cap.turbo_enc = {
+   .capability_flags =
+   RTE_BBDEV_TURBO_CRC_24B_ATTACH |
+   RTE_BBDEV_TURBO_RV_INDEX_BYPASS |
+   RTE_BBDEV_TURBO_RATE_MATCH |
+   RTE_BBDEV_TURBO_ENC_INTERRUPTS |
+   RTE_BBDEV_TURBO_ENC_SCATTER_GATHER,
+   .num_buffers_src =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   .num_buffers_dst =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   }
+   },
+   {
+   .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 |
+   RTE_BBDEV_LDPC_ENC_INTERRUPTS |
+   RTE_BBDEV_LDPC_ENC_SCATTER_GATHER |
+   RTE_BBDEV_LDPC_ENC_CONCATENATION,
+   .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_CRC_TYPE_24A_CHECK |
+   RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK |
+   RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE |
+   RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE |
+   RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE |
+   RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS |
+   RTE_BBDEV_LDPC_

Re: [PATCH v5 01/12] bbdev: add FFT window width member in driver info

[Maxime Coquelin]

On 10/6/23 22:08, Chautru, Nicolas wrote:

Hi Maxime,


-Original Message-
From: Maxime Coquelin 
Sent: Friday, October 6, 2023 12:54 AM
To: Chautru, Nicolas ; dev@dpdk.org
Cc: hemant.agra...@nxp.com; david.march...@redhat.com; Vargas, Hernan

Subject: Re: [PATCH v5 01/12] bbdev: add FFT window width member in driver
info



On 10/5/23 21:48, Nicolas Chautru wrote:

This exposes the width of each windowing shape being configured on the
device. This allows to distinguish different version of the flexible
pointwise windowing applied to the FFT and expose this platform
configuration to the application.
This also add the total number of windows supported in the capability.

The SRS processing chain
(https://doc.dpdk.org/guides/prog_guide/bbdev.html#bbdev-fft-operation
) includes a pointwise multiplication by time window whose shape width
needs to be exposed, notably for accurate SNR estimate.
Using that mechanism user application can retrieve information related
to what has been dynamically programmed on any bbdev device supporting
FFT windowing operation.

Signed-off-by: Nicolas Chautru 
---
   lib/bbdev/rte_bbdev.h| 2 ++
   lib/bbdev/rte_bbdev_op.h | 2 ++
   2 files changed, 4 insertions(+)

diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index
2985c9f42b..d12e2e7fbc 100644
--- a/lib/bbdev/rte_bbdev.h
+++ b/lib/bbdev/rte_bbdev.h
@@ -349,6 +349,8 @@ struct rte_bbdev_driver_info {
const struct rte_bbdev_op_cap *capabilities;
/** Device cpu_flag requirements */
const enum rte_cpu_flag_t *cpu_flag_reqs;
+   /** FFT windowing width for 2048 FFT - size defined in capability. */
+   uint16_t *fft_window_width;
   };

   /** Macro used at end of bbdev PMD list */ diff --git
a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h index
693baa8386..369ac331bf 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -905,6 +905,8 @@ struct rte_bbdev_op_cap_fft {
uint16_t num_buffers_src;
/** Num output code block buffers. */
uint16_t num_buffers_dst;
+   /** Number of FFT windows supported. */
+   uint16_t fft_windows_num;
   };

   /** List of the capabilities for the MLD */


I am Ok to move forwards with this, even if I would have liked feedback from
Hemant.

However, I think you need to add some documentation around it, as what is in
the commit message is important and won't be visible to the end- user.


Can we extend the documentation in incremental serie? There other things that 
could arguably be exposed more clearly, not just this one but more generally on 
device enumeration which is currently limited (pretty much everything from 
info_get).


Ok, as you take the action to do it in a further series:

Reviewed-by: Maxime Coquelin 

Thanks,
Maxime





Thanks,
Maxime

Re: [PATCH v5 02/12] baseband/acc: add FFT window width in the VRB PMD

[Maxime Coquelin]

On 10/6/23 09:55, Maxime Coquelin wrote:



On 10/5/23 21:48, Nicolas Chautru wrote:

This allows to expose the FFT window width being introduced in
previous commit based on what is configured dynamically on the
device platform.

Signed-off-by: Nicolas Chautru 
---
  drivers/baseband/acc/acc_common.h  |  6 +
  drivers/baseband/acc/rte_vrb_pmd.c | 41 +-
  2 files changed, 41 insertions(+), 6 deletions(-)

diff --git a/drivers/baseband/acc/acc_common.h 
b/drivers/baseband/acc/acc_common.h

index 5bb00746c3..afece863bc 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -131,6 +131,8 @@
  #define ACC_LIM_31 20 /* 0.31 */
  #define ACC_MAX_E (128 * 1024 - 2)
+#define ACC_MAX_FFT_WIN  16
+
  /* Helper macro for logging */
  #define rte_acc_log(level, fmt, ...) \
  rte_log(RTE_LOG_ ## level, RTE_LOG_NOTICE, fmt "\n", \
@@ -512,6 +514,8 @@ struct acc_deq_intr_details {
  enum {
  ACC_VF2PF_STATUS_REQUEST = 1,
  ACC_VF2PF_USING_VF = 2,
+    ACC_VF2PF_LUT_VER_REQUEST = 3,
+    ACC_VF2PF_FFT_WIN_REQUEST = 4,
  };
@@ -558,6 +562,8 @@ struct acc_device {
  queue_offset_fun_t queue_offset;  /* Device specific queue 
offset */

  uint16_t num_qgroups;
  uint16_t num_aqs;
+    uint16_t fft_window_width[ACC_MAX_FFT_WIN]; /* FFT windowing 
size. */

+


Remove new line.


  };
  /* Structure associated with each queue. */
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c

index 9e5a73c9c7..b86e814f8f 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -183,6 +183,37 @@ vrb_check_device_enable(struct rte_bbdev *dev)
  return false;
  }
+static inline void
+vrb_vf2pf(struct acc_device *d, unsigned int payload)
+{
+    acc_reg_write(d, d->reg_addr->vf2pf_doorbell, payload);
+}
+
+/* Request device FFT windowing information. */
+static inline void
+vrb_device_fft_win(struct rte_bbdev *dev)
+{
+    struct acc_device *d = dev->data->dev_private;
+    uint32_t reg, time_out = 0, win;
+
+    if (d->pf_device)
+    return;
+
+    /* Check from the device the first time. */
+    if (d->fft_window_width[0] == 0) {
+    for (win = 0; win < ACC_MAX_FFT_WIN; win++) {
+    vrb_vf2pf(d, ACC_VF2PF_FFT_WIN_REQUEST | win);
+    reg = acc_reg_read(d, d->reg_addr->pf2vf_doorbell);
+    while ((time_out < ACC_STATUS_TO) && (reg == 
RTE_BBDEV_DEV_NOSTATUS)) {
+    usleep(ACC_STATUS_WAIT); /*< Wait or VF->PF->VF 
Comms. */

+    reg = acc_reg_read(d, d->reg_addr->pf2vf_doorbell);
+    time_out++;
+    }
+    d->fft_window_width[win] = reg;
+    }
+    }
+}
+
  /* Fetch configuration enabled for the PF/VF using MMIO Read (slow). */
  static inline void
  fetch_acc_config(struct rte_bbdev *dev)
@@ -206,6 +237,8 @@ fetch_acc_config(struct rte_bbdev *dev)
  return;
  }
+    vrb_device_fft_win(dev);
+
  d->ddr_size = 0;
  /* Single VF Bundle by VF. */
@@ -271,12 +304,6 @@ fetch_acc_config(struct rte_bbdev *dev)
  acc_conf->q_fft.aq_depth_log2);
  }
-static inline void
-vrb_vf2pf(struct acc_device *d, unsigned int payload)
-{
-    acc_reg_write(d, d->reg_addr->vf2pf_doorbell, payload);
-}
-
  /* Request device status information. */
  static inline uint32_t
  vrb_device_status(struct rte_bbdev *dev)
@@ -1085,6 +1112,7 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)

  RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
  .num_buffers_dst =
  RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+    .fft_windows_num = ACC_MAX_FFT_WIN,
  }
  },
  RTE_BBDEV_END_OF_CAPABILITIES_LIST()
@@ -1100,6 +1128,7 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)

  fetch_acc_config(dev);
  /* Check the status of device. */
  dev_info->device_status = vrb_device_status(dev);
+    dev_info->fft_window_width = d->fft_window_width;
  /* Exposed number of queues. */
  dev_info->num_queues[RTE_BBDEV_OP_NONE] = 0;


With new line removed:

Reviewed-by; Maxime Coquelin 


With typo fixed to make patchwork happy:
Reviewed-by: Maxime Coquelin 



Thanks,
Maxime

Re: [PATCH v3] vhost: add IRQ suppression

[David Marchand]

On Fri, Sep 29, 2023 at 12:38 PM Maxime Coquelin
 wrote:
>
> Guest notifications offloading, which has been introduced
> in v23.07, aims at offloading syscalls out of the datapath.
>
> This patch optimizes the offloading by not offloading the
> guest notification for a given virtqueue if one is already
> being offloaded by the application.
>
> With a single VDUSE device, we can already see few
> notifications being suppressed when doing throughput
> testing with Iperf3. We can expect to see much more being
> suppressed when the offloading thread is under pressure.
>
> Signed-off-by: Maxime Coquelin 

This looks like a good idea.
Reviewed-by: David Marchand 


-- 
David Marchand

Re: [PATCH v6 1/3] eal: add x86 cpuid support for monitorx

[David Marchand]

On Mon, Oct 9, 2023 at 6:24 PM Patrick Robb  wrote:
>
> Recheck-request: iol-unit-amd64-testing
>
> Failed for service_autotest on windows. I'm doing a retest to see if it's 
> reproducible.

Thanks for checking.
This unit test has never been entirely reliable... I see the rerun was fine.
I'll go ahead with this series.


-- 
David Marchand

Re: [PATCH v6 3/3] power: amd power monitor support

[David Marchand]

Hello Siva,

On Mon, Oct 9, 2023 at 4:06 PM Sivaprasad Tummala
 wrote:
>
> mwaitx allows EPYC processors to enter a implementation dependent
> power/performance optimized state (C1 state) for a specific period
> or until a store to the monitored address range.
>
> Signed-off-by: Sivaprasad Tummala 
> Acked-by: Anatoly Burakov 
> ---

Please put some changelog to make life easier for reviewers (and me).

I diffed with the previous version to check what had been changed and
I see this:

 static void amd_mwaitx(const uint64_t timeout)
...
-   "c"(2), /* enable timer */
-   "b"(timeout));
+   "c"(0)); /* no time-out */

I will take this series as is, but please confirm why this change was needed.


>  lib/eal/x86/rte_power_intrinsics.c | 108 ++---
>  1 file changed, 84 insertions(+), 24 deletions(-)
>
> diff --git a/lib/eal/x86/rte_power_intrinsics.c 
> b/lib/eal/x86/rte_power_intrinsics.c
> index 664cde01e9..0d2953f570 100644
> --- a/lib/eal/x86/rte_power_intrinsics.c
> +++ b/lib/eal/x86/rte_power_intrinsics.c
> @@ -17,6 +17,78 @@ static struct power_wait_status {
> volatile void *monitor_addr; /**< NULL if not currently sleeping */
>  } __rte_cache_aligned wait_status[RTE_MAX_LCORE];
>
> +/**
> + * This functions uses UMONITOR/UMWAIT instructions and will enter C0.2 
> state.

Fixed while applying, function*

> + * For more information about usage of these instructions, please refer to
> + * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
> + */
> +static void intel_umonitor(volatile void *addr)
> +{
> +#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
> +   /* cast away "volatile" when using the intrinsic */
> +   _umonitor((void *)(uintptr_t)addr);
> +#else
> +   /*
> +* we're using raw byte codes for compiler versions which
> +* don't support this instruction natively.
> +*/
> +   asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
> +   :
> +   : "D"(addr));
> +#endif
> +}
> +
> +static void intel_umwait(const uint64_t timeout)
> +{
> +   const uint32_t tsc_l = (uint32_t)timeout;
> +   const uint32_t tsc_h = (uint32_t)(timeout >> 32);
> +#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
> +   _umwait(tsc_l, tsc_h);
> +#else
> +   asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
> +   : /* ignore rflags */
> +   : "D"(0), /* enter C0.2 */
> + "a"(tsc_l), "d"(tsc_h));
> +#endif
> +}
> +
> +/**
> + * This functions uses MONITORX/MWAITX instructions and will enter C1 state.
> + * For more information about usage of these instructions, please refer to
> + * AMD64 Architecture Programmer’s Manual.
> + */
> +static void amd_monitorx(volatile void *addr)
> +{
> +#if defined(__MWAITX__)

This part probably breaks build with MSVC.

I could not determine whether MSVC supports this intrinsic.
I'll rely on Tyler to fix it later.


Series applied.

-- 
David Marchand

Re: [PATCH v4 09/12] baseband/acc: add FFT support to VRB2 variant

[Maxime Coquelin]

On 10/5/23 04:18, Nicolas Chautru wrote:

Support for the FFT the processing specific to the
VRB2 variant.

Signed-off-by: Nicolas Chautru 
---
  drivers/baseband/acc/rte_vrb_pmd.c | 137 +++--
  1 file changed, 129 insertions(+), 8 deletions(-)



Reviewed-by: Maxime Coquelin 

Maxime

RE: [PATCH 1/5] net/mlx5/hws: add support for matching on bth_a bit

[Raslan Darawsheh]

Hi,

> -Original Message-
> From: Itamar Gozlan 
> Sent: Monday, September 18, 2023 3:07 PM
> To: Alex Vesker ; Slava Ovsiienko
> ; NBU-Contact-Thomas Monjalon (EXTERNAL)
> ; Suanming Mou ; Matan
> Azrad ; Ori Kam 
> Cc: dev@dpdk.org
> Subject: [PATCH 1/5] net/mlx5/hws: add support for matching on bth_a bit
> 
> RTE_FLOW_ITEM_TYPE_IB_BTH matches an InfiniBand base transport header.
> We extend the match on the acknowledgment bit (BTH_A).
> 
> Signed-off-by: Itamar Gozlan 

Series applied to next-net-mlx,

Kindest regards,
Raslan Darawsheh

Re: [PATCH v3] power: support amd-pstate cpufreq driver

[David Marchand]

On Mon, Oct 9, 2023 at 4:55 PM Sivaprasad Tummala
 wrote:
>
> amd-pstate introduces a new CPU frequency control mechanism for AMD
> EPYC processors using the ACPI Collaborative Performance Power Control
> feature for a finer grained frequency management.
>
> Patch to add support for amd-pstate driver.
>
> Signed-off-by: Sivaprasad Tummala 
> Acked-by: Anatoly Burakov 

Applied, thanks.


-- 
David Marchand

Re: [PATCH] random: clarify PRNG MT safety guarantees

[David Marchand]

On Wed, Oct 4, 2023 at 2:06 PM Morten Brørup  wrote:
>
> > From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com]
> > Sent: Wednesday, 4 October 2023 12.55
> random: clarify PRNG MT safety guarantees
> >
> > Clarify MT safety guarantees for unregistered non-EAL threads calling
> > PRNG functions in rte_random.h.
> >
> > Clarify that rte_srand() is not MT safe in regards to calls to
> > rte_rand_max() and rte_drand().
> >
> > Suggested-by: Stephen Hemminger 
> > Signed-off-by: Mattias Rönnblom 
> Acked-by: Morten Brørup 

Applied, thanks Mattias.


-- 
David Marchand

Re: [PATCH v3] hash: fix SSE comparison

[David Marchand]

On Mon, Oct 9, 2023 at 4:33 PM Bruce Richardson
 wrote:
>
> On Sat, Oct 07, 2023 at 03:36:34PM +0800, Jieqiang Wang wrote:
> > __mm_cmpeq_epi16 returns 0x if the corresponding 16-bit elements are
> > equal. In original SSE2 implementation for function compare_signatures,
> > it utilizes _mm_movemask_epi8 to create mask from the MSB of each 8-bit
> > element, while we should only care about the MSB of lower 8-bit in each
> > 16-bit element.
> > For example, if the comparison result is all equal, SSE2 path returns
> > 0x while NEON and default scalar path return 0x.
> > Although this bug is not causing any negative effects since the caller
> > function solely examines the trailing zeros of each match mask, we
> > recommend this fix to ensure consistency with NEON and default scalar
> > code behaviors.
> >
> > Fixes: c7d93df552c2 ("hash: use partial-key hashing")
> > Cc: sta...@dpdk.org
> >
> > v2:
> > 1. Utilize scalar mask instead of vector mask to save extra loads (Bruce)
> >
> > v3:
> > 1. Fix coding style warnings

Changelog and other notes on a patch should not be in the commitlog
itself, but should go after ---.
https://doc.dpdk.org/guides/contributing/patches.html#creating-patches


> >
> > Signed-off-by: Feifei Wang 
> > Signed-off-by: Jieqiang Wang 
> > Reviewed-by: Ruifeng Wang 
> Acked-by: Bruce Richardson 

Applied, thanks Jieqiang and Bruce.


-- 
David Marchand

Re: [PATCH] ethdev: remove init_color from METER_MARK action

[Ferruh Yigit]

On 8/8/2023 11:00 AM, Gregory Etelson wrote:
> Indirect list API defines 2 types of action update:
> • Action mutable context is always shared between all flows
>   that referenced indirect actions list handle.
>   Action mutable context can be changed by explicit invocation
>   of indirect handle update function.
> • Flow mutable context is private to a flow.
>   Flow mutable context can be updated by indirect list handle
>   flow rule configuration.
> 
> `METER_MARK::init_color` is flow resource.
> Current flows implementation placed `init_color` in the
> `rte_flow_action_meter_mark` making it action level resource.
> 
> The patch removes `init_color` from the `rte_flow_action_meter_mark`
> structure.
> 
> API change:
> The patch removed:
> • struct rte_flow_action_meter_mark::init_color
> 
> • struct rte_flow_update_meter_mark::init_color_valid
> 
> Signed-off-by: Gregory Etelson 
> 


Ori, et al.,
mechanics of the patches looks good, and mlx is the only user,
if there is no objection it will be merged in a few days.

Re: [RFC PATCH] ethdev: introduce NAT64 action

[Ferruh Yigit]

On 9/21/2023 4:45 PM, Ferruh Yigit wrote:
> On 9/19/2023 11:05 AM, Ori Kam wrote:
>> Hi Bing
>>
>>> -Original Message-
>>> From: Bing Zhao 
>>> Sent: Friday, August 11, 2023 5:07 PM
>>> Subject: [RFC PATCH] ethdev: introduce NAT64 action
>>>
>>> In order to support the communication between IPv4 and IPv6 nodes in
>>> the network, different technologies are used, like dual-stacks,
>>> tunneling and NAT64. In some IPv4-only clients, it is hard to deploy
>>> new software and hardware to support IPv6.
>>>
>>> NAT64 is a choice and it will also reduce the unnecessary overhead of
>>> the traffic in the network. The NAT64 gateways take the
>>> responsibility of the packet headers translation between the IPv6
>>> clouds and IPv4-only clouds.
>>>
>>> This action should support the offloading of the IP headers'
>>> translation. The following fields should be reset correctly in the
>>> translation.
>>>   - Version
>>>   - Traffic Class / TOS
>>>   - Flow Label (0 in v4)
>>>   - Payload Length / Total length
>>>   - Next Header
>>>   - Hop Limit / TTL
>>>
>>> Since there are different mapping and translating modes of the
>>> addresses, it will depend on the capabilities of each vendor.
>>>
>>> The ICMP* and transport layers protocol is out of the scope of NAT64
>>> rte_flow action.
>>>
>>> Reference links:
>>>   - https://datatracker.ietf.org/doc/html/rfc6146
>>>   - https://datatracker.ietf.org/doc/html/rfc6052
>>>   - https://datatracker.ietf.org/doc/html/rfc6145
>>>
>>> Signed-off-by: Bing Zhao 
>>> ---
>>
>> Acked-by: Ori Kam 
>>
> 
> Hi Bing,
> 
> This is a RFC, but we are not having more comment & objection, so what
> do you think to continue with a patch including testpmd implementation?
> 
> 

Hi Bing, what is the latest status of the patch?

[PATCH] gpu/cuda: add PCI device ID for NVIDIA TU102GL [Quadro RTX 6000/8000]

[Levend Sayar]

PCI device ID is added for NVIDIA TU102GL [Quadro RTX 6000/8000]
GPU card.

Signed-off-by: Levend Sayar 
---
 drivers/gpu/cuda/cuda.c| 4 
 drivers/gpu/cuda/devices.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/cuda/cuda.c b/drivers/gpu/cuda/cuda.c
index a552aabeb8..00133696d7 100644
--- a/drivers/gpu/cuda/cuda.c
+++ b/drivers/gpu/cuda/cuda.c
@@ -203,6 +203,10 @@ static const struct rte_pci_id pci_id_cuda_map[] = {
RTE_PCI_DEVICE(NVIDIA_GPU_VENDOR_ID,
NVIDIA_GPU_QUADRO_RTX_8000)
},
+   {
+   RTE_PCI_DEVICE(NVIDIA_GPU_VENDOR_ID,
+   NVIDIA_GPU_QUADRO_RTX_8000_2)
+   },
{
RTE_PCI_DEVICE(NVIDIA_GPU_VENDOR_ID,
NVIDIA_GPU_QUADRO_RTX_A4000)
diff --git a/drivers/gpu/cuda/devices.h b/drivers/gpu/cuda/devices.h
index e6502910f3..94e4ee218c 100644
--- a/drivers/gpu/cuda/devices.h
+++ b/drivers/gpu/cuda/devices.h
@@ -54,6 +54,7 @@
 #define NVIDIA_GPU_QUADRO_RTX_5000 (0x1eb0)
 #define NVIDIA_GPU_QUADRO_RTX_6000 (0x13d9)
 #define NVIDIA_GPU_QUADRO_RTX_8000 (0x13d8)
+#define NVIDIA_GPU_QUADRO_RTX_8000_2 (0x1e30)
 #define NVIDIA_GPU_QUADRO_RTX_A4000 (0x24b0)
 #define NVIDIA_GPU_QUADRO_RTX_A6000 (0x2230)
 #define NVIDIA_GPU_QUADRO_RTX_A5000 (0x2231)
-- 
2.39.3 (Apple Git-145)

Re: [PATCH] gpu/cuda: add PCI device ID for NVIDIA TU102GL [Quadro RTX 6000/8000]

[Elena Agostini]

Sounds good to me

Thanks
EA

From: Levend Sayar 
Sent: Tuesday, October 10, 2023 12:02
To: Elena Agostini 
Cc: dev@dpdk.org ; Levend Sayar 
Subject: [PATCH] gpu/cuda: add PCI device ID for NVIDIA TU102GL [Quadro RTX 
6000/8000]


PCI device ID is added for NVIDIA TU102GL [Quadro RTX 6000/8000]
GPU card.

Signed-off-by: Levend Sayar 
---
 drivers/gpu/cuda/cuda.c| 4 
 drivers/gpu/cuda/devices.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/cuda/cuda.c b/drivers/gpu/cuda/cuda.c
index a552aabeb8..00133696d7 100644
--- a/drivers/gpu/cuda/cuda.c
+++ b/drivers/gpu/cuda/cuda.c
@@ -203,6 +203,10 @@ static const struct rte_pci_id pci_id_cuda_map[] = {
RTE_PCI_DEVICE(NVIDIA_GPU_VENDOR_ID,
NVIDIA_GPU_QUADRO_RTX_8000)
},
+   {
+   RTE_PCI_DEVICE(NVIDIA_GPU_VENDOR_ID,
+   NVIDIA_GPU_QUADRO_RTX_8000_2)
+   },
{
RTE_PCI_DEVICE(NVIDIA_GPU_VENDOR_ID,
NVIDIA_GPU_QUADRO_RTX_A4000)
diff --git a/drivers/gpu/cuda/devices.h b/drivers/gpu/cuda/devices.h
index e6502910f3..94e4ee218c 100644
--- a/drivers/gpu/cuda/devices.h
+++ b/drivers/gpu/cuda/devices.h
@@ -54,6 +54,7 @@
 #define NVIDIA_GPU_QUADRO_RTX_5000 (0x1eb0)
 #define NVIDIA_GPU_QUADRO_RTX_6000 (0x13d9)
 #define NVIDIA_GPU_QUADRO_RTX_8000 (0x13d8)
+#define NVIDIA_GPU_QUADRO_RTX_8000_2 (0x1e30)
 #define NVIDIA_GPU_QUADRO_RTX_A4000 (0x24b0)
 #define NVIDIA_GPU_QUADRO_RTX_A6000 (0x2230)
 #define NVIDIA_GPU_QUADRO_RTX_A5000 (0x2231)
--
2.39.3 (Apple Git-145)

Re: [PATCH v6 3/3] power: amd power monitor support

[Konstantin Ananyev]

09.10.2023 15:05, Sivaprasad Tummala пишет:

mwaitx allows EPYC processors to enter a implementation dependent
power/performance optimized state (C1 state) for a specific period
or until a store to the monitored address range.

Signed-off-by: Sivaprasad Tummala 
Acked-by: Anatoly Burakov 
---
  lib/eal/x86/rte_power_intrinsics.c | 108 ++---
  1 file changed, 84 insertions(+), 24 deletions(-)

diff --git a/lib/eal/x86/rte_power_intrinsics.c 
b/lib/eal/x86/rte_power_intrinsics.c
index 664cde01e9..0d2953f570 100644
--- a/lib/eal/x86/rte_power_intrinsics.c
+++ b/lib/eal/x86/rte_power_intrinsics.c
@@ -17,6 +17,78 @@ static struct power_wait_status {
volatile void *monitor_addr; /**< NULL if not currently sleeping */
  } __rte_cache_aligned wait_status[RTE_MAX_LCORE];
  
+/**

+ * This functions uses UMONITOR/UMWAIT instructions and will enter C0.2 state.
+ * For more information about usage of these instructions, please refer to
+ * Intel(R) 64 and IA-32 Architectures Software Developer's Manual.
+ */
+static void intel_umonitor(volatile void *addr)
+{
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+   /* cast away "volatile" when using the intrinsic */
+   _umonitor((void *)(uintptr_t)addr);
+#else
+   /*
+* we're using raw byte codes for compiler versions which
+* don't support this instruction natively.
+*/
+   asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
+   :
+   : "D"(addr));
+#endif
+}
+
+static void intel_umwait(const uint64_t timeout)
+{
+   const uint32_t tsc_l = (uint32_t)timeout;
+   const uint32_t tsc_h = (uint32_t)(timeout >> 32);
+#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
+   _umwait(tsc_l, tsc_h);
+#else
+   asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
+   : /* ignore rflags */
+   : "D"(0), /* enter C0.2 */
+ "a"(tsc_l), "d"(tsc_h));
+#endif
+}
+
+/**
+ * This functions uses MONITORX/MWAITX instructions and will enter C1 state.
+ * For more information about usage of these instructions, please refer to
+ * AMD64 Architecture Programmer’s Manual.
+ */
+static void amd_monitorx(volatile void *addr)
+{
+#if defined(__MWAITX__)
+   /* cast away "volatile" when using the intrinsic */
+   _mm_monitorx((void *)(uintptr_t)addr, 0, 0);
+#else
+   asm volatile(".byte 0x0f, 0x01, 0xfa;"
+   :
+   : "a"(addr),
+   "c"(0),  /* no extensions */
+   "d"(0)); /* no hints */
+#endif
+}
+
+static void amd_mwaitx(const uint64_t timeout)
+{
+   RTE_SET_USED(timeout);
+#if defined(__MWAITX__)
+   _mm_mwaitx(0, 0, 0);
+#else
+   asm volatile(".byte 0x0f, 0x01, 0xfb;"
+   : /* ignore rflags */
+   : "a"(0), /* enter C1 */
+   "c"(0)); /* no time-out */
+#endif
+}
+
+static struct {
+   void (*mmonitor)(volatile void *addr);
+   void (*mwait)(const uint64_t timeout);
+} __rte_cache_aligned power_monitor_ops;
+
  static inline void
  __umwait_wakeup(volatile void *addr)
  {
@@ -76,8 +148,6 @@ int
  rte_power_monitor(const struct rte_power_monitor_cond *pmc,
const uint64_t tsc_timestamp)
  {
-   const uint32_t tsc_l = (uint32_t)tsc_timestamp;
-   const uint32_t tsc_h = (uint32_t)(tsc_timestamp >> 32);
const unsigned int lcore_id = rte_lcore_id();
struct power_wait_status *s;
uint64_t cur_value;
@@ -105,19 +175,8 @@ rte_power_monitor(const struct rte_power_monitor_cond *pmc,
rte_spinlock_lock(&s->lock);
s->monitor_addr = pmc->addr;
  
-	/* set address for UMONITOR */

-#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
-   /* cast away "volatile" when using the intrinsic */
-   _umonitor((void *)(uintptr_t)pmc->addr);
-#else
-   /*
-* we're using raw byte codes for compiler versions which
-* don't support this instruction natively.
-*/
-   asm volatile(".byte 0xf3, 0x0f, 0xae, 0xf7;"
-   :
-   : "D"(pmc->addr));
-#endif
+   /* set address for memory monitor */
+   power_monitor_ops.mmonitor(pmc->addr);
  
  	/* now that we've put this address into monitor, we can unlock */

rte_spinlock_unlock(&s->lock);
@@ -128,15 +187,8 @@ rte_power_monitor(const struct rte_power_monitor_cond *pmc,
if (pmc->fn(cur_value, pmc->opaque) != 0)
goto end;
  
-	/* execute UMWAIT */

-#if defined(RTE_TOOLCHAIN_MSVC) || defined(__WAITPKG__)
-   _umwait(tsc_l, tsc_h);
-#else
-   asm volatile(".byte 0xf2, 0x0f, 0xae, 0xf7;"
-   : /* ignore rflags */
-   : "D"(0), /* enter C0.2 */
- "a"(tsc_l), "d"(tsc_h));
-#endif
+   /* execute mwait */
+   power_monitor_ops.mwait(tsc_timestamp);
  
  end:

/

Re: [PATCH v2] ethdev: add TCP/IP modify field IDs

[Ferruh Yigit]

On 9/8/2023 4:49 AM, Suanming Mou wrote:
> Currently, get TCP/IP header or data length information from traffic
> is missing in the modify field IDs. This commit adds the missing
> TCP data_offset, IPv4 IHL/total_len, IPv6 payload_len to modify filed
> IDs. This allows users be able to manager more TCP/IP fields.
> 
> Signed-off-by: Suanming Mou 
> ---
> 
> v2: fix typo tcp_date_off -> tcp_data_off
> 
> ---
>  app/test-pmd/cmdline_flow.c | 1 +
>  lib/ethdev/rte_flow.h   | 4 
>  2 files changed, 5 insertions(+)
> 
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index 94827bcc4a..310068ce88 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -937,6 +937,7 @@ static const char *const modify_field_ids[] = {
>   "flex_item",
>   "hash_result",
>   "geneve_opt_type", "geneve_opt_class", "geneve_opt_data", "mpls",
> + "tcp_data_off", "ipv4_ihl", "ipv4_total_len", "ipv6_payload_len",
>   NULL
>  };
>  
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index 2ebb76dbc0..43ba51da6e 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -3875,6 +3875,10 @@ enum rte_flow_field_id {
>   RTE_FLOW_FIELD_GENEVE_OPT_CLASS,/**< GENEVE option class. */
>   RTE_FLOW_FIELD_GENEVE_OPT_DATA, /**< GENEVE option data. */
>   RTE_FLOW_FIELD_MPLS,/**< MPLS header. */
> + RTE_FLOW_FIELD_TCP_DATA_OFFSET, /**< TCP data offset. */
> + RTE_FLOW_FIELD_IPV4_IHL,/**< IPv4 IHL. */
> + RTE_FLOW_FIELD_IPV4_TOTAL_LEN,  /**< IPv4 total length. */
> + RTE_FLOW_FIELD_IPV6_PAYLOAD_LEN /**< IPv6 payload length. */
>  };
>  
>  /**

Hi Suanming,

Patch looks good. But, testpmd modify flow action support seems not
documented at all, can you please first add it [1], later update that
document with this patch?

Also can you please check if `rte_flow.rst` also needs to be updated or not?


[1]: `doc/guides/testpmd_app_ug/testpmd_funcs.rst`, `Flow rules
management` section

[PATCH v4 1/2] security: add fallback security processing and Rx inject

[Anoob Joseph]

Add alternate datapath API for security processing which would do Rx
injection (similar to loopback) after successful security processing.

With inline protocol offload, variable part of the session context
(AR windows, lifetime etc in case of IPsec), is not accessible to the
application. If packets are not getting processed in the inline path
due to non security reasons (such as outer fragmentation or rte_flow
packet steering limitations), then the packet cannot be security
processed as the session context is private to the PMD and security
library doesn't provide alternate APIs to make use of the same session.

Introduce new API and Rx injection as fallback mechanism to security
processing failures due to non-security reasons. For example, when there
is outer fragmentation and PMD doesn't support reassembly of outer
fragments, application would receive fragments which it can then
reassemble. Post successful reassembly, packet can be submitted for
security processing and Rx inject. The packets can be then received in
the application as normal inline protocol processed packets.

Same API can be leveraged in lookaside protocol offload mode to inject
packet to Rx. This would help in using rte_flow based packet parsing
after security processing. For example, with IPsec, this will help in
flow splitting after IPsec processing is done.

In both inline protocol capable ethdevs and lookaside protocol capable
cryptodevs, the packet would be received back in eth port & queue based
on rte_flow rules and packet parsing after security processing. The API
would behave like a loopback but with the additional security
processing.

Signed-off-by: Anoob Joseph 
Signed-off-by: Vidya Sagar Velumuri 
Acked-by: Akhil Goyal 
---
v4:
Updated release notes

v3:
* Resolved compilation error with 32 bit build

v2:
* Added a new API for configuring security device to do Rx inject to a specific
  ethdev port
* Rebased

 doc/guides/cryptodevs/features/default.ini |  1 +
 doc/guides/rel_notes/release_23_11.rst | 19 +
 lib/cryptodev/rte_cryptodev.h  |  2 +
 lib/security/rte_security.c| 22 ++
 lib/security/rte_security.h| 85 ++
 lib/security/rte_security_driver.h | 44 +++
 lib/security/version.map   |  3 +
 7 files changed, 176 insertions(+)

diff --git a/doc/guides/cryptodevs/features/default.ini 
b/doc/guides/cryptodevs/features/default.ini
index 6f637fa7e2..f411d4bab7 100644
--- a/doc/guides/cryptodevs/features/default.ini
+++ b/doc/guides/cryptodevs/features/default.ini
@@ -34,6 +34,7 @@ Sym raw data path API  =
 Cipher multiple data units =
 Cipher wrapped key =
 Inner checksum =
+Rx inject  =
 
 ;
 ; Supported crypto algorithms of a default crypto driver.
diff --git a/doc/guides/rel_notes/release_23_11.rst 
b/doc/guides/rel_notes/release_23_11.rst
index be51f00dbf..6853c907c9 100644
--- a/doc/guides/rel_notes/release_23_11.rst
+++ b/doc/guides/rel_notes/release_23_11.rst
@@ -107,6 +107,25 @@ New Features
   enhancements to ``rte_crypto_op`` fields to handle all datapath requirements
   of TLS and DTLS. The support is added for TLS 1.2, TLS 1.3 and DTLS 1.2.
 
+* **Added support for rte_security Rx inject API.**
+
+  Added Rx inject API to allow applications to submit packets for protocol
+  offload and have them injected back to ethdev Rx so that further ethdev Rx
+  actions (IP reassembly, packet parsing and flow lookups) can happen based on
+  inner packet.
+
+  The API when implemented by an ethdev, may be used to process packets that 
the
+  application wants to process with inline protocol offload enabled 
rte_security
+  session. These can be packets that are received from other non-inline capable
+  ethdevs or can be packets that failed inline protocol offload (such as
+  receiving fragmented ESP packets in case of inline IPsec offload).
+
+  The API when implemented by a cryptodev, can be used for injecting packets to
+  ethdev Rx after IPsec processing and take advantage of ethdev Rx processing
+  for the inner packet. The API helps application to avail ethdev Rx actions
+  based on inner packet while working with rte_security sessions which cannot
+  be accelerated in inline protocol offload mode.
+
 * **Updated ipsec_mb crypto driver.**
 
   Added support for digest encrypted to AESNI_MB asynchronous crypto driver.
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 6c8f532797..be0698ce9f 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -559,6 +559,8 @@ rte_cryptodev_asym_get_xform_string(enum 
rte_crypto_asym_xform_type xform_enum);
 /**< Support wrapped key in cipher xform  */
 #define RTE_CRYPTODEV_FF_SECURITY_INNER_CSUM   (1ULL << 27)
 /**< Support inner checksum computation/verification */
+#define RTE_CRYPTODEV_FF_SECURITY_RX_INJECT(1ULL << 28)
+/**< Support Rx injection after security processing */
 
 /*

[PATCH v4 2/2] test/cryptodev: add Rx inject test

[Anoob Joseph]

From: Vidya Sagar Velumuri 

Add test to verify Rx inject. The test case added would push a known
vector to cryptodev which would be injected to ethdev Rx. The test
case verifies that the packet is received from ethdev Rx and is
processed successfully. It also verifies that the userdata matches with
the expectation.

Signed-off-by: Anoob Joseph 
Signed-off-by: Vidya Sagar Velumuri 
Acked-by: Akhil Goyal 
---
 app/test/test_cryptodev.c| 340 +++
 app/test/test_cryptodev_security_ipsec.h |   1 +
 2 files changed, 288 insertions(+), 53 deletions(-)

diff --git a/app/test/test_cryptodev.c b/app/test/test_cryptodev.c
index f2112e181e..b645cb32f1 100644
--- a/app/test/test_cryptodev.c
+++ b/app/test/test_cryptodev.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1426,6 +1427,93 @@ ut_setup_security(void)
return dev_configure_and_start(0);
 }
 
+static int
+ut_setup_security_rx_inject(void)
+{
+   struct rte_mempool *mbuf_pool = rte_mempool_lookup("CRYPTO_MBUFPOOL");
+   struct crypto_testsuite_params *ts_params = &testsuite_params;
+   struct rte_eth_conf port_conf = {
+   .rxmode = {
+   .offloads = RTE_ETH_RX_OFFLOAD_CHECKSUM |
+   RTE_ETH_RX_OFFLOAD_SECURITY,
+   },
+   .txmode = {
+   .offloads = RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE,
+   },
+   .lpbk_mode = 1,  /* Enable loopback */
+   };
+   struct rte_cryptodev_info dev_info;
+   struct rte_eth_rxconf rx_conf = {
+   .rx_thresh = {
+   .pthresh = 8,
+   .hthresh = 8,
+   .wthresh = 8,
+   },
+   .rx_free_thresh = 32,
+   };
+   uint16_t nb_ports;
+   void *sec_ctx;
+   int ret;
+
+   rte_cryptodev_info_get(ts_params->valid_devs[0], &dev_info);
+   if (!(dev_info.feature_flags & RTE_CRYPTODEV_FF_SECURITY_RX_INJECT) ||
+   !(dev_info.feature_flags & RTE_CRYPTODEV_FF_SECURITY)) {
+   RTE_LOG(INFO, USER1,
+   "Feature requirements for IPsec Rx inject test case not 
met\n");
+   return TEST_SKIPPED;
+   }
+
+   sec_ctx = rte_cryptodev_get_sec_ctx(ts_params->valid_devs[0]);
+   if (sec_ctx == NULL)
+   return TEST_SKIPPED;
+
+   nb_ports = rte_eth_dev_count_avail();
+   if (nb_ports == 0)
+   return TEST_SKIPPED;
+
+   ret = rte_eth_dev_configure(0 /* port_id */,
+   1 /* nb_rx_queue */,
+   0 /* nb_tx_queue */,
+   &port_conf);
+   if (ret) {
+   printf("Could not configure ethdev port 0 [err=%d]\n", ret);
+   return TEST_SKIPPED;
+   }
+
+   /* Rx queue setup */
+   ret = rte_eth_rx_queue_setup(0 /* port_id */,
+0 /* rx_queue_id */,
+1024 /* nb_rx_desc */,
+SOCKET_ID_ANY,
+&rx_conf,
+mbuf_pool);
+   if (ret) {
+   printf("Could not setup eth port 0 queue 0\n");
+   return TEST_SKIPPED;
+   }
+
+   ret = rte_security_rx_inject_configure(sec_ctx, 0, true);
+   if (ret) {
+   printf("Could not enable Rx inject offload");
+   return TEST_SKIPPED;
+   }
+
+   ret = rte_eth_dev_start(0);
+   if (ret) {
+   printf("Could not start ethdev");
+   return TEST_SKIPPED;
+   }
+
+   ret = rte_eth_promiscuous_enable(0);
+   if (ret) {
+   printf("Could not enable promiscuous mode");
+   return TEST_SKIPPED;
+   }
+
+   /* Configure and start cryptodev with no features disabled */
+   return dev_configure_and_start(0);
+}
+
 void
 ut_teardown(void)
 {
@@ -1478,6 +1566,33 @@ ut_teardown(void)
rte_cryptodev_stop(ts_params->valid_devs[0]);
 }
 
+static void
+ut_teardown_rx_inject(void)
+{
+   struct crypto_testsuite_params *ts_params = &testsuite_params;
+   void *sec_ctx;
+   int ret;
+
+   if  (rte_eth_dev_count_avail() != 0) {
+   ret = rte_eth_dev_reset(0);
+   if (ret)
+   printf("Could not reset eth port 0");
+
+   }
+
+   ut_teardown();
+
+   sec_ctx = rte_cryptodev_get_sec_ctx(ts_params->valid_devs[0]);
+   if (sec_ctx == NULL)
+   return;
+
+   ret = rte_security_rx_inject_configure(sec_ctx, 0, false);
+   if (ret) {
+   printf("Could not disable Rx inject offload");
+   return;
+   }
+}
+
 static int
 test_device_configure_invalid_dev_id(void)
 {
@@ -9875,6 +9990,136 @@ ext_mbuf_create(struct rte_mempool *mbuf_pool, int 
pkt_len,
  

Re: [PATCH v4] app/testpmd: enable cli for programmable action

[Ferruh Yigit]

On 10/7/2023 11:47 AM, Qi Zhang wrote:
> Parsing command line for rte_flow_action_prog.
> 
> Syntax:
> 
> "prog name  [arguments   \
>... end]"
> 

Can you please put full rte flow command in the commit log? Like what is
the 'pattern' for above command?


> Use parse_string0 to parse name string.
> Use parse_hex to parse hex string.
> Use struct action_prog_data to store parsed result.
> 
> Example:
> 
> Action with 2 arguments:
> 
> "prog name action0 arguments field0 03FF field1 55AA end"
> 
> Action without argument:
> 
> "prog name action1"
> 
> Signed-off-by: Qi Zhang 
>

Is there an existing driver implementation, checking it helps to
understand feature implementation?


> ---
> 
> v4:
> - be more generous on the max size of name and value.
> 
> v3:
> - refine struct action_prog_data
> - enlarge the max size
> 
> v2:
> - fix title
> - minor coding style refine.
> 
>  app/test-pmd/cmdline_flow.c | 232 
>  1 file changed, 232 insertions(+)
> 

Hi Qi,

Can you please update documentation too,
`doc/guides/testpmd_app_ug/testpmd_funcs.rst`, `Flow rules management`
section.


> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index 21828c144c..ae5556e704 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -719,6 +719,13 @@ enum index {
>   ACTION_IPV6_EXT_PUSH,
>   ACTION_IPV6_EXT_PUSH_INDEX,
>   ACTION_IPV6_EXT_PUSH_INDEX_VALUE,
> + ACTION_PROG,
> + ACTION_PROG_NAME,
> + ACTION_PROG_NAME_STRING,
> + ACTION_PROG_ARGUMENTS,
> + ACTION_PROG_ARG_NAME,
> + ACTION_PROG_ARG_VALUE,
> + ACTION_PROG_ARG_END,
>  };
>  
>  /** Maximum size for pattern in struct rte_flow_item_raw. */
> @@ -749,6 +756,23 @@ struct action_rss_data {
>   uint16_t queue[ACTION_RSS_QUEUE_NUM];
>  };
>  
> +#define ACTION_PROG_NAME_SIZE_MAX 256
> +#define ACTION_PROG_ARG_NUM_MAX 16
> +#define ACTION_PROG_ARG_VALUE_SIZE_MAX 64
> +
> +/** Storage for struct rte_flow_action_prog including external data. */
> +struct action_prog_data {
> + struct rte_flow_action_prog conf;
> + struct {
> + char name[ACTION_PROG_NAME_SIZE_MAX];
> + struct rte_flow_action_prog_argument 
> args[ACTION_PROG_ARG_NUM_MAX];
> + struct {
> + char names[ACTION_PROG_NAME_SIZE_MAX];
> + uint8_t value[ACTION_PROG_ARG_VALUE_SIZE_MAX];
> + } arg_data[ACTION_PROG_ARG_NUM_MAX];
> + } data;
> +};
> +
>  /** Maximum data size in struct rte_flow_action_raw_encap. */
>  #define ACTION_RAW_ENCAP_MAX_DATA 512
>  #define RAW_ENCAP_CONFS_MAX_NUM 8
> @@ -2169,6 +2193,7 @@ static const enum index next_action[] = {
>   ACTION_QUOTA_QU,
>   ACTION_IPV6_EXT_REMOVE,
>   ACTION_IPV6_EXT_PUSH,
> + ACTION_PROG,
>   ZERO,
>  };
>  
> @@ -2510,6 +2535,13 @@ static const enum index action_represented_port[] = {
>   ZERO,
>  };
>  
> +static const enum index action_prog[] = {
> + ACTION_PROG_NAME,
> + ACTION_PROG_ARGUMENTS,
> + ACTION_NEXT,
> + ZERO,
> +};
> +
>  static int parse_set_raw_encap_decap(struct context *, const struct token *,
>const char *, unsigned int,
>void *, unsigned int);
> @@ -2786,6 +2818,18 @@ static int
>  parse_qu_mode_name(struct context *ctx, const struct token *token,
>  const char *str, unsigned int len, void *buf,
>  unsigned int size);
> +static int
> +parse_vc_action_prog(struct context *, const struct token *,
> +  const char *, unsigned int, void *,
> +  unsigned int);
> +static int
> +parse_vc_action_prog_arg_name(struct context *, const struct token *,
> +   const char *, unsigned int, void *,
> +   unsigned int);
> +static int
> +parse_vc_action_prog_arg_value(struct context *, const struct token *,
> +const char *, unsigned int, void *,
> +unsigned int);
>  static int comp_none(struct context *, const struct token *,
>unsigned int, char *, unsigned int);
>  static int comp_boolean(struct context *, const struct token *,
> @@ -7518,6 +7562,48 @@ static const struct token token_list[] = {
>   .args = ARGS(ARGS_ENTRY(struct rte_flow_item_tx_queue,
>   tx_queue)),
>   },
> + [ACTION_PROG] = {
> + .name = "prog",
> + .help = "match a programmable action",
> + .priv = PRIV_ACTION(PROG, sizeof(struct action_prog_data)),
> + .next = NEXT(action_prog),
> + .call = parse_vc_action_prog,
> + },
> + [ACTION_PROG_NAME] = {
> + .name = "name",
> + .help = "programble action name",
>

Can you please remind me again what was the 'name' filed of "struct
rte_flow_action_prog" was for?


> + .

Re: [PATCH v1] app/testpmd: refine encap content

[Ferruh Yigit]

On 8/22/2023 2:13 AM, Zhang, Yuying wrote:
> From: Yuying Zhang 
> 
> Refine vxlan encap content of all protocol headers.
> 
> Fixes: 1960be7d32f8 ("app/testpmd: add VXLAN encap/decap")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Yuying Zhang 
> 

Ori, Aman, ping for review.

Re: [PATCH] ethdev: add calculate hash function

[Ferruh Yigit]

On 9/26/2023 12:37 PM, Ori Kam wrote:
> rte_flow supports insert by index table[1].
> 
> Using the above table, the application can create rules
> that are based on hash.
> For example application can create the following logic in order
> to create load balancing:
> 1. Create insert by index table with 2 rules, that hashes based on dmac
> 2. Insert to index 0 a rule that sends the traffic to port A.
> 3. Insert to index 1 a rule that sends the traffic to port B.
> 
> Let's also assume that before this table, there is a 5 tuple
> match table that jumps to the above table.
> 
> So each packet that matches one of the 5 tuple rules is RSSed
> to port A or B, based on dmac hash.
> 
> The issue arises when there is a miss on the 5 tuple table,
> which resulted due to the packet being the first packet of this flow, or
> fragmented packet or any other reason.
> In this case, the application must calculate what would be the
> hash calculated by the HW so it can send the packet to the correct
> port.
> 
> This new API allows applications to calculate the hash value of a given
> packet for a given table.
> 
> [1] - 
> http://patches.dpdk.org/project/dpdk/patch/20230208030624.78465-2-akozy...@nvidia.com/
> 
> Signed-off-by: Ori Kam 
> ---
>  app/test-pmd/cmdline_flow.c  | 86 +++-
>  app/test-pmd/config.c| 54 ++
>  app/test-pmd/testpmd.h   |  2 +
>  lib/ethdev/rte_flow.c| 21 +
>  lib/ethdev/rte_flow.h| 32 ++
>  lib/ethdev/rte_flow_driver.h |  5 +++
>  lib/ethdev/version.map   |  1 +
>  7 files changed, 200 insertions(+), 1 deletion(-)
> 

This is a new rte_flow API but unfortunately there isn't any
review/comment, at least it is experimental API. If there is no
objection/discussion in next few days, I will merge the feature.

Probably it will be another rte flow feature that only NVIDIA knows and
uses. While mentioned from using, is the driver update for the feature
planned for this release?


Meanwhile, can you please update the documentation, `rte_flow.rst` and
`testpmd_funcs.rst`?
Also can you please rebase on top of latest next-net, this patch
conflicts with merged group set miss action feature.

Re: [PATCH v3] ethdev: add packet type matching item

[Ferruh Yigit]

On 10/9/2023 5:24 PM, Alexander Kozyrev wrote:
> Add RTE_FLOW_ITEM_TYPE_PTYPE to allow matching on
> L2/L3/L4 and tunnel information as defined in mbuf.
> 
> To match on RTE_PTYPE_L4_TCP and RTE_PTYPE_INNER_L4_UDP:
>   flow pattern_template 0 create pattern_template_id 1
> ingress template ptype packet_type mask 0x0f000f00 / end
>   flow queue 0 create 0 template_table 1
> pattern_template 0 actions_template 0
> pattern ptype packet_type is 0x02000100 / end
> actions queue index 1 / end
> 
> Signed-off-by: Alexander Kozyrev 
> Acked-by: Ori Kam 
> 
Applied to dpdk-next-net/main, thanks.

RE: [PATCH] ethdev: add calculate hash function

[Ori Kam]

Hi Ferruh,

> -Original Message-
> From: Ferruh Yigit 
> Sent: Tuesday, October 10, 2023 2:06 PM
> 
> On 9/26/2023 12:37 PM, Ori Kam wrote:
> > rte_flow supports insert by index table[1].
> >
> > Using the above table, the application can create rules
> > that are based on hash.
> > For example application can create the following logic in order
> > to create load balancing:
> > 1. Create insert by index table with 2 rules, that hashes based on dmac
> > 2. Insert to index 0 a rule that sends the traffic to port A.
> > 3. Insert to index 1 a rule that sends the traffic to port B.
> >
> > Let's also assume that before this table, there is a 5 tuple
> > match table that jumps to the above table.
> >
> > So each packet that matches one of the 5 tuple rules is RSSed
> > to port A or B, based on dmac hash.
> >
> > The issue arises when there is a miss on the 5 tuple table,
> > which resulted due to the packet being the first packet of this flow, or
> > fragmented packet or any other reason.
> > In this case, the application must calculate what would be the
> > hash calculated by the HW so it can send the packet to the correct
> > port.
> >
> > This new API allows applications to calculate the hash value of a given
> > packet for a given table.
> >
> > [1] - http://patches.dpdk.org/project/dpdk/patch/20230208030624.78465-2-
> akozy...@nvidia.com/
> >
> > Signed-off-by: Ori Kam 
> > ---
> >  app/test-pmd/cmdline_flow.c  | 86
> +++-
> >  app/test-pmd/config.c| 54 ++
> >  app/test-pmd/testpmd.h   |  2 +
> >  lib/ethdev/rte_flow.c| 21 +
> >  lib/ethdev/rte_flow.h| 32 ++
> >  lib/ethdev/rte_flow_driver.h |  5 +++
> >  lib/ethdev/version.map   |  1 +
> >  7 files changed, 200 insertions(+), 1 deletion(-)
> >
> 
> This is a new rte_flow API but unfortunately there isn't any
> review/comment, at least it is experimental API. If there is no
> objection/discussion in next few days, I will merge the feature.
> 

Thanks,

> Probably it will be another rte flow feature that only NVIDIA knows and
> uses. While mentioned from using, is the driver update for the feature
> planned for this release?
>

Yes, I hope to send the mlx5 patches in a few days. 
 
> 
> Meanwhile, can you please update the documentation, `rte_flow.rst` and
> `testpmd_funcs.rst`?
> Also can you please rebase on top of latest next-net, this patch
> conflicts with merged group set miss action feature.

Sure

Re: [PATCH v6 2/3] test: add dispatcher test suite

[David Marchand]

On Mon, Oct 9, 2023 at 8:22 PM Mattias Rönnblom
 wrote:
> +static int
> +test_dispatcher(void)
> +{
> +   return unit_test_suite_runner(&test_suite);
> +}
> +
> +REGISTER_FAST_TEST(dispatcher_autotest, false, true, test_dispatcher);

Since this test expects some lcores, wdyt of adding:

@@ -1044,6 +1044,12 @@ static struct unit_test_suite test_suite = {
 static int
 test_dispatcher(void)
 {
+   if (rte_lcore_count() < NUM_SERVICE_CORES + 1) {
+   printf("Not enough cores for dispatcher_autotest,
expecting at least %u\n",
+   NUM_SERVICE_CORES + 1);
+   return TEST_SKIPPED;
+   }
+
return unit_test_suite_runner(&test_suite);
 }

This should avoid the failures we get with some CI env.
(additionnally, I tested this on my laptop and the test runs fine)


-- 
David Marchand

Re: [PATCH v3] net/axgbe: use CPUID to identify cpu

[Ferruh Yigit]

On 10/4/2023 11:07 AM, Selwin Sebastian wrote:
> Using root complex to identify cpu will not work for vm passthrough.
> CPUID is used to get family and modelid to identify cpu
> 
> Fixes: b0db927b5eba ("net/axgbe: use PCI root complex device to distinguish 
> device")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Selwin Sebastian 
> 

Acked-by: Ferruh Yigit 

Applied to dpdk-next-net/main, thanks.


Progressing with this patch for now, to not block the functionality, but
when cpuid abstraction by David [1] is matured, can you please support
porting this patch to new API?

[1]
[Introduce x86 specific identification
API](https://patchwork.dpdk.org/project/dpdk/list/?series=29605)

Re: [PATCH 1/2] ethdev: add IPsec event subtype range for PMD specific code

[Ferruh Yigit]

On 10/4/2023 1:59 PM, Nithin Dabilpuram wrote:
> Add IPsec event subtype range for PMD specific code in order
> to accommodate wide range of errors that PMD supports.
> These IPsec event subtypes are used when an error doesn't
> match the spec defined subtypes between RTE_ETH_EVENT_IPSEC_UNKNOWN
> and RTE_ETH_EVENT_IPSEC_MAX. Adding this as -ve error range
> to avoid ABI breakage.
> 
> Signed-off-by: Nithin Dabilpuram 
> ---
>  lib/ethdev/rte_ethdev.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 8542257721..f949dfc83d 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -3905,6 +3905,10 @@ struct rte_eth_event_macsec_desc {
>   * eth device.
>   */
>  enum rte_eth_event_ipsec_subtype {
> + /**  PMD specific error start */
> + RTE_ETH_EVENT_IPSEC_PMD_ERROR_START = -256,
> + /**  PMD specific error end */
> + RTE_ETH_EVENT_IPSEC_PMD_ERROR_END = -1,
>   /** Unknown event type */
>   RTE_ETH_EVENT_IPSEC_UNKNOWN = 0,
>   /** Sequence number overflow */
>

I don't see any problem to extend event subtype with custom error range,
@Akhil, @Anoob what do you think?

Re: [PATCH v6 3/3] doc: add dispatcher programming guide

[David Marchand]

On Mon, Oct 9, 2023 at 8:23 PM Mattias Rönnblom
 wrote:

[snip]

> +A module may use more than one event handler, for convenience or to
> +further decouple sub-modules. However, the dispatcher may impose an
> +upper limit of the number handlers. In addition, installing a large
> +number of handlers increase dispatcher overhead, although this does
> +not nessarily translate to a system-level performance degradation. See

necessarily*

[snip]

> +Event Clustering
> +
> +
> +The dispatcher maintains the order of events destined for the same
> +handler.
> +
> +*Order* here refers to the order in which the events were delivered
> +from the event device to the dispatcher (i.e., in the event array
> +populated by ``rte_event_dequeue_burst()``), in relation to the order
> +in which the dispatcher deliveres these events to the application.
> +
> +The dispatcher *does not* guarantee to maintain the order of events
> +delivered to *different* handlers.
> +
> +For example, assume that ``MODULE_A_QUEUE_ID`` expands to the value 0,
> +and ``MODULE_B_STAGE_0_QUEUE_ID`` expands to the value 1. Then
> +consider a scenario where the following events are dequeued from the
> +event device (qid is short for event queue id).
> +
> +.. code-block::

Surprisingly, Ubuntu in GHA sphinx complains about this code-block
directive while generating on my Fedora runs fine...

FAILED: doc/guides/html
/usr/bin/python3 ../buildtools/call-sphinx-build.py
/usr/bin/sphinx-build 23.11.0-rc0
/home/runner/work/dpdk/dpdk/doc/guides
/home/runner/work/dpdk/dpdk/build/doc/guides -a -W

Warning, treated as error:
/home/runner/work/dpdk/dpdk/doc/guides/prog_guide/dispatcher_lib.rst:253:Error
in "code-block" directive:
1 argument(s) required, 0 supplied.

.. code-block::

[e0: qid=1], [e1: qid=1], [e2: qid=0], [e3: qid=1]

Looking at 
https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-code-block,
I suspect there is probably a difference in the default settings of
sphinx in those Ubuntu containers.

This is pseudo-code / close to C, so we could probably mark this block
as "C", but "none" works fine too.
WDYT?


-- 
David Marchand

RE: [PATCH v3] net/axgbe: use CPUID to identify cpu

[Sebastian, Selwin]

[AMD Official Use Only - General]

Hi Ferruh,
Thank you. Yes, once David's patch is accepted, I will make changes to use new 
API.

Regards
Selwin

-Original Message-
From: Yigit, Ferruh 
Sent: Tuesday, October 10, 2023 6:24 PM
To: Sebastian, Selwin ; dev@dpdk.org
Cc: sta...@dpdk.org; David Marchand 
Subject: Re: [PATCH v3] net/axgbe: use CPUID to identify cpu

On 10/4/2023 11:07 AM, Selwin Sebastian wrote:
> Using root complex to identify cpu will not work for vm passthrough.
> CPUID is used to get family and modelid to identify cpu
>
> Fixes: b0db927b5eba ("net/axgbe: use PCI root complex device to
> distinguish device")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Selwin Sebastian 
>

Acked-by: Ferruh Yigit 

Applied to dpdk-next-net/main, thanks.


Progressing with this patch for now, to not block the functionality, but when 
cpuid abstraction by David [1] is matured, can you please support porting this 
patch to new API?

[1]
[Introduce x86 specific identification
API](https://patchwork.dpdk.org/project/dpdk/list/?series=29605)

Re: [PATCH 2/3] net/ark: remove RQ pacing firmware from PMD

[Ferruh Yigit]

On 10/5/2023 9:52 PM, Ed Czeck wrote:
> features and function have been removed from FPGA firmware
> 

I am always a little confused how you manage the deployment, if a
customer requires RQ pacing, how you manage it, at least should it be
documented in driver documentation that RQ pacing supported before
v23.11, or something like that?
If this doesn't make sense for your deployment model, scratch it, this
is just a reminder if it is useful.


> Signed-off-by: Ed Czeck 
> ---
>  drivers/net/ark/ark_ethdev.c | 62 
>  drivers/net/ark/ark_global.h |  3 --
>  drivers/net/ark/ark_rqp.c| 70 
>  drivers/net/ark/ark_rqp.h| 58 --
>  drivers/net/ark/meson.build  |  1 -
>  5 files changed, 15 insertions(+), 179 deletions(-)
>  delete mode 100644 drivers/net/ark/ark_rqp.c
>  delete mode 100644 drivers/net/ark/ark_rqp.h
> 
> diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
> index 90d3c8abe6..306121ba31 100644
> --- a/drivers/net/ark/ark_ethdev.c
> +++ b/drivers/net/ark/ark_ethdev.c
> @@ -17,7 +17,6 @@
>  #include "ark_mpu.h"
>  #include "ark_ddm.h"
>  #include "ark_udm.h"
> -#include "ark_rqp.h"
>  #include "ark_pktdir.h"
>  #include "ark_pktgen.h"
>  #include "ark_pktchkr.h"
> @@ -107,36 +106,32 @@ static const struct rte_pci_id pci_id_ark_map[] = {
>   * This structure is used to statically define the capabilities
>   * of supported devices.
>   * Capabilities:
> - *  rqpacing -
> - * Some HW variants require that PCIe read-requests be correctly throttled.
> - * This is called "rqpacing" and has to do with credit and flow control
> - * on certain Arkville implementations.
> + *isvf -- defined for function id that are virtual
>   */
>  struct ark_caps {
> - bool rqpacing;
>   bool isvf;
>  };
>  struct ark_dev_caps {
>   uint32_t  device_id;
>   struct ark_caps  caps;
>  };
> -#define SET_DEV_CAPS(id, rqp, vf)\
> - {id, {.rqpacing = rqp, .isvf = vf} }
> +#define SET_DEV_CAPS(id, vf) \
> + {id, {.isvf = vf} }
>  
>  static const struct ark_dev_caps
>  ark_device_caps[] = {
> -  SET_DEV_CAPS(0x100d, true, false),
> -  SET_DEV_CAPS(0x100e, true, false),
> -  SET_DEV_CAPS(0x100f, true, false),
> -  SET_DEV_CAPS(0x1010, false, false),
> -  SET_DEV_CAPS(0x1017, true, false),
> -  SET_DEV_CAPS(0x1018, true, false),
> -  SET_DEV_CAPS(0x1019, true, false),
> -  SET_DEV_CAPS(0x101a, true, false),
> -  SET_DEV_CAPS(0x101b, true, false),
> -  SET_DEV_CAPS(0x101c, true, true),
> -  SET_DEV_CAPS(0x101e, false, false),
> -  SET_DEV_CAPS(0x101f, false, false),
> +  SET_DEV_CAPS(0x100d, false),
> +  SET_DEV_CAPS(0x100e, false),
> +  SET_DEV_CAPS(0x100f, false),
> +  SET_DEV_CAPS(0x1010, false),
> +  SET_DEV_CAPS(0x1017, false),
> +  SET_DEV_CAPS(0x1018, false),
> +  SET_DEV_CAPS(0x1019, false),
> +  SET_DEV_CAPS(0x101a, false),
> +  SET_DEV_CAPS(0x101b, false),
> +  SET_DEV_CAPS(0x101c, true),
> +  SET_DEV_CAPS(0x101e, false),
> +  SET_DEV_CAPS(0x101f, false),
>{.device_id = 0,}
>  };
>  
> @@ -301,9 +296,6 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
>   int port_count = 1;
>   int p;
>   uint16_t num_queues;
> - bool rqpacing = false;
> -
> - ark->eth_dev = dev;
>  

Above "ark->eth_dev" assignment doesn't look directly related with RQ
pacing, I just want to double check if it is removed intentionally?

[PATCH] eventdev: fix symbol export for port maintenance

[David Marchand]

Trying to call rte_event_maintain out of the eventdev library triggers
a link failure, as the tracepoint symbol associated to this inline
helper was not exported.

Fixes: 54f17843a887 ("eventdev: add port maintenance API")
Cc: sta...@dpdk.org

Signed-off-by: David Marchand 
---
Caught by the CI when testing the dispatcher library.
See for example:
https://github.com/ovsrobot/dpdk/actions/runs/6460514355/job/17538348529#step:19:5506

---
 lib/eventdev/version.map | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/eventdev/version.map b/lib/eventdev/version.map
index b03c10d99f..249eb115b1 100644
--- a/lib/eventdev/version.map
+++ b/lib/eventdev/version.map
@@ -5,6 +5,7 @@ DPDK_24 {
__rte_eventdev_trace_deq_burst;
__rte_eventdev_trace_enq_burst;
__rte_eventdev_trace_eth_tx_adapter_enqueue;
+   __rte_eventdev_trace_maintain;
__rte_eventdev_trace_timer_arm_burst;
__rte_eventdev_trace_timer_arm_tmo_tick_burst;
__rte_eventdev_trace_timer_cancel_burst;
-- 
2.41.0

Re: [PATCH v6 2/3] test: add dispatcher test suite

[David Marchand]

On Mon, Oct 9, 2023 at 8:22 PM Mattias Rönnblom
 wrote:
>
> Add unit tests for the dispatcher.

Fyi, this patch is the first external user of rte_event_maintain and
it revealed an issue:
http://mails.dpdk.org/archives/test-report/2023-October/475671.html

I sent a fix, can you have a look?
https://patchwork.dpdk.org/project/dpdk/patch/20231010140029.66159-1-david.march...@redhat.com/

Thanks.

-- 
David Marchand

DPDK summit in Dublin - videos & photos

[Thomas Monjalon]

Hello,

As you probably know, the videos of the summit are online:
https://www.youtube.com/playlist?list=PLo97Rhbj4ceJf9p-crjGvGvn8pMWrJ_cV

You can find the group photo from Dublin here:
http://fast.dpdk.org/events/images/DPDK-2023-09-Ireland-group-6.jpg

and more in http://fast.dpdk.org/events/images/

Re: [PATCH v5 09/12] baseband/acc: add FFT support to VRB2 variant

[Maxime Coquelin]

On 10/5/23 21:49, Nicolas Chautru wrote:

Support for the FFT the processing specific to the
VRB2 variant.

Signed-off-by: Nicolas Chautru 
---
  drivers/baseband/acc/rte_vrb_pmd.c | 146 +++--
  1 file changed, 119 insertions(+), 27 deletions(-)



Reviewed-by: Maxime Coquelin 

Maxime

[PATCH v2] ethdev: add calculate hash function

[Ori Kam]

rte_flow supports insert by index table[1].

Using the above table, the application can create rules
that are based on hash.
For example application can create the following logic in order
to create load balancing:
1. Create insert by index table with 2 rules, that hashes based on dmac
2. Insert to index 0 a rule that sends the traffic to port A.
3. Insert to index 1 a rule that sends the traffic to port B.

Let's also assume that before this table, there is a 5 tuple
match table that jumps to the above table.

So each packet that matches one of the 5 tuple rules is RSSed
to port A or B, based on dmac hash.

The issue arises when there is a miss on the 5 tuple table,
which resulted due to the packet being the first packet of this flow, or
fragmented packet or any other reason.
In this case, the application must calculate what would be the
hash calculated by the HW so it can send the packet to the correct
port.

This new API allows applications to calculate the hash value of a given
packet for a given table.

[1] - 
http://patches.dpdk.org/project/dpdk/patch/20230208030624.78465-2-akozy...@nvidia.com/

Signed-off-by: Ori Kam 
---

v2: add rst documentations

---
 app/test-pmd/cmdline_flow.c | 86 -
 app/test-pmd/config.c   | 54 +
 app/test-pmd/testpmd.h  |  2 +
 doc/guides/prog_guide/rte_flow.rst  | 17 
 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 22 ++
 lib/ethdev/rte_flow.c   | 21 +
 lib/ethdev/rte_flow.h   | 32 
 lib/ethdev/rte_flow_driver.h|  5 ++
 lib/ethdev/version.map  |  1 +
 9 files changed, 239 insertions(+), 1 deletion(-)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 12809f1042..dd66429554 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -102,6 +102,7 @@ enum index {
QUEUE,
PUSH,
PULL,
+   HASH,
 
/* Flex arguments */
FLEX_ITEM_INIT,
@@ -214,6 +215,11 @@ enum index {
GROUP_TRANSFER,
GROUP_SET_MISS_ACTIONS,
 
+   /* Hash calculation arguments. */
+   HASH_CALC_TABLE,
+   HASH_CALC_PATTERN_INDEX,
+   HASH_CALC_PATTERN,
+
/* Tunnel arguments. */
TUNNEL_CREATE,
TUNNEL_CREATE_TYPE,
@@ -2708,6 +2714,9 @@ static int parse_pull(struct context *, const struct 
token *,
 static int parse_group(struct context *, const struct token *,
   const char *, unsigned int,
   void *, unsigned int);
+static int parse_hash(struct context *, const struct token *,
+ const char *, unsigned int,
+ void *, unsigned int);
 static int parse_tunnel(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
@@ -3066,7 +3075,8 @@ static const struct token token_list[] = {
  FLEX,
  QUEUE,
  PUSH,
- PULL)),
+ PULL,
+ HASH)),
.call = parse_init,
},
/* Top-level command. */
@@ -3751,6 +3761,33 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY(struct buffer, queue)),
},
/* Top-level command. */
+   [HASH] = {
+   .name = "hash",
+   .help = "calculate hash for a given pattern in a given template 
table",
+   .next = NEXT(NEXT_ENTRY(HASH_CALC_TABLE), 
NEXT_ENTRY(COMMON_PORT_ID)),
+   .args = ARGS(ARGS_ENTRY(struct buffer, port)),
+   .call = parse_hash,
+   },
+   /* Sub-level commands. */
+   [HASH_CALC_TABLE] = {
+   .name = "template_table",
+   .help = "specify table id",
+   .next = NEXT(NEXT_ENTRY(HASH_CALC_PATTERN_INDEX),
+NEXT_ENTRY(COMMON_TABLE_ID)),
+   .args = ARGS(ARGS_ENTRY(struct buffer,
+   args.vc.table_id)),
+   .call = parse_hash,
+   },
+   [HASH_CALC_PATTERN_INDEX] = {
+   .name = "pattern_template",
+   .help = "specify pattern template id",
+   .next = NEXT(NEXT_ENTRY(ITEM_PATTERN),
+NEXT_ENTRY(COMMON_UNSIGNED)),
+   .args = ARGS(ARGS_ENTRY(struct buffer,
+   args.vc.pat_templ_id)),
+   .call = parse_hash,
+   },
+   /* Top-level command. */
[INDIRECT_ACTION] = {
.name = "indirect_action",
.type = "{command} {port_id} [{arg} [...]]",
@@ -10544,6 +10581,48 @@ parse_pull(struct context *ctx, const struct token 
*token,
return len;
 }
 
+/** Parse tokens for hash calculation command

[PATCH v2] common/mlx5: Optimize mlx5 mempool get extmem

[Aaron Conole]

From: John Romein 

This patch reduces the time to allocate and register tens of gigabytes
of GPU memory from hours to seconds, by sorting the heap only once
instead of for each object in the mempool.

Fixes: 690b2a88c2f7 ("common/mlx5: add mempool registration facilities")

Signed-off-by: John Romein 
---
 drivers/common/mlx5/mlx5_common_mr.c | 69 
 1 file changed, 20 insertions(+), 49 deletions(-)

diff --git a/drivers/common/mlx5/mlx5_common_mr.c 
b/drivers/common/mlx5/mlx5_common_mr.c
index 40ff9153bd..77b66e444b 100644
--- a/drivers/common/mlx5/mlx5_common_mr.c
+++ b/drivers/common/mlx5/mlx5_common_mr.c
@@ -1389,63 +1389,23 @@ mlx5_mempool_get_chunks(struct rte_mempool *mp, struct 
mlx5_range **out,
return 0;
 }
 
-struct mlx5_mempool_get_extmem_data {
-   struct mlx5_range *heap;
-   unsigned int heap_size;
-   int ret;
-};
-
 static void
 mlx5_mempool_get_extmem_cb(struct rte_mempool *mp, void *opaque,
   void *obj, unsigned int obj_idx)
 {
-   struct mlx5_mempool_get_extmem_data *data = opaque;
+   struct mlx5_range *heap = opaque;
struct rte_mbuf *mbuf = obj;
uintptr_t addr = (uintptr_t)mbuf->buf_addr;
-   struct mlx5_range *seg, *heap;
struct rte_memseg_list *msl;
size_t page_size;
uintptr_t page_start;
-   unsigned int pos = 0, len = data->heap_size, delta;
 
RTE_SET_USED(mp);
-   RTE_SET_USED(obj_idx);
-   if (data->ret < 0)
-   return;
-   /* Binary search for an already visited page. */
-   while (len > 1) {
-   delta = len / 2;
-   if (addr < data->heap[pos + delta].start) {
-   len = delta;
-   } else {
-   pos += delta;
-   len -= delta;
-   }
-   }
-   if (data->heap != NULL) {
-   seg = &data->heap[pos];
-   if (seg->start <= addr && addr < seg->end)
-   return;
-   }
-   /* Determine the page boundaries and remember them. */
-   heap = realloc(data->heap, sizeof(heap[0]) * (data->heap_size + 1));
-   if (heap == NULL) {
-   free(data->heap);
-   data->heap = NULL;
-   data->ret = -1;
-   return;
-   }
-   data->heap = heap;
-   data->heap_size++;
-   seg = &heap[data->heap_size - 1];
msl = rte_mem_virt2memseg_list((void *)addr);
page_size = msl != NULL ? msl->page_sz : rte_mem_page_size();
page_start = RTE_PTR_ALIGN_FLOOR(addr, page_size);
-   seg->start = page_start;
-   seg->end = page_start + page_size;
-   /* Maintain the heap order. */
-   qsort(data->heap, data->heap_size, sizeof(heap[0]),
- mlx5_range_compare_start);
+   heap[obj_idx].start = page_start;
+   heap[obj_idx].end = page_start + page_size;
 }
 
 /**
@@ -1457,15 +1417,26 @@ static int
 mlx5_mempool_get_extmem(struct rte_mempool *mp, struct mlx5_range **out,
unsigned int *out_n)
 {
-   struct mlx5_mempool_get_extmem_data data;
+   unsigned int out_size = 1;
+   struct mlx5_range *heap;
 
DRV_LOG(DEBUG, "Recovering external pinned pages of mempool %s",
mp->name);
-   memset(&data, 0, sizeof(data));
-   rte_mempool_obj_iter(mp, mlx5_mempool_get_extmem_cb, &data);
-   *out = data.heap;
-   *out_n = data.heap_size;
-   return data.ret;
+   heap = malloc(mp->size * sizeof(struct mlx5_range));
+   if (heap == NULL)
+   return -1;
+   rte_mempool_obj_iter(mp, mlx5_mempool_get_extmem_cb, heap);
+   qsort(heap, mp->size, sizeof(heap[0]), mlx5_range_compare_start);
+   /* remove duplicates */
+   for (unsigned int i = 1; i < mp->size; i++)
+   if (heap[out_size - 1].start != heap[i].start)
+   heap[out_size++] = heap[i];
+   heap = realloc(heap, out_size * sizeof(struct mlx5_range));
+   if (heap == NULL)
+   return -1;
+   *out = heap;
+   *out_n = out_size;
+   return 0;
 }
 
 /**
-- 
2.41.0

RE: [EXT] Re: [PATCH 1/2] ethdev: add IPsec event subtype range for PMD specific code

[Akhil Goyal]

> On 10/4/2023 1:59 PM, Nithin Dabilpuram wrote:
> > Add IPsec event subtype range for PMD specific code in order
> > to accommodate wide range of errors that PMD supports.
> > These IPsec event subtypes are used when an error doesn't
> > match the spec defined subtypes between
> RTE_ETH_EVENT_IPSEC_UNKNOWN
> > and RTE_ETH_EVENT_IPSEC_MAX. Adding this as -ve error range
> > to avoid ABI breakage.
> >
> > Signed-off-by: Nithin Dabilpuram 
> > ---
> >  lib/ethdev/rte_ethdev.h | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> > index 8542257721..f949dfc83d 100644
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -3905,6 +3905,10 @@ struct rte_eth_event_macsec_desc {
> >   * eth device.
> >   */
> >  enum rte_eth_event_ipsec_subtype {
> > +   /**  PMD specific error start */
> > +   RTE_ETH_EVENT_IPSEC_PMD_ERROR_START = -256,
> > +   /**  PMD specific error end */
> > +   RTE_ETH_EVENT_IPSEC_PMD_ERROR_END = -1,
> > /** Unknown event type */
> > RTE_ETH_EVENT_IPSEC_UNKNOWN = 0,
> > /** Sequence number overflow */
> >
> 
> I don't see any problem to extend event subtype with custom error range,
> @Akhil, @Anoob what do you think?

I believe it is ok to add the custom error range.
It is just that the user will need to check the negative values too, which I 
believe is ok.

Acked-by: Akhil Goyal 

RE: [EXT] Re: [PATCH 1/2] ethdev: add IPsec event subtype range for PMD specific code

[Anoob Joseph]

Hi Ferruh,

> 
> --
> On 10/4/2023 1:59 PM, Nithin Dabilpuram wrote:
> > Add IPsec event subtype range for PMD specific code in order to
> > accommodate wide range of errors that PMD supports.
> > These IPsec event subtypes are used when an error doesn't match the
> > spec defined subtypes between RTE_ETH_EVENT_IPSEC_UNKNOWN and
> > RTE_ETH_EVENT_IPSEC_MAX. Adding this as -ve error range to avoid ABI
> > breakage.
> >
> > Signed-off-by: Nithin Dabilpuram 
> > ---
> >  lib/ethdev/rte_ethdev.h | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
> > 8542257721..f949dfc83d 100644
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -3905,6 +3905,10 @@ struct rte_eth_event_macsec_desc {
> >   * eth device.
> >   */
> >  enum rte_eth_event_ipsec_subtype {
> > +   /**  PMD specific error start */
> > +   RTE_ETH_EVENT_IPSEC_PMD_ERROR_START = -256,
> > +   /**  PMD specific error end */
> > +   RTE_ETH_EVENT_IPSEC_PMD_ERROR_END = -1,
> > /** Unknown event type */
> > RTE_ETH_EVENT_IPSEC_UNKNOWN = 0,
> > /** Sequence number overflow */
> >
> 
> I don't see any problem to extend event subtype with custom error range,
> @Akhil, @Anoob what do you think?

[Anoob] Thanks for looping in. I do not see an issue with the approach either.

Acked-by: Anoob Joseph 

Thanks,
Anoob

Re: [PATCH 2/3] net/ark: remove RQ pacing firmware from PMD

[Ed Czeck]

On Tue, Oct 10, 2023 at 9:51 AM Ferruh Yigit  wrote:
>
> On 10/5/2023 9:52 PM, Ed Czeck wrote:
> > features and function have been removed from FPGA firmware
> >
>
> I am always a little confused how you manage the deployment, if a
> customer requires RQ pacing, how you manage it, at least should it be
> documented in driver documentation that RQ pacing supported before
> v23.11, or something like that?
> If this doesn't make sense for your deployment model, scratch it, this
> is just a reminder if it is useful.

Our deployment needs to balance the DPDK  release, our FPGA firmware, our
(not yet
published) DPDKpatches and external FPGA-IP firmware from AMD (Xilinx) and
Intel
(Altera).  We have safety code to ensure that these fall into a valid
alignment. We also
try to maintain SW/FPGA compatibility and evolve without breaking things
unnecessarily.
Our releases follow DPDK's and we update other tools as they are released.

For RQ pacing, it was an internal feature needed for older Xilinx PCIE IP,
with a
narrow exposure via our PMD.  The Xilinx IP no longer requires this module,
our
firmware no longer includes it, and the PMD can drop.  It was not user
controllable
nor an advertised feature.

>
>
> > Signed-off-by: Ed Czeck 
> > ---
> >  drivers/net/ark/ark_ethdev.c | 62 
> >  drivers/net/ark/ark_global.h |  3 --
> >  drivers/net/ark/ark_rqp.c| 70 
> >  drivers/net/ark/ark_rqp.h| 58 --
> >  drivers/net/ark/meson.build  |  1 -
> >  5 files changed, 15 insertions(+), 179 deletions(-)
> >  delete mode 100644 drivers/net/ark/ark_rqp.c
> >  delete mode 100644 drivers/net/ark/ark_rqp.h
> >
> > diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
> > index 90d3c8abe6..306121ba31 100644
> > --- a/drivers/net/ark/ark_ethdev.c
> > +++ b/drivers/net/ark/ark_ethdev.c
> > @@ -17,7 +17,6 @@
> >  #include "ark_mpu.h"
> >  #include "ark_ddm.h"
> >  #include "ark_udm.h"
> > -#include "ark_rqp.h"
> >  #include "ark_pktdir.h"
> >  #include "ark_pktgen.h"
> >  #include "ark_pktchkr.h"
> > @@ -107,36 +106,32 @@ static const struct rte_pci_id pci_id_ark_map[] =
{
> >   * This structure is used to statically define the capabilities
> >   * of supported devices.
> >   * Capabilities:
> > - *  rqpacing -
> > - * Some HW variants require that PCIe read-requests be correctly
throttled.
> > - * This is called "rqpacing" and has to do with credit and flow control
> > - * on certain Arkville implementations.
> > + *isvf -- defined for function id that are virtual
> >   */
> >  struct ark_caps {
> > - bool rqpacing;
> >   bool isvf;
> >  };
> >  struct ark_dev_caps {
> >   uint32_t  device_id;
> >   struct ark_caps  caps;
> >  };
> > -#define SET_DEV_CAPS(id, rqp, vf)\
> > - {id, {.rqpacing = rqp, .isvf = vf} }
> > +#define SET_DEV_CAPS(id, vf) \
> > + {id, {.isvf = vf} }
> >
> >  static const struct ark_dev_caps
> >  ark_device_caps[] = {
> > -  SET_DEV_CAPS(0x100d, true, false),
> > -  SET_DEV_CAPS(0x100e, true, false),
> > -  SET_DEV_CAPS(0x100f, true, false),
> > -  SET_DEV_CAPS(0x1010, false, false),
> > -  SET_DEV_CAPS(0x1017, true, false),
> > -  SET_DEV_CAPS(0x1018, true, false),
> > -  SET_DEV_CAPS(0x1019, true, false),
> > -  SET_DEV_CAPS(0x101a, true, false),
> > -  SET_DEV_CAPS(0x101b, true, false),
> > -  SET_DEV_CAPS(0x101c, true, true),
> > -  SET_DEV_CAPS(0x101e, false, false),
> > -  SET_DEV_CAPS(0x101f, false, false),
> > +  SET_DEV_CAPS(0x100d, false),
> > +  SET_DEV_CAPS(0x100e, false),
> > +  SET_DEV_CAPS(0x100f, false),
> > +  SET_DEV_CAPS(0x1010, false),
> > +  SET_DEV_CAPS(0x1017, false),
> > +  SET_DEV_CAPS(0x1018, false),
> > +  SET_DEV_CAPS(0x1019, false),
> > +  SET_DEV_CAPS(0x101a, false),
> > +  SET_DEV_CAPS(0x101b, false),
> > +  SET_DEV_CAPS(0x101c, true),
> > +  SET_DEV_CAPS(0x101e, false),
> > +  SET_DEV_CAPS(0x101f, false),
> >{.device_id = 0,}
> >  };
> >
> > @@ -301,9 +296,6 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
> >   int port_count = 1;
> >   int p;
> >   uint16_t num_queues;
> > - bool rqpacing = false;
> > -
> > - ark->eth_dev = dev;
> >
>
> Above "ark->eth_dev" assignment doesn't look directly related with RQ
> pacing, I just want to double check if it is removed intentionally?

This change is in error.   Thanks for catching it.  New patch to follow.

>
>

[RFC] doc/linux_gsg: add amd configuration section

[Vipin Varghese]

Add AMD EPYC SoC tuning guide as new setcion of linux getting
started guide.

Signed-off-by: Vipin Varghese 
---
 doc/guides/linux_gsg/amd_platform.rst | 63 +++
 doc/guides/linux_gsg/index.rst|  1 +
 2 files changed, 64 insertions(+)
 create mode 100644 doc/guides/linux_gsg/amd_platform.rst

diff --git a/doc/guides/linux_gsg/amd_platform.rst 
b/doc/guides/linux_gsg/amd_platform.rst
new file mode 100644
index 00..bcd12bf4f9
--- /dev/null
+++ b/doc/guides/linux_gsg/amd_platform.rst
@@ -0,0 +1,63 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2023 Advanced Micro Devices, Inc. All rights reserved.
+
+How to get best performance on AMD platform
+===
+
+This document shares step-by-step guide for configuring AMD EPYC SoC across 
various families for getting best performance for DPDK applications.
+Various factors like BIOS, Numa Per Socket, Memory per Numa, near-far from IO 
device affects the overall performance.
+
+These are covered in various sections of tuning guides shared below.
+
+
+Tuning Guide for AMD EPYC SoC
+-
+
+#. `MILAN 
`_
+
+#. `GENOA 
`_
+
+#. `BERGAMO|SIENNA 
`_
+
+
+General Requirements
+
+
+Memory
+~~
+
+Refer `Memory Configuration` section for SoC specific details.
+
+Note: general thumb rule is to ensure that each memory channel has at least 
one memory DIMM populated. The ideal memory size for each is at least 8|16|32 
GB ECC modules.
+
+
+BIOS
+
+
+Refer `BIOS Performance` section in tuning guide for recommended settings.
+
+
+Linux Grub
+--
+
+Refer `Linux OS & Kernel` in tuning guide for recommended settings.
+
+
+NIC and Accelerator
+---
+
+AMD EPYC supports PCIe Generation of 1|2|3|4|5 depending upon SoC familes. For 
best performance ensure the right slots are used which provides adequate 
bandwidth.
+
+Use ``lspci`` to check the speed of a PCI slot ::
+
+  lspci -s 41:00.0 -vv | grep LnkSta
+
+  LnkSta: Speed 16GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- ...
+  LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+ ...
+
+
+Compiler
+---
+
+Refer `Compiler Flags` for recommended version and `-march` flags.
+
diff --git a/doc/guides/linux_gsg/index.rst b/doc/guides/linux_gsg/index.rst
index c3e67bf9ec..ecdaf35eec 100644
--- a/doc/guides/linux_gsg/index.rst
+++ b/doc/guides/linux_gsg/index.rst
@@ -21,3 +21,4 @@ Getting Started Guide for Linux
 linux_eal_parameters
 enable_func
 nic_perf_intel_platform
+amd_platform
-- 
2.34.1

[RFC] doc/linux_gsg: add amd configuration section

[Vipin Varghese]

Add AMD EPYC SoC tuning guide as new setcion of linux getting
started guide.

Signed-off-by: Vipin Varghese 
---
 doc/guides/linux_gsg/amd_platform.rst | 63 +++
 doc/guides/linux_gsg/index.rst|  1 +
 2 files changed, 64 insertions(+)
 create mode 100644 doc/guides/linux_gsg/amd_platform.rst

diff --git a/doc/guides/linux_gsg/amd_platform.rst 
b/doc/guides/linux_gsg/amd_platform.rst
new file mode 100644
index 00..cdb535e9c0
--- /dev/null
+++ b/doc/guides/linux_gsg/amd_platform.rst
@@ -0,0 +1,63 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2023 Advanced Micro Devices, Inc. All rights reserved.
+
+How to get best performance on AMD platform
+===
+
+This document shares step-by-step guide for configuring AMD EPYC SoC across 
various families for getting best performance for DPDK applications.
+Various factors like BIOS, Numa Per Socket, Memory per Numa, near-far from IO 
device affects the overall performance.
+
+These are covered in various sections of tuning guides shared below.
+
+
+Tuning Guide for AMD EPYC SoC
+-
+
+#. `MILAN 
`_
+
+#. `GENOA 
`_
+
+#. `BERGAMO|SIENNA 
`_
+
+
+General Requirements
+
+
+Memory
+~~
+
+Refer `Memory Configuration` section for SoC specific details.
+
+Note: general thumb rule is to ensure that each memory channel has at least 
one memory DIMM populated. The ideal memory size for each is at least 8|16|32 
GB ECC modules.
+
+
+BIOS
+
+
+Refer `BIOS Performance` section in tuning guide for recommended settings.
+
+
+Linux Grub
+--
+
+Refer `Linux OS & Kernel` in tuning guide for recommended settings.
+
+
+NIC and Accelerator
+---
+
+AMD EPYC supports PCIe Generation of 1|2|3|4|5 depending upon SoC families. 
For best performance ensure the right slots are used which provides adequate 
bandwidth.
+
+Use ``lspci`` to check the speed of a PCI slot ::
+
+  lspci -s 41:00.0 -vv | grep LnkSta
+
+  LnkSta: Speed 16GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- ...
+  LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+ ...
+
+
+Compiler
+---
+
+Refer `Compiler Flags` for recommended version and `-march` flags.
+
diff --git a/doc/guides/linux_gsg/index.rst b/doc/guides/linux_gsg/index.rst
index c3e67bf9ec..ecdaf35eec 100644
--- a/doc/guides/linux_gsg/index.rst
+++ b/doc/guides/linux_gsg/index.rst
@@ -21,3 +21,4 @@ Getting Started Guide for Linux
 linux_eal_parameters
 enable_func
 nic_perf_intel_platform
+amd_platform
-- 
2.34.1

Re: [PATCH v2] net/netvsc: add support for mtu_set

[Stephen Hemminger]

On Fri, 6 Oct 2023 20:09:09 +
Sam Andrew  wrote:

> Add support for changing the netvsc MTU. The MTU can only be set at nvs
> initialization, therefore to change the MTU the underlying vmbus
> channel(s) are torn down and the vmbus device unmapped and remapped. The
> existing rx and tx queue(s) are reconnected to the new vmbus channel(s).
> 
> Signed-off-by: Sam Andrew 
> ---

Acked-by: Stephen Hemminger 

[PATCH v2 2/3] net/ark: remove RQ pacing firmware from PMD

[Ed Czeck]

features and function have been removed from FPGA firmware

Signed-off-by: Ed Czeck 
---
v2:
* restore previously incorrectly deleted line
---
 drivers/net/ark/ark_ethdev.c | 60 ---
 drivers/net/ark/ark_global.h |  3 --
 drivers/net/ark/ark_rqp.c| 70 
 drivers/net/ark/ark_rqp.h| 58 --
 drivers/net/ark/meson.build  |  1 -
 5 files changed, 15 insertions(+), 177 deletions(-)
 delete mode 100644 drivers/net/ark/ark_rqp.c
 delete mode 100644 drivers/net/ark/ark_rqp.h

diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index 90d3c8abe6..0ffd4b9e9e 100644
--- a/drivers/net/ark/ark_ethdev.c
+++ b/drivers/net/ark/ark_ethdev.c
@@ -17,7 +17,6 @@
 #include "ark_mpu.h"
 #include "ark_ddm.h"
 #include "ark_udm.h"
-#include "ark_rqp.h"
 #include "ark_pktdir.h"
 #include "ark_pktgen.h"
 #include "ark_pktchkr.h"
@@ -107,36 +106,32 @@ static const struct rte_pci_id pci_id_ark_map[] = {
  * This structure is used to statically define the capabilities
  * of supported devices.
  * Capabilities:
- *  rqpacing -
- * Some HW variants require that PCIe read-requests be correctly throttled.
- * This is called "rqpacing" and has to do with credit and flow control
- * on certain Arkville implementations.
+ *isvf -- defined for function id that are virtual
  */
 struct ark_caps {
-   bool rqpacing;
bool isvf;
 };
 struct ark_dev_caps {
uint32_t  device_id;
struct ark_caps  caps;
 };
-#define SET_DEV_CAPS(id, rqp, vf)  \
-   {id, {.rqpacing = rqp, .isvf = vf} }
+#define SET_DEV_CAPS(id, vf)   \
+   {id, {.isvf = vf} }
 
 static const struct ark_dev_caps
 ark_device_caps[] = {
-SET_DEV_CAPS(0x100d, true, false),
-SET_DEV_CAPS(0x100e, true, false),
-SET_DEV_CAPS(0x100f, true, false),
-SET_DEV_CAPS(0x1010, false, false),
-SET_DEV_CAPS(0x1017, true, false),
-SET_DEV_CAPS(0x1018, true, false),
-SET_DEV_CAPS(0x1019, true, false),
-SET_DEV_CAPS(0x101a, true, false),
-SET_DEV_CAPS(0x101b, true, false),
-SET_DEV_CAPS(0x101c, true, true),
-SET_DEV_CAPS(0x101e, false, false),
-SET_DEV_CAPS(0x101f, false, false),
+SET_DEV_CAPS(0x100d, false),
+SET_DEV_CAPS(0x100e, false),
+SET_DEV_CAPS(0x100f, false),
+SET_DEV_CAPS(0x1010, false),
+SET_DEV_CAPS(0x1017, false),
+SET_DEV_CAPS(0x1018, false),
+SET_DEV_CAPS(0x1019, false),
+SET_DEV_CAPS(0x101a, false),
+SET_DEV_CAPS(0x101b, false),
+SET_DEV_CAPS(0x101c, true),
+SET_DEV_CAPS(0x101e, false),
+SET_DEV_CAPS(0x101f, false),
 {.device_id = 0,}
 };
 
@@ -301,7 +296,6 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
int port_count = 1;
int p;
uint16_t num_queues;
-   bool rqpacing = false;
 
ark->eth_dev = dev;
 
@@ -319,7 +313,6 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
p = 0;
while (ark_device_caps[p].device_id != 0) {
if (pci_dev->id.device_id == ark_device_caps[p].device_id) {
-   rqpacing = ark_device_caps[p].caps.rqpacing;
ark->isvf = ark_device_caps[p].caps.isvf;
break;
}
@@ -344,12 +337,6 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
ark->pktgen.v  = (void *)&ark->bar0[ARK_PKTGEN_BASE];
ark->pktchkr.v  = (void *)&ark->bar0[ARK_PKTCHKR_BASE];
 
-   if (rqpacing) {
-   ark->rqpacing =
-   (struct ark_rqpace_t *)(ark->bar0 + ARK_RCPACING_BASE);
-   } else {
-   ark->rqpacing = NULL;
-   }
ark->started = 0;
ark->pkt_dir_v = ARK_PKT_DIR_INIT_VAL;
 
@@ -368,17 +355,6 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
ark->sysctrl.t32[4], __func__);
return -1;
}
-   if (ark->sysctrl.t32[3] != 0) {
-   if (ark->rqpacing) {
-   if (ark_rqp_lasped(ark->rqpacing)) {
-   ARK_PMD_LOG(ERR, "Arkville Evaluation System - "
-   "Timer has Expired\n");
-   return -1;
-   }
-   ARK_PMD_LOG(WARNING, "Arkville Evaluation System - "
-   "Timer is Running\n");
-   }
-   }
 
ARK_PMD_LOG(DEBUG,
"HW Sanity test has PASSED, expected constant"
@@ -550,9 +526,6 @@ ark_config_device(struct rte_eth_dev *dev)
   

[PATCH] doc: remove confusing command to send patch

[Thomas Monjalon]

In the contributor guide, it was said that no need to Cc maintainers
for new additions, probably for new directories not having a maintainer.
There is no harm, and it is a good habit, to always Cc maintainers.

Remove this case as it can mislead to not Cc maintainers when needed.

Signed-off-by: Thomas Monjalon 
---
 doc/guides/contributing/patches.rst | 4 
 1 file changed, 4 deletions(-)

diff --git a/doc/guides/contributing/patches.rst 
b/doc/guides/contributing/patches.rst
index e286d9e6d5..d114ceba2b 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -561,10 +561,6 @@ Script ``get-maintainer.sh`` can be used to select 
maintainers automatically::
 
   git send-email --to-cmd ./devtools/get-maintainer.sh --cc dev@dpdk.org 
000*.patch
 
-New additions can be sent without a maintainer::
-
-   git send-email --to dev@dpdk.org 000*.patch
-
 You can test the emails by sending it to yourself or with the ``--dry-run`` 
option.
 
 If the patch is in relation to a previous email thread you can add it to the 
same thread using the Message ID::
-- 
2.42.0

Re: [PATCH v2 2/3] net/ark: remove RQ pacing firmware from PMD

[Ferruh Yigit]

On 10/10/2023 5:08 PM, Ed Czeck wrote:
> features and function have been removed from FPGA firmware
> 
> Signed-off-by: Ed Czeck 
> ---
> v2:
> * restore previously incorrectly deleted line
> 

Can you please send v2 of whole set, this helps on CI checks and back
tracing via patchwork etc...

RE: [PATCH v4 1/2] security: add fallback security processing and Rx inject

[Akhil Goyal]

> -Original Message-
> From: Anoob Joseph 
> Sent: Tuesday, October 10, 2023 4:02 PM
> To: Akhil Goyal ; Jerin Jacob Kollanukkaran
> ; Konstantin Ananyev 
> Cc: Hemant Agrawal ; dev@dpdk.org; Vidya Sagar
> Velumuri ; david.co...@intel.com; kai...@intel.com;
> kevin.osulli...@intel.com; Ciara Power 
> Subject: [PATCH v4 1/2] security: add fallback security processing and Rx 
> inject
> 
> Add alternate datapath API for security processing which would do Rx
> injection (similar to loopback) after successful security processing.
> 
> With inline protocol offload, variable part of the session context
> (AR windows, lifetime etc in case of IPsec), is not accessible to the
> application. If packets are not getting processed in the inline path
> due to non security reasons (such as outer fragmentation or rte_flow
> packet steering limitations), then the packet cannot be security
> processed as the session context is private to the PMD and security
> library doesn't provide alternate APIs to make use of the same session.
> 
> Introduce new API and Rx injection as fallback mechanism to security
> processing failures due to non-security reasons. For example, when there
> is outer fragmentation and PMD doesn't support reassembly of outer
> fragments, application would receive fragments which it can then
> reassemble. Post successful reassembly, packet can be submitted for
> security processing and Rx inject. The packets can be then received in
> the application as normal inline protocol processed packets.
> 
> Same API can be leveraged in lookaside protocol offload mode to inject
> packet to Rx. This would help in using rte_flow based packet parsing
> after security processing. For example, with IPsec, this will help in
> flow splitting after IPsec processing is done.
> 
> In both inline protocol capable ethdevs and lookaside protocol capable
> cryptodevs, the packet would be received back in eth port & queue based
> on rte_flow rules and packet parsing after security processing. The API
> would behave like a loopback but with the additional security
> processing.
> 
> Signed-off-by: Anoob Joseph 
> Signed-off-by: Vidya Sagar Velumuri 
> Acked-by: Akhil Goyal 
> ---
> v4:
> Updated release notes
> 
> v3:
> * Resolved compilation error with 32 bit build
> 
> v2:
> * Added a new API for configuring security device to do Rx inject to a 
> specific
>   ethdev port
> * Rebased
> 
>  doc/guides/cryptodevs/features/default.ini |  1 +
>  doc/guides/rel_notes/release_23_11.rst | 19 +
>  lib/cryptodev/rte_cryptodev.h  |  2 +
>  lib/security/rte_security.c| 22 ++
>  lib/security/rte_security.h| 85 ++
>  lib/security/rte_security_driver.h | 44 +++
>  lib/security/version.map   |  3 +
>  7 files changed, 176 insertions(+)
> 
> diff --git a/doc/guides/cryptodevs/features/default.ini
> b/doc/guides/cryptodevs/features/default.ini
> index 6f637fa7e2..f411d4bab7 100644
> --- a/doc/guides/cryptodevs/features/default.ini
> +++ b/doc/guides/cryptodevs/features/default.ini
> @@ -34,6 +34,7 @@ Sym raw data path API  =
>  Cipher multiple data units =
>  Cipher wrapped key =
>  Inner checksum =
> +Rx inject  =
> 
>  ;
>  ; Supported crypto algorithms of a default crypto driver.
> diff --git a/doc/guides/rel_notes/release_23_11.rst
> b/doc/guides/rel_notes/release_23_11.rst
> index be51f00dbf..6853c907c9 100644
> --- a/doc/guides/rel_notes/release_23_11.rst
> +++ b/doc/guides/rel_notes/release_23_11.rst
> @@ -107,6 +107,25 @@ New Features
>enhancements to ``rte_crypto_op`` fields to handle all datapath 
> requirements
>of TLS and DTLS. The support is added for TLS 1.2, TLS 1.3 and DTLS 1.2.
> 
> +* **Added support for rte_security Rx inject API.**
> +
> +  Added Rx inject API to allow applications to submit packets for protocol
> +  offload and have them injected back to ethdev Rx so that further ethdev Rx
> +  actions (IP reassembly, packet parsing and flow lookups) can happen based 
> on
> +  inner packet.
> +
> +  The API when implemented by an ethdev, may be used to process packets that
> the
> +  application wants to process with inline protocol offload enabled 
> rte_security
> +  session. These can be packets that are received from other non-inline 
> capable
> +  ethdevs or can be packets that failed inline protocol offload (such as
> +  receiving fragmented ESP packets in case of inline IPsec offload).
> +
> +  The API when implemented by a cryptodev, can be used for injecting packets
> to
> +  ethdev Rx after IPsec processing and take advantage of ethdev Rx processing
> +  for the inner packet. The API helps application to avail ethdev Rx actions
> +  based on inner packet while working with rte_security sessions which cannot
> +  be accelerated in inline protocol offload mode.
> +
Reworded the above release notes as below.

* **Added support for rte_security Rx inject API.**

  Adde

[PATCH v1 0/2] FlexRAN SDK update for 23.11

[Hernan Vargas]

Upstreaming SDK workaround for ACC100 and updating documentation for new SDK 
release.

Hernan Vargas (2):
  baseband/acc: support ACC100 deRM corner case SDK
  doc: update FlexRAN SDK links

 doc/guides/bbdevs/turbo_sw.rst| 53 +---
 drivers/baseband/acc/meson.build  | 23 ++-
 drivers/baseband/acc/rte_acc100_pmd.c | 59 +--
 3 files changed, 107 insertions(+), 28 deletions(-)

-- 
2.37.1

[PATCH v1 1/2] baseband/acc: support ACC100 deRM corner case SDK

[Hernan Vargas]

Implement de-ratematch pre-processing for ACC100 SW corner cases.
Some specific 5GUL FEC corner cases may cause unintended back pressure
and in some cases a potential stability issue on the ACC100.
The PMD can detect such code block configuration and issue an info
message to the user.

Signed-off-by: Hernan Vargas 
---
 drivers/baseband/acc/meson.build  | 23 ++-
 drivers/baseband/acc/rte_acc100_pmd.c | 59 +--
 2 files changed, 77 insertions(+), 5 deletions(-)

diff --git a/drivers/baseband/acc/meson.build b/drivers/baseband/acc/meson.build
index 27a654b50153..84f4fea635ef 100644
--- a/drivers/baseband/acc/meson.build
+++ b/drivers/baseband/acc/meson.build
@@ -1,7 +1,28 @@
 # SPDX-License-Identifier: BSD-3-Clause
 # Copyright(c) 2020 Intel Corporation
 
-deps += ['bus_pci']
+# check for FlexRAN SDK libraries
+dep_dec5g = dependency('flexran_sdk_ldpc_decoder_5gnr', required: false)
+
+if dep_dec5g.found()
+ext_deps += cc.find_library('stdc++', required: true)
+ext_deps += cc.find_library('irc', required: true)
+ext_deps += cc.find_library('imf', required: true)
+ext_deps += cc.find_library('ipps', required: true)
+ext_deps += cc.find_library('svml', required: true)
+ext_deps += dep_dec5g
+ext_deps += dependency('flexran_sdk_ldpc_encoder_5gnr', required: true)
+ext_deps += dependency('flexran_sdk_LDPC_ratematch_5gnr', required: true)
+ext_deps += dependency('flexran_sdk_rate_dematching_5gnr', required: true)
+ext_deps += dependency('flexran_sdk_turbo', required: true)
+ext_deps += dependency('flexran_sdk_crc', required: true)
+ext_deps += dependency('flexran_sdk_rate_matching', required: true)
+ext_deps += dependency('flexran_sdk_common', required: true)
+cflags += ['-DRTE_BBDEV_SDK_AVX2']
+cflags += ['-DRTE_BBDEV_SDK_AVX512']
+endif
+
+deps += ['bbdev', 'bus_pci']
 
 sources = files('rte_acc100_pmd.c', 'rte_vrb_pmd.c')
 
diff --git a/drivers/baseband/acc/rte_acc100_pmd.c 
b/drivers/baseband/acc/rte_acc100_pmd.c
index 5362d39c302f..e45137212f68 100644
--- a/drivers/baseband/acc/rte_acc100_pmd.c
+++ b/drivers/baseband/acc/rte_acc100_pmd.c
@@ -22,6 +22,10 @@
 #include "acc101_pmd.h"
 #include "vrb_cfg.h"
 
+#ifdef RTE_BBDEV_SDK_AVX512
+#include 
+#endif
+
 #ifdef RTE_LIBRTE_BBDEV_DEBUG
 RTE_LOG_REGISTER_DEFAULT(acc100_logtype, DEBUG);
 #else
@@ -3058,7 +3062,8 @@ derm_workaround_recommended(struct rte_bbdev_op_ldpc_dec 
*ldpc_dec, struct acc_q
 /** Enqueue one decode operations for ACC100 device in CB mode */
 static inline int
 enqueue_ldpc_dec_one_op_cb(struct acc_queue *q, struct rte_bbdev_dec_op *op,
-   uint16_t total_enqueued_cbs, bool same_op)
+   uint16_t total_enqueued_cbs, bool same_op,
+   struct rte_bbdev_queue_data *q_data)
 {
int ret;
if (unlikely(check_bit(op->ldpc_dec.op_flags,
@@ -3113,8 +3118,54 @@ enqueue_ldpc_dec_one_op_cb(struct acc_queue *q, struct 
rte_bbdev_dec_op *op,
struct acc_fcw_ld *fcw;
uint32_t seg_total_left;
 
-   if (derm_workaround_recommended(&op->ldpc_dec, q))
-   rte_bbdev_log(INFO, "Corner case may require deRM 
pre-processing");
+   if (derm_workaround_recommended(&op->ldpc_dec, q)) {
+   #ifdef RTE_BBDEV_SDK_AVX512
+   struct rte_bbdev_op_ldpc_dec *dec = &op->ldpc_dec;
+   struct bblib_rate_dematching_5gnr_request derm_req;
+   struct bblib_rate_dematching_5gnr_response derm_resp;
+   uint8_t *in;
+
+   /* Checking input size is matching with E */
+   if (dec->input.data->data_len < (dec->cb_params.e % 
65536)) {
+   rte_bbdev_log(ERR, "deRM: Input size mismatch");
+   return -EFAULT;
+   }
+   /* Run first deRM processing in SW */
+   in = rte_pktmbuf_mtod_offset(dec->input.data, uint8_t 
*, in_offset);
+   derm_req.p_in = (int8_t *) in;
+   derm_req.p_harq = (int8_t *) q->derm_buffer;
+   derm_req.base_graph = dec->basegraph;
+   derm_req.zc = dec->z_c;
+   derm_req.ncb = dec->n_cb;
+   derm_req.e = dec->cb_params.e;
+   if (derm_req.e > ACC_MAX_E) {
+   rte_bbdev_log(WARNING,
+   "deRM: E %d > %d max",
+   derm_req.e, ACC_MAX_E);
+   derm_req.e = ACC_MAX_E;
+   }
+   derm_req.k0 = 0; /* Actual output from SDK */
+   derm_req.isretx = false;
+   derm_req.rvid = dec->rv_index;
+   derm_req.modulation_order = dec->q_m;
+   

[PATCH v1 2/2] doc: update FlexRAN SDK links

[Hernan Vargas]

Update FlexRAN SDK module link to use FEC_SDK_23.07.
Update compiler links to use ICX.
Update build SDK build instructions.

Signed-off-by: Hernan Vargas 
---
 doc/guides/bbdevs/turbo_sw.rst | 53 +++---
 1 file changed, 30 insertions(+), 23 deletions(-)

diff --git a/doc/guides/bbdevs/turbo_sw.rst b/doc/guides/bbdevs/turbo_sw.rst
index 1056e7a47af6..9445cf132785 100644
--- a/doc/guides/bbdevs/turbo_sw.rst
+++ b/doc/guides/bbdevs/turbo_sw.rst
@@ -67,11 +67,13 @@ FlexRAN SDK Download
 As an option it is possible to link this driver with FleXRAN SDK libraries
 which can enable real time signal processing using AVX instructions.
 
-These libraries are available through this `link 
`_.
+These libraries are available through this `link 
`_.
 
 After download is complete, the user needs to unpack and compile on their
 system before building DPDK.
 
+To get the FlexRAN FEC SDK User manual extract this `doxygen 
`_.
+
 The following table maps DPDK versions with past FlexRAN SDK releases:
 
 .. _table_flexran_releases:
@@ -83,6 +85,7 @@ The following table maps DPDK versions with past FlexRAN SDK 
releases:
=  
19.08 to 22.07 19.04
22.11+ 22.11
+   23.11+ FEC_SDK_23.07
=  
 
 FlexRAN SDK Installation
@@ -91,31 +94,34 @@ FlexRAN SDK Installation
 Note that the installation of these libraries is optional.
 
 The following are pre-requisites for building FlexRAN SDK Libraries:
- (a) An AVX2 or AVX512 supporting machine
- (b) CentOS Linux release 7.2.1511 (Core) operating system is advised
- (c) Intel ICC 18.0.1 20171018 compiler or more recent and related libraries
- ICC is `available with a free community license 
`_.
+ (a) An AVX512 supporting machine.
+ (b) Ubuntu Linux release 22.04 operating system is advised.
+ (c) Intel ICX 2023.0.0 compiler or more recent and related libraries.
+ ICX is available `here 
`_.
+ (d) `FlexRAN SDK Modules 
`_.
+ (e) CMake 3.9.2 (Minimum 2.8.12)
+ (f) Google Test 1.7.0 (Required to run the verification and compute 
performance tests)
+ (g) Math Kernel Library 18.0 (Required by some functions in SDK)
 
 The following instructions should be followed in this exact order:
 
-#. Set the environment variables:
+#. Clone the SDK (Folder name needs to end in 'sdk')
 
 .. code-block:: console
 
-source /linux/bin/compilervars.sh 
intel64 -platform linux
+git clone -b Branch_FEC_SDK_23.07 
https://github.com/intel/FlexRAN-FEC-SDK-Modules.git flexran_sdk
 
-#. Run the SDK extractor script and accept the license:
+#. Set the environment variables:
 
 .. code-block:: console
 
-cd 
-./FlexRAN-FEC-SDK-19-04.sh
+source /export_settings.sh -o -avx512
 
 #. Generate makefiles based on system configuration:
 
 .. code-block:: console
 
-cd /FlexRAN-FEC-SDK-19-04/sdk/
+cd 
 ./create-makefiles-linux.sh
 
 #. A build folder is generated in this form ``build--``, enter that
@@ -123,11 +129,11 @@ The following instructions should be followed in this 
exact order:
 
 .. code-block:: console
 
-cd build-avx512-icc/
-make && make install
+cd 
/build-${WIRELESS_SDK_TARGET_ISA}-${WIRELESS_SDK_TOOLCHAIN}/
+make -j$(nproc) && make install
 
-Initialization
---
+DPDK Initialization
+~~~
 
 In order to enable this virtual bbdev PMD, the user may:
 
@@ -142,18 +148,20 @@ In order to enable this virtual bbdev PMD, the user may:
 
 Example:
 
-.. code-block:: console
+.. code-block:: console
 
-export 
FLEXRAN_SDK=/FlexRAN-FEC-SDK-19-04/sdk/build-avx2-icc/install
-export 
DIR_WIRELESS_SDK=/FlexRAN-FEC-SDK-19-04/sdk/build-avx2-icc/
-export PKG_CONFIG_PATH=$DIR_WIRELESS_SDK/pkgcfg:$PKG_CONFIG_PATH
-cd build
-meson configure
+export 
FLEXRAN_SDK=/build-${WIRELESS_SDK_TARGET_ISA}-${WIRELESS_SDK_TOOLCHAIN}/install
+export 
DIR_WIRELESS_SDK=/build-${WIRELESS_SDK_TARGET_ISA}-${WIRELESS_SDK_TOOLCHAIN}
+export PKG_CONFIG_PATH=${DIR_WIRELESS_SDK}/pkgcfg:${PKG_CONFIG_PATH}
+cd build
+meson configure
 
 * For AVX512 machines with SDK libraries installed then both 4G and 5G can be 
enabled for full real time FEC capability.
   For AVX2 machines it is possible to only enable the 4G libraries and the PMD 
capabilitie

[PATCH v3] net/netvsc: add support for mtu_set

[Sam Andrew]

Add support for changing the netvsc MTU. The MTU can only be set at nvs
initialization, therefore to change the MTU the underlying vmbus
channel(s) are torn down and the vmbus device unmapped and remapped. The
existing rx and tx queue(s) are reconnected to the new vmbus channel(s).

Signed-off-by: Sam Andrew 
Acked-by: Stephen Hemminger 
---
v3: If device is not stopped when MTU change attempted, return -EBUSY,
instead of -EIO. Fix additional coding style issue.

v2: Fix coding style issue.
---
 drivers/bus/vmbus/vmbus_common.c |   6 +-
 drivers/net/netvsc/hn_ethdev.c   | 185 +--
 drivers/net/netvsc/hn_rndis.c|   7 ++
 drivers/net/netvsc/hn_rndis.h|   1 +
 drivers/net/netvsc/hn_var.h  |   3 +-
 drivers/net/netvsc/hn_vf.c   |  23 +++-
 6 files changed, 190 insertions(+), 35 deletions(-)

diff --git a/drivers/bus/vmbus/vmbus_common.c b/drivers/bus/vmbus/vmbus_common.c
index 95f3ad78bc..feb9fbe33f 100644
--- a/drivers/bus/vmbus/vmbus_common.c
+++ b/drivers/bus/vmbus/vmbus_common.c
@@ -39,6 +39,9 @@ vmbus_map_resource(void *requested_addr, int fd, off_t 
offset, size_t size,
  "mmap(%d, %p, %zu, %ld) failed: %s",
  fd, requested_addr, size, (long)offset,
  strerror(errno));
+   } else {
+   VMBUS_LOG(DEBUG, "  VMBUS memory mapped at %p",
+ mapaddr);
}
return mapaddr;
 }
@@ -55,9 +58,10 @@ vmbus_unmap_resource(void *requested_addr, size_t size)
VMBUS_LOG(ERR, "munmap(%p, 0x%lx) failed: %s",
requested_addr, (unsigned long)size,
strerror(errno));
-   } else
+   } else {
VMBUS_LOG(DEBUG, "  VMBUS memory unmapped at %p",
  requested_addr);
+   }
 }
 
 /**
diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
index d0bbc0a4c0..993ed14f52 100644
--- a/drivers/net/netvsc/hn_ethdev.c
+++ b/drivers/net/netvsc/hn_ethdev.c
@@ -1059,37 +1059,6 @@ hn_dev_close(struct rte_eth_dev *dev)
return ret;
 }
 
-static const struct eth_dev_ops hn_eth_dev_ops = {
-   .dev_configure  = hn_dev_configure,
-   .dev_start  = hn_dev_start,
-   .dev_stop   = hn_dev_stop,
-   .dev_close  = hn_dev_close,
-   .dev_infos_get  = hn_dev_info_get,
-   .txq_info_get   = hn_dev_tx_queue_info,
-   .rxq_info_get   = hn_dev_rx_queue_info,
-   .dev_supported_ptypes_get = hn_vf_supported_ptypes,
-   .promiscuous_enable = hn_dev_promiscuous_enable,
-   .promiscuous_disable= hn_dev_promiscuous_disable,
-   .allmulticast_enable= hn_dev_allmulticast_enable,
-   .allmulticast_disable   = hn_dev_allmulticast_disable,
-   .set_mc_addr_list   = hn_dev_mc_addr_list,
-   .reta_update= hn_rss_reta_update,
-   .reta_query = hn_rss_reta_query,
-   .rss_hash_update= hn_rss_hash_update,
-   .rss_hash_conf_get  = hn_rss_hash_conf_get,
-   .tx_queue_setup = hn_dev_tx_queue_setup,
-   .tx_queue_release   = hn_dev_tx_queue_release,
-   .tx_done_cleanup= hn_dev_tx_done_cleanup,
-   .rx_queue_setup = hn_dev_rx_queue_setup,
-   .rx_queue_release   = hn_dev_rx_queue_release,
-   .link_update= hn_dev_link_update,
-   .stats_get  = hn_dev_stats_get,
-   .stats_reset= hn_dev_stats_reset,
-   .xstats_get = hn_dev_xstats_get,
-   .xstats_get_names   = hn_dev_xstats_get_names,
-   .xstats_reset   = hn_dev_xstats_reset,
-};
-
 /*
  * Setup connection between PMD and kernel.
  */
@@ -1129,12 +1098,158 @@ hn_detach(struct hn_data *hv)
hn_rndis_detach(hv);
 }
 
+/*
+ * Connects EXISTING rx/tx queues to NEW vmbus channel(s), and
+ * re-initializes NDIS and RNDIS, including re-sending initial
+ * NDIS/RNDIS configuration. To be used after the underlying vmbus
+ * has been un- and re-mapped, e.g. as must happen when the device
+ * MTU is changed.
+ */
+static int
+hn_reinit(struct rte_eth_dev *dev, uint16_t mtu)
+{
+   struct hn_data *hv = dev->data->dev_private;
+   struct hn_rx_queue **rxqs = (struct hn_rx_queue **)dev->data->rx_queues;
+   struct hn_tx_queue **txqs = (struct hn_tx_queue **)dev->data->tx_queues;
+   int i, ret = 0;
+
+   /* Point primary queues at new primary channel */
+   rxqs[0]->chan = hv->channels[0];
+   txqs[0]->chan = hv->channels[0];
+
+   ret = hn_attach(hv, mtu);
+   if (ret)
+   return ret;
+
+   /* Create vmbus subchannels, additional RNDIS configuration */
+   ret = hn_dev_configure(dev);
+   if (ret)
+   return ret;
+
+   /* Point any additional queues at new subchannels */
+   for (i = 1; i < dev->data->nb_rx_queues; i++)
+   r

RE: [PATCH v3] net/netvsc: add support for mtu_set

[Long Li]

> Subject: [PATCH v3] net/netvsc: add support for mtu_set
> 
> Add support for changing the netvsc MTU. The MTU can only be set at nvs
> initialization, therefore to change the MTU the underlying vmbus
> channel(s) are torn down and the vmbus device unmapped and remapped. The
> existing rx and tx queue(s) are reconnected to the new vmbus channel(s).
> 
> Signed-off-by: Sam Andrew 
> Acked-by: Stephen Hemminger 

Acked-by: Long Li 

> ---
> v3: If device is not stopped when MTU change attempted, return -EBUSY, instead
> of -EIO. Fix additional coding style issue.
> 
> v2: Fix coding style issue.
> ---
>  drivers/bus/vmbus/vmbus_common.c |   6 +-
>  drivers/net/netvsc/hn_ethdev.c   | 185 +--
>  drivers/net/netvsc/hn_rndis.c|   7 ++
>  drivers/net/netvsc/hn_rndis.h|   1 +
>  drivers/net/netvsc/hn_var.h  |   3 +-
>  drivers/net/netvsc/hn_vf.c   |  23 +++-
>  6 files changed, 190 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/bus/vmbus/vmbus_common.c
> b/drivers/bus/vmbus/vmbus_common.c
> index 95f3ad78bc..feb9fbe33f 100644
> --- a/drivers/bus/vmbus/vmbus_common.c
> +++ b/drivers/bus/vmbus/vmbus_common.c
> @@ -39,6 +39,9 @@ vmbus_map_resource(void *requested_addr, int fd, off_t
> offset, size_t size,
> "mmap(%d, %p, %zu, %ld) failed: %s",
> fd, requested_addr, size, (long)offset,
> strerror(errno));
> + } else {
> + VMBUS_LOG(DEBUG, "  VMBUS memory mapped at %p",
> +   mapaddr);
>   }
>   return mapaddr;
>  }
> @@ -55,9 +58,10 @@ vmbus_unmap_resource(void *requested_addr, size_t
> size)
>   VMBUS_LOG(ERR, "munmap(%p, 0x%lx) failed: %s",
>   requested_addr, (unsigned long)size,
>   strerror(errno));
> - } else
> + } else {
>   VMBUS_LOG(DEBUG, "  VMBUS memory unmapped at %p",
> requested_addr);
> + }
>  }
> 
>  /**
> diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
> index d0bbc0a4c0..993ed14f52 100644
> --- a/drivers/net/netvsc/hn_ethdev.c
> +++ b/drivers/net/netvsc/hn_ethdev.c
> @@ -1059,37 +1059,6 @@ hn_dev_close(struct rte_eth_dev *dev)
>   return ret;
>  }
> 
> -static const struct eth_dev_ops hn_eth_dev_ops = {
> - .dev_configure  = hn_dev_configure,
> - .dev_start  = hn_dev_start,
> - .dev_stop   = hn_dev_stop,
> - .dev_close  = hn_dev_close,
> - .dev_infos_get  = hn_dev_info_get,
> - .txq_info_get   = hn_dev_tx_queue_info,
> - .rxq_info_get   = hn_dev_rx_queue_info,
> - .dev_supported_ptypes_get = hn_vf_supported_ptypes,
> - .promiscuous_enable = hn_dev_promiscuous_enable,
> - .promiscuous_disable= hn_dev_promiscuous_disable,
> - .allmulticast_enable= hn_dev_allmulticast_enable,
> - .allmulticast_disable   = hn_dev_allmulticast_disable,
> - .set_mc_addr_list   = hn_dev_mc_addr_list,
> - .reta_update= hn_rss_reta_update,
> - .reta_query = hn_rss_reta_query,
> - .rss_hash_update= hn_rss_hash_update,
> - .rss_hash_conf_get  = hn_rss_hash_conf_get,
> - .tx_queue_setup = hn_dev_tx_queue_setup,
> - .tx_queue_release   = hn_dev_tx_queue_release,
> - .tx_done_cleanup= hn_dev_tx_done_cleanup,
> - .rx_queue_setup = hn_dev_rx_queue_setup,
> - .rx_queue_release   = hn_dev_rx_queue_release,
> - .link_update= hn_dev_link_update,
> - .stats_get  = hn_dev_stats_get,
> - .stats_reset= hn_dev_stats_reset,
> - .xstats_get = hn_dev_xstats_get,
> - .xstats_get_names   = hn_dev_xstats_get_names,
> - .xstats_reset   = hn_dev_xstats_reset,
> -};
> -
>  /*
>   * Setup connection between PMD and kernel.
>   */
> @@ -1129,12 +1098,158 @@ hn_detach(struct hn_data *hv)
>   hn_rndis_detach(hv);
>  }
> 
> +/*
> + * Connects EXISTING rx/tx queues to NEW vmbus channel(s), and
> + * re-initializes NDIS and RNDIS, including re-sending initial
> + * NDIS/RNDIS configuration. To be used after the underlying vmbus
> + * has been un- and re-mapped, e.g. as must happen when the device
> + * MTU is changed.
> + */
> +static int
> +hn_reinit(struct rte_eth_dev *dev, uint16_t mtu) {
> + struct hn_data *hv = dev->data->dev_private;
> + struct hn_rx_queue **rxqs = (struct hn_rx_queue **)dev->data-
> >rx_queues;
> + struct hn_tx_queue **txqs = (struct hn_tx_queue **)dev->data-
> >tx_queues;
> + int i, ret = 0;
> +
> + /* Point primary queues at new primary channel */
> + rxqs[0]->chan = hv->channels[0];
> + txqs[0]->chan = hv->channels[0];
> +
> + ret = hn_attach(hv, mtu);
> + if (ret)
> + return ret;
> +
> + /* Create vmbus subchannels, additional RNDIS configuration */
> + r

Re: [PATCH v2 13/15] crypto/cnxk: add support for raw APIs

[Thomas Monjalon]

26/09/2023 07:58, Tejasree Kondoj:
> From: Anoob Joseph 
> 
> Add crypto RAW API support in cnxk PMD
> Enable the flag to allow execution of raw test suite.
> 
> Signed-off-by: Vidya Sagar Velumuri 
> Signed-off-by: Anoob Joseph 
> ---
>  doc/guides/cryptodevs/features/cn10k.ini  |   1 +
>  drivers/crypto/cnxk/cn10k_cryptodev_ops.c | 459 ++
>  drivers/crypto/cnxk/cnxk_cryptodev.c  |  20 +-
>  drivers/crypto/cnxk/cnxk_cryptodev_ops.h  |   1 +
>  drivers/crypto/cnxk/cnxk_se.h | 293 ++
>  5 files changed, 761 insertions(+), 13 deletions(-)

This patch does not compile on RISC-V:
drivers/crypto/cnxk/cnxk_se.h:499:25: error: argument 2 null where non-null 
expected

[PATCH v6 00/12] VRB2 bbdev PMD introduction

[Nicolas Chautru]

v6: removed one empty line typo.
Thanks

v5: missed a line in v4 patch 2/12.
change to 9/12 with suggested refactor.

v4: updates based on Maxime's suggestions:
- FFT windowing exposure tweaked to show number of windows
as well in capacity to be more generic and future-proof.
- few code refactor notably to avoid code duplication
- cosmetic and doc update

v3: updates based on v2 review:
- split into smaller incremental commits
- FFT windowing exposed through a more generic structure
- refactor using wrapper functions to manage device variants
- removed custom dump function
- consider the request unsupport SO option as an error
instead of fall-back. 
- cosmetic and doc update.
Thanks

v2: doc, comments and commit-log updates.

This serie includes changes to the VRB BBDEV PMD for 23.11.

This allows the VRB unified driver to support the new VRB2
implementation variant on GNR-D.

This also include minor change to the dev_info to expose FFT version
flexibility to expose information to the application on what windows
LUT is configured dynamically on the device.

Nicolas Chautru (12):
  bbdev: add FFT window width member in driver info
  baseband/acc: add FFT window width in the VRB PMD
  baseband/acc: remove the 4G SO capability for VRB1
  baseband/acc: allocate FCW memory separately
  baseband/acc: add support for MLD operation
  baseband/acc: refactor to allow unified driver extension
  baseband/acc: adding VRB2 device variant
  baseband/acc: add FEC capabilities for the VRB2 variant
  baseband/acc: add FFT support to VRB2 variant
  baseband/acc: add MLD support in VRB2 variant
  baseband/acc: add support for VRB2 engine error detection
  baseband/acc: add configure helper for VRB2

 doc/guides/bbdevs/features/vrb2.ini|   14 +
 doc/guides/bbdevs/index.rst|1 +
 doc/guides/bbdevs/vrb1.rst |4 -
 doc/guides/bbdevs/vrb2.rst |  206 
 doc/guides/rel_notes/release_23_11.rst |3 +
 drivers/baseband/acc/acc100_pmd.h  |2 +
 drivers/baseband/acc/acc_common.h  |  185 ++-
 drivers/baseband/acc/rte_acc100_pmd.c  |6 +-
 drivers/baseband/acc/rte_vrb_pmd.c | 1571 +---
 drivers/baseband/acc/vrb1_pf_enum.h|   17 +-
 drivers/baseband/acc/vrb2_pf_enum.h|  124 ++
 drivers/baseband/acc/vrb2_vf_enum.h|  121 ++
 drivers/baseband/acc/vrb_cfg.h |   16 +
 drivers/baseband/acc/vrb_pmd.h |  173 ++-
 lib/bbdev/rte_bbdev.h  |2 +
 lib/bbdev/rte_bbdev_op.h   |2 +
 16 files changed, 2258 insertions(+), 189 deletions(-)
 create mode 100644 doc/guides/bbdevs/features/vrb2.ini
 create mode 100644 doc/guides/bbdevs/vrb2.rst
 create mode 100644 drivers/baseband/acc/vrb2_pf_enum.h
 create mode 100644 drivers/baseband/acc/vrb2_vf_enum.h

-- 
2.34.1

[PATCH v6 01/12] bbdev: add FFT window width member in driver info

[Nicolas Chautru]

This exposes the width of each windowing shape being configured on
the device. This allows to distinguish different version of the
flexible pointwise windowing applied to the FFT and expose
this platform configuration to the application.
This also add the total number of windows supported in the capability.

The SRS processing chain
(https://doc.dpdk.org/guides/prog_guide/bbdev.html#bbdev-fft-operation)
includes a pointwise multiplication by time window whose shape width
needs to be exposed, notably for accurate SNR estimate.
Using that mechanism user application can retrieve information related
to what has been dynamically programmed on any bbdev device
supporting FFT windowing operation.

Signed-off-by: Nicolas Chautru 
Reviewed-by: Maxime Coquelin 
---
 lib/bbdev/rte_bbdev.h| 2 ++
 lib/bbdev/rte_bbdev_op.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h
index 2985c9f42b..d12e2e7fbc 100644
--- a/lib/bbdev/rte_bbdev.h
+++ b/lib/bbdev/rte_bbdev.h
@@ -349,6 +349,8 @@ struct rte_bbdev_driver_info {
const struct rte_bbdev_op_cap *capabilities;
/** Device cpu_flag requirements */
const enum rte_cpu_flag_t *cpu_flag_reqs;
+   /** FFT windowing width for 2048 FFT - size defined in capability. */
+   uint16_t *fft_window_width;
 };
 
 /** Macro used at end of bbdev PMD list */
diff --git a/lib/bbdev/rte_bbdev_op.h b/lib/bbdev/rte_bbdev_op.h
index 693baa8386..369ac331bf 100644
--- a/lib/bbdev/rte_bbdev_op.h
+++ b/lib/bbdev/rte_bbdev_op.h
@@ -905,6 +905,8 @@ struct rte_bbdev_op_cap_fft {
uint16_t num_buffers_src;
/** Num output code block buffers. */
uint16_t num_buffers_dst;
+   /** Number of FFT windows supported. */
+   uint16_t fft_windows_num;
 };
 
 /** List of the capabilities for the MLD */
-- 
2.34.1

[PATCH v6 02/12] baseband/acc: add FFT window width in the VRB PMD

[Nicolas Chautru]

This allows to expose the FFT window width being introduced in
previous commit based on what is configured dynamically on the
device platform.

Signed-off-by: Nicolas Chautru 
Reviewed-by: Maxime Coquelin 
---
 drivers/baseband/acc/acc_common.h  |  5 
 drivers/baseband/acc/rte_vrb_pmd.c | 41 +-
 2 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/drivers/baseband/acc/acc_common.h 
b/drivers/baseband/acc/acc_common.h
index 5bb00746c3..cfdadcc473 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -131,6 +131,8 @@
 #define ACC_LIM_31 20 /* 0.31 */
 #define ACC_MAX_E (128 * 1024 - 2)
 
+#define ACC_MAX_FFT_WIN  16
+
 /* Helper macro for logging */
 #define rte_acc_log(level, fmt, ...) \
rte_log(RTE_LOG_ ## level, RTE_LOG_NOTICE, fmt "\n", \
@@ -512,6 +514,8 @@ struct acc_deq_intr_details {
 enum {
ACC_VF2PF_STATUS_REQUEST = 1,
ACC_VF2PF_USING_VF = 2,
+   ACC_VF2PF_LUT_VER_REQUEST = 3,
+   ACC_VF2PF_FFT_WIN_REQUEST = 4,
 };
 
 
@@ -558,6 +562,7 @@ struct acc_device {
queue_offset_fun_t queue_offset;  /* Device specific queue offset */
uint16_t num_qgroups;
uint16_t num_aqs;
+   uint16_t fft_window_width[ACC_MAX_FFT_WIN]; /* FFT windowing size. */
 };
 
 /* Structure associated with each queue. */
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index 9e5a73c9c7..b86e814f8f 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -183,6 +183,37 @@ vrb_check_device_enable(struct rte_bbdev *dev)
return false;
 }
 
+static inline void
+vrb_vf2pf(struct acc_device *d, unsigned int payload)
+{
+   acc_reg_write(d, d->reg_addr->vf2pf_doorbell, payload);
+}
+
+/* Request device FFT windowing information. */
+static inline void
+vrb_device_fft_win(struct rte_bbdev *dev)
+{
+   struct acc_device *d = dev->data->dev_private;
+   uint32_t reg, time_out = 0, win;
+
+   if (d->pf_device)
+   return;
+
+   /* Check from the device the first time. */
+   if (d->fft_window_width[0] == 0) {
+   for (win = 0; win < ACC_MAX_FFT_WIN; win++) {
+   vrb_vf2pf(d, ACC_VF2PF_FFT_WIN_REQUEST | win);
+   reg = acc_reg_read(d, d->reg_addr->pf2vf_doorbell);
+   while ((time_out < ACC_STATUS_TO) && (reg == 
RTE_BBDEV_DEV_NOSTATUS)) {
+   usleep(ACC_STATUS_WAIT); /*< Wait or VF->PF->VF 
Comms. */
+   reg = acc_reg_read(d, 
d->reg_addr->pf2vf_doorbell);
+   time_out++;
+   }
+   d->fft_window_width[win] = reg;
+   }
+   }
+}
+
 /* Fetch configuration enabled for the PF/VF using MMIO Read (slow). */
 static inline void
 fetch_acc_config(struct rte_bbdev *dev)
@@ -206,6 +237,8 @@ fetch_acc_config(struct rte_bbdev *dev)
return;
}
 
+   vrb_device_fft_win(dev);
+
d->ddr_size = 0;
 
/* Single VF Bundle by VF. */
@@ -271,12 +304,6 @@ fetch_acc_config(struct rte_bbdev *dev)
acc_conf->q_fft.aq_depth_log2);
 }
 
-static inline void
-vrb_vf2pf(struct acc_device *d, unsigned int payload)
-{
-   acc_reg_write(d, d->reg_addr->vf2pf_doorbell, payload);
-}
-
 /* Request device status information. */
 static inline uint32_t
 vrb_device_status(struct rte_bbdev *dev)
@@ -1085,6 +1112,7 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)
RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
.num_buffers_dst =
RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+   .fft_windows_num = ACC_MAX_FFT_WIN,
}
},
RTE_BBDEV_END_OF_CAPABILITIES_LIST()
@@ -1100,6 +1128,7 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)
fetch_acc_config(dev);
/* Check the status of device. */
dev_info->device_status = vrb_device_status(dev);
+   dev_info->fft_window_width = d->fft_window_width;
 
/* Exposed number of queues. */
dev_info->num_queues[RTE_BBDEV_OP_NONE] = 0;
-- 
2.34.1

[PATCH v6 03/12] baseband/acc: remove the 4G SO capability for VRB1

[Nicolas Chautru]

This removes the specific capability and support of LTE Decoder
Soft Output option on the VRB1 PMD.

This is triggered as a vendor decision to defeature the related optional
capability so that to avoid theoretical risk of race conditions
impacting the device reliability. That optional APP LLR output is
not impacting the actual decoder hard output.

Signed-off-by: Nicolas Chautru 
Reviewed-by: Maxime Coquelin 
---
 doc/guides/bbdevs/vrb1.rst |  4 
 drivers/baseband/acc/rte_vrb_pmd.c | 10 ++
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/doc/guides/bbdevs/vrb1.rst b/doc/guides/bbdevs/vrb1.rst
index 9c48d30964..fdefb20651 100644
--- a/doc/guides/bbdevs/vrb1.rst
+++ b/doc/guides/bbdevs/vrb1.rst
@@ -71,11 +71,7 @@ The Intel vRAN Boost v1.0 PMD supports the following bbdev 
capabilities:
- ``RTE_BBDEV_TURBO_EARLY_TERMINATION``: set early termination feature.
- ``RTE_BBDEV_TURBO_DEC_SCATTER_GATHER``: supports scatter-gather for 
input/output data.
- ``RTE_BBDEV_TURBO_HALF_ITERATION_EVEN``: set half iteration granularity.
-   - ``RTE_BBDEV_TURBO_SOFT_OUTPUT``: set the APP LLR soft output.
-   - ``RTE_BBDEV_TURBO_EQUALIZER``: set the turbo equalizer feature.
-   - ``RTE_BBDEV_TURBO_SOFT_OUT_SATURATE``: set the soft output saturation.
- ``RTE_BBDEV_TURBO_CONTINUE_CRC_MATCH``: set to run an extra odd iteration 
after CRC match.
-   - ``RTE_BBDEV_TURBO_NEG_LLR_1_BIT_SOFT_OUT``: set if negative APP LLR 
output supported.
- ``RTE_BBDEV_TURBO_MAP_DEC``: supports flexible parallel MAP engine 
decoding.
 
 * For the FFT operation:
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index b86e814f8f..1f7f82deae 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -1024,15 +1024,11 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)
RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE |
RTE_BBDEV_TURBO_CRC_TYPE_24B |
RTE_BBDEV_TURBO_DEC_CRC_24B_DROP |
-   RTE_BBDEV_TURBO_EQUALIZER |
-   RTE_BBDEV_TURBO_SOFT_OUT_SATURATE |
RTE_BBDEV_TURBO_HALF_ITERATION_EVEN |
RTE_BBDEV_TURBO_CONTINUE_CRC_MATCH |
-   RTE_BBDEV_TURBO_SOFT_OUTPUT |
RTE_BBDEV_TURBO_EARLY_TERMINATION |
RTE_BBDEV_TURBO_DEC_INTERRUPTS |
RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN |
-   RTE_BBDEV_TURBO_NEG_LLR_1_BIT_SOFT_OUT |
RTE_BBDEV_TURBO_MAP_DEC |
RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP |
RTE_BBDEV_TURBO_DEC_SCATTER_GATHER,
@@ -1982,6 +1978,12 @@ enqueue_dec_one_op_cb(struct acc_queue *q, struct 
rte_bbdev_dec_op *op,
struct rte_mbuf *input, *h_output_head, *h_output,
*s_output_head, *s_output;
 
+   if ((q->d->device_variant == VRB1_VARIANT) &&
+   (check_bit(op->turbo_dec.op_flags, 
RTE_BBDEV_TURBO_SOFT_OUTPUT))) {
+   /* SO not supported for VRB1. */
+   return -EPERM;
+   }
+
desc = acc_desc(q, total_enqueued_cbs);
vrb_fcw_td_fill(op, &desc->req.fcw_td);
 
-- 
2.34.1

[PATCH v6 04/12] baseband/acc: allocate FCW memory separately

[Nicolas Chautru]

This allows more flexibility to the FCW size for the
unified driver. No actual functional change.

Signed-off-by: Nicolas Chautru 
Reviewed-by: Maxime Coquelin 
---
 drivers/baseband/acc/acc_common.h  |  4 +++-
 drivers/baseband/acc/rte_vrb_pmd.c | 25 -
 2 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/baseband/acc/acc_common.h 
b/drivers/baseband/acc/acc_common.h
index cfdadcc473..da8a2321f8 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -101,6 +101,7 @@
 #define ACC_NUM_QGRPS_PER_WORD 8
 #define ACC_MAX_NUM_QGRPS  32
 #define ACC_RING_SIZE_GRANULARITY  64
+#define ACC_MAX_FCW_SIZE  128
 
 /* Constants from K0 computation from 3GPP 38.212 Table 5.4.2.1-2 */
 #define ACC_N_ZC_1 66 /* N = 66 Zc for BG 1 */
@@ -586,13 +587,14 @@ struct __rte_cache_aligned acc_queue {
uint32_t aq_enqueued;  /* Count how many "batches" have been enqueued */
uint32_t aq_dequeued;  /* Count how many "batches" have been dequeued */
uint32_t irq_enable;  /* Enable ops dequeue interrupts if set to 1 */
-   struct rte_mempool *fcw_mempool;  /* FCW mempool */
enum rte_bbdev_op_type op_type;  /* Type of this Queue: TE or TD */
/* Internal Buffers for loopback input */
uint8_t *lb_in;
uint8_t *lb_out;
+   uint8_t *fcw_ring;
rte_iova_t lb_in_addr_iova;
rte_iova_t lb_out_addr_iova;
+   rte_iova_t fcw_ring_addr_iova;
int8_t *derm_buffer; /* interim buffer for de-rm in SDK */
struct acc_device *d;
 };
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index 1f7f82deae..378abcc3e6 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -889,6 +889,25 @@ vrb_queue_setup(struct rte_bbdev *dev, uint16_t queue_id,
goto free_companion_ring_addr;
}
 
+   q->fcw_ring = rte_zmalloc_socket(dev->device->driver->name,
+   ACC_MAX_FCW_SIZE * d->sw_ring_max_depth,
+   RTE_CACHE_LINE_SIZE, conf->socket);
+   if (q->fcw_ring == NULL) {
+   rte_bbdev_log(ERR, "Failed to allocate fcw_ring memory");
+   ret = -ENOMEM;
+   goto free_companion_ring_addr;
+   }
+   q->fcw_ring_addr_iova = rte_malloc_virt2iova(q->fcw_ring);
+
+   /* For FFT we need to store the FCW separately */
+   if (conf->op_type == RTE_BBDEV_OP_FFT) {
+   for (desc_idx = 0; desc_idx < d->sw_ring_max_depth; desc_idx++) 
{
+   desc = q->ring_addr + desc_idx;
+   desc->req.data_ptrs[0].address = q->fcw_ring_addr_iova +
+   desc_idx * ACC_MAX_FCW_SIZE;
+   }
+   }
+
q->qgrp_id = (q_idx >> VRB1_GRP_ID_SHIFT) & 0xF;
q->vf_id = (q_idx >> VRB1_VF_ID_SHIFT)  & 0x3F;
q->aq_id = q_idx & 0xF;
@@ -1000,6 +1019,7 @@ vrb_queue_release(struct rte_bbdev *dev, uint16_t q_id)
if (q != NULL) {
/* Mark the Queue as un-assigned. */
d->q_assigned_bit_map[q->qgrp_id] &= (~0ULL - (1 << (uint64_t) 
q->aq_id));
+   rte_free(q->fcw_ring);
rte_free(q->companion_ring_addr);
rte_free(q->lb_in);
rte_free(q->lb_out);
@@ -3234,7 +3254,10 @@ vrb_enqueue_fft_one_op(struct acc_queue *q, struct 
rte_bbdev_fft_op *op,
output = op->fft.base_output.data;
in_offset = op->fft.base_input.offset;
out_offset = op->fft.base_output.offset;
-   fcw = &desc->req.fcw_fft;
+
+   fcw = (struct acc_fcw_fft *) (q->fcw_ring +
+   ((q->sw_ring_head + total_enqueued_cbs) & 
q->sw_ring_wrap_mask)
+   * ACC_MAX_FCW_SIZE);
 
vrb1_fcw_fft_fill(op, fcw);
vrb1_dma_desc_fft_fill(op, &desc->req, input, output, &in_offset, 
&out_offset);
-- 
2.34.1

[PATCH v6 05/12] baseband/acc: add support for MLD operation

[Nicolas Chautru]

There is no functionality related to the MLD operation
but allows the unified PMD to support the operation
being added moving forward.

Signed-off-by: Nicolas Chautru 
Reviewed-by: Maxime Coquelin 
---
 drivers/baseband/acc/acc_common.h  |  1 +
 drivers/baseband/acc/rte_vrb_pmd.c | 39 --
 drivers/baseband/acc/vrb_pmd.h | 12 +
 3 files changed, 45 insertions(+), 7 deletions(-)

diff --git a/drivers/baseband/acc/acc_common.h 
b/drivers/baseband/acc/acc_common.h
index da8a2321f8..06778bd6fc 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -87,6 +87,7 @@
 #define ACC_FCW_LE_BLEN32
 #define ACC_FCW_LD_BLEN36
 #define ACC_FCW_FFT_BLEN   28
+#define ACC_FCW_MLDTS_BLEN 32
 #define ACC_5GUL_SIZE_016
 #define ACC_5GUL_SIZE_140
 #define ACC_5GUL_OFFSET_0  36
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index 378abcc3e6..0979de0354 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -37,7 +37,7 @@ vrb1_queue_offset(bool pf_device, uint8_t vf_id, uint8_t 
qgrp_id, uint16_t aq_id
return ((qgrp_id << 7) + (aq_id << 3) + VRB1_VfQmgrIngressAq);
 }
 
-enum {UL_4G = 0, UL_5G, DL_4G, DL_5G, FFT, NUM_ACC};
+enum {UL_4G = 0, UL_5G, DL_4G, DL_5G, FFT, MLD, NUM_ACC};
 
 /* Return the accelerator enum for a Queue Group Index. */
 static inline int
@@ -53,6 +53,7 @@ accFromQgid(int qg_idx, const struct rte_acc_conf *acc_conf)
NumQGroupsPerFn[DL_4G] = acc_conf->q_dl_4g.num_qgroups;
NumQGroupsPerFn[DL_5G] = acc_conf->q_dl_5g.num_qgroups;
NumQGroupsPerFn[FFT] = acc_conf->q_fft.num_qgroups;
+   NumQGroupsPerFn[MLD] = acc_conf->q_mld.num_qgroups;
for (acc = UL_4G;  acc < NUM_ACC; acc++)
for (qgIdx = 0; qgIdx < NumQGroupsPerFn[acc]; qgIdx++)
accQg[qgIndex++] = acc;
@@ -83,6 +84,9 @@ qtopFromAcc(struct rte_acc_queue_topology **qtop, int 
acc_enum, struct rte_acc_c
case FFT:
p_qtop = &(acc_conf->q_fft);
break;
+   case MLD:
+   p_qtop = &(acc_conf->q_mld);
+   break;
default:
/* NOTREACHED. */
rte_bbdev_log(ERR, "Unexpected error evaluating %s using %d", 
__func__, acc_enum);
@@ -139,6 +143,9 @@ initQTop(struct rte_acc_conf *acc_conf)
acc_conf->q_fft.num_aqs_per_groups = 0;
acc_conf->q_fft.num_qgroups = 0;
acc_conf->q_fft.first_qgroup_index = -1;
+   acc_conf->q_mld.num_aqs_per_groups = 0;
+   acc_conf->q_mld.num_qgroups = 0;
+   acc_conf->q_mld.first_qgroup_index = -1;
 }
 
 static inline void
@@ -283,7 +290,7 @@ fetch_acc_config(struct rte_bbdev *dev)
}
 
rte_bbdev_log_debug(
-   "%s Config LLR SIGN IN/OUT %s %s QG %u %u %u %u %u AQ 
%u %u %u %u %u Len %u %u %u %u %u\n",
+   "%s Config LLR SIGN IN/OUT %s %s QG %u %u %u %u %u %u 
AQ %u %u %u %u %u %u Len %u %u %u %u %u %u\n",
(d->pf_device) ? "PF" : "VF",
(acc_conf->input_pos_llr_1_bit) ? "POS" : "NEG",
(acc_conf->output_pos_llr_1_bit) ? "POS" : "NEG",
@@ -292,16 +299,19 @@ fetch_acc_config(struct rte_bbdev *dev)
acc_conf->q_ul_5g.num_qgroups,
acc_conf->q_dl_5g.num_qgroups,
acc_conf->q_fft.num_qgroups,
+   acc_conf->q_mld.num_qgroups,
acc_conf->q_ul_4g.num_aqs_per_groups,
acc_conf->q_dl_4g.num_aqs_per_groups,
acc_conf->q_ul_5g.num_aqs_per_groups,
acc_conf->q_dl_5g.num_aqs_per_groups,
acc_conf->q_fft.num_aqs_per_groups,
+   acc_conf->q_mld.num_aqs_per_groups,
acc_conf->q_ul_4g.aq_depth_log2,
acc_conf->q_dl_4g.aq_depth_log2,
acc_conf->q_ul_5g.aq_depth_log2,
acc_conf->q_dl_5g.aq_depth_log2,
-   acc_conf->q_fft.aq_depth_log2);
+   acc_conf->q_fft.aq_depth_log2,
+   acc_conf->q_mld.aq_depth_log2);
 }
 
 /* Request device status information. */
@@ -338,7 +348,7 @@ vrb_check_ir(struct acc_device *acc_dev)
 
while (ring_data->valid) {
if ((ring_data->int_nb < ACC_PF_INT_DMA_DL_DESC_IRQ) || (
-   ring_data->int_nb > 
ACC_PF_INT_DMA_DL5G_DESC_IRQ)) {
+   ring_data->int_nb > 
ACC_PF_INT_DMA_MLD_DESC_IRQ)) {
rte_bbdev_log(WARNING, "InfoRing: ITR:%d Info:0x%x",
ring_data->int_nb, 
ring_data->detailed_info);
/* Initialize Info Ring entry and m

[PATCH v6 06/12] baseband/acc: refactor to allow unified driver extension

[Nicolas Chautru]

Adding a few functions and common code prior to
extending the VRB driver.

Signed-off-by: Nicolas Chautru 
Reviewed-by: Maxime Coquelin 
---
 drivers/baseband/acc/acc_common.h  | 175 ++---
 drivers/baseband/acc/rte_vrb_pmd.c |  58 +-
 2 files changed, 190 insertions(+), 43 deletions(-)

diff --git a/drivers/baseband/acc/acc_common.h 
b/drivers/baseband/acc/acc_common.h
index 06778bd6fc..bda2ad2f7a 100644
--- a/drivers/baseband/acc/acc_common.h
+++ b/drivers/baseband/acc/acc_common.h
@@ -18,6 +18,7 @@
 #define ACC_DMA_BLKID_OUT_HARQ  3
 #define ACC_DMA_BLKID_IN_HARQ   3
 #define ACC_DMA_BLKID_IN_MLD_R  3
+#define ACC_DMA_BLKID_DEWIN_IN  3
 
 /* Values used in filling in decode FCWs */
 #define ACC_FCW_TD_VER  1
@@ -103,6 +104,9 @@
 #define ACC_MAX_NUM_QGRPS  32
 #define ACC_RING_SIZE_GRANULARITY  64
 #define ACC_MAX_FCW_SIZE  128
+#define ACC_IQ_SIZE4
+
+#define ACC_FCW_FFT_BLEN_3 28
 
 /* Constants from K0 computation from 3GPP 38.212 Table 5.4.2.1-2 */
 #define ACC_N_ZC_1 66 /* N = 66 Zc for BG 1 */
@@ -132,6 +136,17 @@
 #define ACC_LIM_21 14 /* 0.21 */
 #define ACC_LIM_31 20 /* 0.31 */
 #define ACC_MAX_E (128 * 1024 - 2)
+#define ACC_MAX_CS 12
+
+#define ACC100_VARIANT  0
+#define VRB1_VARIANT   2
+#define VRB2_VARIANT   3
+
+/* Queue Index Hierarchy */
+#define VRB1_GRP_ID_SHIFT10
+#define VRB1_VF_ID_SHIFT 4
+#define VRB2_GRP_ID_SHIFT12
+#define VRB2_VF_ID_SHIFT 6
 
 #define ACC_MAX_FFT_WIN  16
 
@@ -334,6 +349,37 @@ struct __rte_packed acc_fcw_fft {
res:19;
 };
 
+/* FFT Frame Control Word. */
+struct __rte_packed acc_fcw_fft_3 {
+   uint32_t in_frame_size:16,
+   leading_pad_size:16;
+   uint32_t out_frame_size:16,
+   leading_depad_size:16;
+   uint32_t cs_window_sel;
+   uint32_t cs_window_sel2:16,
+   cs_enable_bmap:16;
+   uint32_t num_antennas:8,
+   idft_size:8,
+   dft_size:8,
+   cs_offset:8;
+   uint32_t idft_shift:8,
+   dft_shift:8,
+   cs_multiplier:16;
+   uint32_t bypass:2,
+   fp16_in:1,
+   fp16_out:1,
+   exp_adj:4,
+   power_shift:4,
+   power_en:1,
+   enable_dewin:1,
+   freq_resample_mode:2,
+   depad_output_size:16;
+   uint16_t cs_theta_0[ACC_MAX_CS];
+   uint32_t cs_theta_d[ACC_MAX_CS];
+   int8_t cs_time_offset[ACC_MAX_CS];
+};
+
+
 /* MLD-TS Frame Control Word */
 struct __rte_packed acc_fcw_mldts {
uint32_t fcw_version:4,
@@ -475,14 +521,14 @@ union acc_info_ring_data {
uint16_t valid: 1;
};
struct {
-   uint32_t aq_id_3: 6;
-   uint32_t qg_id_3: 5;
-   uint32_t vf_id_3: 6;
-   uint32_t int_nb_3: 6;
-   uint32_t msi_0_3: 1;
-   uint32_t vf2pf_3: 6;
-   uint32_t loop_3: 1;
-   uint32_t valid_3: 1;
+   uint32_t aq_id_vrb2: 6;
+   uint32_t qg_id_vrb2: 5;
+   uint32_t vf_id_vrb2: 6;
+   uint32_t int_nb_vrb2: 6;
+   uint32_t msi_0_vrb2: 1;
+   uint32_t vf2pf_vrb2: 6;
+   uint32_t loop_vrb2: 1;
+   uint32_t valid_vrb2: 1;
};
 } __rte_packed;
 
@@ -763,22 +809,114 @@ alloc_sw_rings_min_mem(struct rte_bbdev *dev, struct 
acc_device *d,
free_base_addresses(base_addrs, i);
 }
 
+/* Wrapper to provide VF index from ring data. */
+static inline uint16_t
+vf_from_ring(const union acc_info_ring_data ring_data, uint16_t device_variant)
+{
+   if (device_variant == VRB2_VARIANT)
+   return ring_data.vf_id_vrb2;
+   else
+   return ring_data.vf_id;
+}
+
+/* Wrapper to provide QG index from ring data. */
+static inline uint16_t
+qg_from_ring(const union acc_info_ring_data ring_data, uint16_t device_variant)
+{
+   if (device_variant == VRB2_VARIANT)
+   return ring_data.qg_id_vrb2;
+   else
+   return ring_data.qg_id;
+}
+
+/* Wrapper to provide AQ index from ring data. */
+static inline uint16_t
+aq_from_ring(const union acc_info_ring_data ring_data, uint16_t device_variant)
+{
+   if (device_variant == VRB2_VARIANT)
+   return ring_data.aq_id_vrb2;
+   else
+   return ring_data.aq_id;
+}
+
+/* Wrapper to provide int index from ring data. */
+static inline uint16_t
+int_from_ring(const union acc_info_ring_data ring_data, uint16_t 
device_variant)
+{
+   if (device_variant == VRB2_VARIANT)
+   return ring_data.int_nb_vrb2;
+   else
+   return ring_data.int_nb;
+}
+
+/* Wrapper to provide queue index from group and aq index. */
+static inline int
+queue_index(uint16_t group_idx, uint16_t aq_idx, uint16_t device_variant)

[PATCH v6 07/12] baseband/acc: adding VRB2 device variant

[Nicolas Chautru]

No functionality exposed only device enumeration and
configuration.

Signed-off-by: Nicolas Chautru 
Reviewed-by: Maxime Coquelin 
---
 doc/guides/bbdevs/features/vrb2.ini|  14 ++
 doc/guides/bbdevs/index.rst|   1 +
 doc/guides/bbdevs/vrb2.rst | 206 +
 doc/guides/rel_notes/release_23_11.rst |   3 +
 drivers/baseband/acc/rte_vrb_pmd.c | 156 +++
 drivers/baseband/acc/vrb2_pf_enum.h| 124 +++
 drivers/baseband/acc/vrb2_vf_enum.h| 121 +++
 drivers/baseband/acc/vrb_pmd.h | 161 ++-
 8 files changed, 751 insertions(+), 35 deletions(-)
 create mode 100644 doc/guides/bbdevs/features/vrb2.ini
 create mode 100644 doc/guides/bbdevs/vrb2.rst
 create mode 100644 drivers/baseband/acc/vrb2_pf_enum.h
 create mode 100644 drivers/baseband/acc/vrb2_vf_enum.h

diff --git a/doc/guides/bbdevs/features/vrb2.ini 
b/doc/guides/bbdevs/features/vrb2.ini
new file mode 100644
index 00..23ca6990b7
--- /dev/null
+++ b/doc/guides/bbdevs/features/vrb2.ini
@@ -0,0 +1,14 @@
+;
+; Supported features of the 'Intel vRAN Boost v2' baseband driver.
+;
+; Refer to default.ini for the full list of available PMD features.
+;
+[Features]
+Turbo Decoder (4G) = Y
+Turbo Encoder (4G) = Y
+LDPC Decoder (5G)  = Y
+LDPC Encoder (5G)  = Y
+LLR/HARQ Compression   = Y
+FFT/SRS= Y
+External DDR Access= N
+HW Accelerated = Y
diff --git a/doc/guides/bbdevs/index.rst b/doc/guides/bbdevs/index.rst
index 77d4c54664..269157d77f 100644
--- a/doc/guides/bbdevs/index.rst
+++ b/doc/guides/bbdevs/index.rst
@@ -15,4 +15,5 @@ Baseband Device Drivers
 fpga_5gnr_fec
 acc100
 vrb1
+vrb2
 la12xx
diff --git a/doc/guides/bbdevs/vrb2.rst b/doc/guides/bbdevs/vrb2.rst
new file mode 100644
index 00..2a30002e05
--- /dev/null
+++ b/doc/guides/bbdevs/vrb2.rst
@@ -0,0 +1,206 @@
+..  SPDX-License-Identifier: BSD-3-Clause
+Copyright(c) 2023 Intel Corporation
+
+.. include:: 
+
+Intel\ |reg| vRAN Boost v2 Poll Mode Driver (PMD)
+=
+
+The Intel\ |reg| vRAN Boost integrated accelerator enables
+cost-effective 4G and 5G next-generation virtualized Radio Access Network 
(vRAN)
+solutions.
+The Intel vRAN Boost v2.0 (VRB2 in the code) is specifically integrated on the
+Intel\ |reg| Xeon\ |reg| Granite Rapids-D Process (GNR-D).
+
+Features
+
+
+Intel vRAN Boost v2.0 includes a 5G Low Density Parity Check (LDPC) 
encoder/decoder,
+rate match/dematch, Hybrid Automatic Repeat Request (HARQ) with access to DDR
+memory for buffer management, a 4G Turbo encoder/decoder,
+a Fast Fourier Transform (FFT) block providing DFT/iDFT processing offload
+for the 5G Sounding Reference Signal (SRS), a MLD-TS accelerator, a Queue 
Manager (QMGR),
+and a DMA subsystem.
+There is no dedicated on-card memory for HARQ, the coherent memory on the CPU 
side is being used.
+
+These hardware blocks provide the following features exposed by the PMD:
+
+- LDPC Encode in the Downlink (5GNR)
+- LDPC Decode in the Uplink (5GNR)
+- Turbo Encode in the Downlink (4G)
+- Turbo Decode in the Uplink (4G)
+- FFT processing
+- MLD-TS processing
+- Single Root I/O Virtualization (SR-IOV) with 16 Virtual Functions (VFs) per 
Physical Function (PF)
+- Maximum of 2048 queues per VF
+- Message Signaled Interrupts (MSIs)
+
+The Intel vRAN Boost v2.0 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.
+   - ``RTE_BBDEV_LDPC_ENC_SCATTER_GATHER``: supports scatter-gather for 
input/output data.
+   - ``RTE_BBDEV_LDPC_ENC_CONCATENATION``: concatenate code blocks with bit 
granularity.
+
+* For the LDPC decode operation:
+   - ``RTE_BBDEV_LDPC_CRC_TYPE_24B_CHECK``: check CRC24B from CB(s).
+   - ``RTE_BBDEV_LDPC_CRC_TYPE_24B_DROP``: drops CRC24B bits appended while 
decoding.
+   - ``RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK``: check CRC24A from CB(s).
+   - ``RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK``: check CRC16 from CB(s).
+   - ``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_ITERATION_STOP_ENABLE``: disable early termination.
+   - ``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.
+   - ``RTE_BBDEV_LDPC_HARQ_4BIT_COMPRESSION``: supports compression of the 
HARQ input/output.
+   - ``RTE_BBDEV_LDPC_SOFT_OUT_ENABLE``: set the APP LLR soft output.
+   - ``RTE_BBDEV_LDPC_SOFT_OUT_RM_BYPASS``: set the A

[PATCH v6 08/12] baseband/acc: add FEC capabilities for the VRB2 variant

[Nicolas Chautru]

New implementation for some of the FEC features
specific to the VRB2 variant.

Signed-off-by: Nicolas Chautru 
Reviewed-by: Maxime Coquelin 
---
 drivers/baseband/acc/rte_vrb_pmd.c | 370 +
 1 file changed, 328 insertions(+), 42 deletions(-)

diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index b36dd6ccd8..dab61fd5df 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -1235,6 +1235,94 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)
};
 
static const struct rte_bbdev_op_cap vrb2_bbdev_capabilities[] = {
+   {
+   .type = RTE_BBDEV_OP_TURBO_DEC,
+   .cap.turbo_dec = {
+   .capability_flags =
+   RTE_BBDEV_TURBO_SUBBLOCK_DEINTERLEAVE |
+   RTE_BBDEV_TURBO_CRC_TYPE_24B |
+   RTE_BBDEV_TURBO_DEC_CRC_24B_DROP |
+   RTE_BBDEV_TURBO_EQUALIZER |
+   RTE_BBDEV_TURBO_SOFT_OUT_SATURATE |
+   RTE_BBDEV_TURBO_HALF_ITERATION_EVEN |
+   RTE_BBDEV_TURBO_CONTINUE_CRC_MATCH |
+   RTE_BBDEV_TURBO_SOFT_OUTPUT |
+   RTE_BBDEV_TURBO_EARLY_TERMINATION |
+   RTE_BBDEV_TURBO_DEC_INTERRUPTS |
+   RTE_BBDEV_TURBO_NEG_LLR_1_BIT_IN |
+   RTE_BBDEV_TURBO_NEG_LLR_1_BIT_SOFT_OUT |
+   RTE_BBDEV_TURBO_MAP_DEC |
+   RTE_BBDEV_TURBO_DEC_TB_CRC_24B_KEEP |
+   RTE_BBDEV_TURBO_DEC_SCATTER_GATHER,
+   .max_llr_modulus = INT8_MAX,
+   .num_buffers_src =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   .num_buffers_hard_out =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   .num_buffers_soft_out =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   }
+   },
+   {
+   .type = RTE_BBDEV_OP_TURBO_ENC,
+   .cap.turbo_enc = {
+   .capability_flags =
+   RTE_BBDEV_TURBO_CRC_24B_ATTACH |
+   RTE_BBDEV_TURBO_RV_INDEX_BYPASS |
+   RTE_BBDEV_TURBO_RATE_MATCH |
+   RTE_BBDEV_TURBO_ENC_INTERRUPTS |
+   RTE_BBDEV_TURBO_ENC_SCATTER_GATHER,
+   .num_buffers_src =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   .num_buffers_dst =
+   RTE_BBDEV_TURBO_MAX_CODE_BLOCKS,
+   }
+   },
+   {
+   .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 |
+   RTE_BBDEV_LDPC_ENC_INTERRUPTS |
+   RTE_BBDEV_LDPC_ENC_SCATTER_GATHER |
+   RTE_BBDEV_LDPC_ENC_CONCATENATION,
+   .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_CRC_TYPE_24A_CHECK |
+   RTE_BBDEV_LDPC_CRC_TYPE_16_CHECK |
+   RTE_BBDEV_LDPC_HQ_COMBINE_IN_ENABLE |
+   RTE_BBDEV_LDPC_HQ_COMBINE_OUT_ENABLE |
+   RTE_BBDEV_LDPC_ITERATION_STOP_ENABLE |
+   RTE_BBDEV_LDPC_DEINTERLEAVER_BYPASS |
+   RTE_BBDEV_LDPC_DEC_SCATTER_GAT

[PATCH v6 09/12] baseband/acc: add FFT support to VRB2 variant

[Nicolas Chautru]

Support for the FFT the processing specific to the
VRB2 variant.

Signed-off-by: Nicolas Chautru 
Reviewed-by: Maxime Coquelin 
---
 drivers/baseband/acc/rte_vrb_pmd.c | 146 +++--
 1 file changed, 119 insertions(+), 27 deletions(-)

diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index dab61fd5df..26bb06a6f9 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -902,6 +902,9 @@ vrb_queue_setup(struct rte_bbdev *dev, uint16_t queue_id,
ACC_FCW_LD_BLEN : (conf->op_type == RTE_BBDEV_OP_FFT ?
ACC_FCW_FFT_BLEN : ACC_FCW_MLDTS_BLEN;
 
+   if ((q->d->device_variant == VRB2_VARIANT) && (conf->op_type == 
RTE_BBDEV_OP_FFT))
+   fcw_len = ACC_FCW_FFT_BLEN_3;
+
for (desc_idx = 0; desc_idx < d->sw_ring_max_depth; desc_idx++) {
desc = q->ring_addr + desc_idx;
desc->req.word0 = ACC_DMA_DESC_TYPE;
@@ -1224,10 +1227,8 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)
RTE_BBDEV_FFT_DFT_BYPASS |
RTE_BBDEV_FFT_IDFT_BYPASS |
RTE_BBDEV_FFT_WINDOWING_BYPASS,
-   .num_buffers_src =
-   RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
-   .num_buffers_dst =
-   RTE_BBDEV_LDPC_MAX_CODE_BLOCKS,
+   .num_buffers_src = 1,
+   .num_buffers_dst = 1,
.fft_windows_num = ACC_MAX_FFT_WIN,
}
},
@@ -1323,6 +1324,23 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)
.num_buffers_soft_out = 0,
}
},
+   {
+   .type   = RTE_BBDEV_OP_FFT,
+   .cap.fft = {
+   .capability_flags =
+   RTE_BBDEV_FFT_WINDOWING |
+   RTE_BBDEV_FFT_CS_ADJUSTMENT |
+   RTE_BBDEV_FFT_DFT_BYPASS |
+   RTE_BBDEV_FFT_IDFT_BYPASS |
+   RTE_BBDEV_FFT_FP16_INPUT |
+   RTE_BBDEV_FFT_FP16_OUTPUT |
+   RTE_BBDEV_FFT_POWER_MEAS |
+   RTE_BBDEV_FFT_WINDOWING_BYPASS,
+   .num_buffers_src = 1,
+   .num_buffers_dst = 1,
+   .fft_windows_num = ACC_MAX_FFT_WIN,
+   }
+   },
RTE_BBDEV_END_OF_CAPABILITIES_LIST()
};
 
@@ -3608,62 +3626,136 @@ vrb1_fcw_fft_fill(struct rte_bbdev_fft_op *op, struct 
acc_fcw_fft *fcw)
fcw->bypass = 0;
 }
 
+/* Fill in a frame control word for FFT processing. */
+static inline void
+vrb2_fcw_fft_fill(struct rte_bbdev_fft_op *op, struct acc_fcw_fft_3 *fcw)
+{
+   fcw->in_frame_size = op->fft.input_sequence_size;
+   fcw->leading_pad_size = op->fft.input_leading_padding;
+   fcw->out_frame_size = op->fft.output_sequence_size;
+   fcw->leading_depad_size = op->fft.output_leading_depadding;
+   fcw->cs_window_sel = op->fft.window_index[0] +
+   (op->fft.window_index[1] << 8) +
+   (op->fft.window_index[2] << 16) +
+   (op->fft.window_index[3] << 24);
+   fcw->cs_window_sel2 = op->fft.window_index[4] +
+   (op->fft.window_index[5] << 8);
+   fcw->cs_enable_bmap = op->fft.cs_bitmap;
+   fcw->num_antennas = op->fft.num_antennas_log2;
+   fcw->idft_size = op->fft.idft_log2;
+   fcw->dft_size = op->fft.dft_log2;
+   fcw->cs_offset = op->fft.cs_time_adjustment;
+   fcw->idft_shift = op->fft.idft_shift;
+   fcw->dft_shift = op->fft.dft_shift;
+   fcw->cs_multiplier = op->fft.ncs_reciprocal;
+   fcw->power_shift = op->fft.power_shift;
+   fcw->exp_adj = op->fft.fp16_exp_adjust;
+   fcw->fp16_in = check_bit(op->fft.op_flags, RTE_BBDEV_FFT_FP16_INPUT);
+   fcw->fp16_out = check_bit(op->fft.op_flags, RTE_BBDEV_FFT_FP16_OUTPUT);
+   fcw->power_en = check_bit(op->fft.op_flags, RTE_BBDEV_FFT_POWER_MEAS);
+   if (check_bit(op->fft.op_flags,
+   RTE_BBDEV_FFT_IDFT_BYPASS)) {
+   if (check_bit(op->fft.op_flags,
+   RTE_BBDEV_FFT_WINDOWING_BYPASS))
+   fcw->bypass = 2;
+   else
+   fcw->bypass = 1;
+   } else if

[PATCH v6 10/12] baseband/acc: add MLD support in VRB2 variant

[Nicolas Chautru]

Adding the capability for the MLD-TS processing specific to
the VRB2 variant.

Signed-off-by: Nicolas Chautru 
Reviewed-by: Maxime Coquelin 
---
 drivers/baseband/acc/rte_vrb_pmd.c | 374 +
 1 file changed, 374 insertions(+)

diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index 26bb06a6f9..4c7a92833b 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -1341,6 +1341,17 @@ vrb_dev_info_get(struct rte_bbdev *dev, struct 
rte_bbdev_driver_info *dev_info)
.fft_windows_num = ACC_MAX_FFT_WIN,
}
},
+   {
+   .type   = RTE_BBDEV_OP_MLDTS,
+   .cap.mld = {
+   .capability_flags =
+   RTE_BBDEV_MLDTS_REP,
+   .num_buffers_src =
+   1,
+   .num_buffers_dst =
+   1,
+   }
+   },
RTE_BBDEV_END_OF_CAPABILITIES_LIST()
};
 
@@ -3878,6 +3889,367 @@ vrb_dequeue_fft(struct rte_bbdev_queue_data *q_data,
return i;
 }
 
+/* Fill in a frame control word for MLD-TS processing. */
+static inline void
+vrb2_fcw_mldts_fill(struct rte_bbdev_mldts_op *op, struct acc_fcw_mldts *fcw)
+{
+   fcw->nrb = op->mldts.num_rbs;
+   fcw->NLayers = op->mldts.num_layers - 1;
+   fcw->Qmod0 = (op->mldts.q_m[0] >> 1) - 1;
+   fcw->Qmod1 = (op->mldts.q_m[1] >> 1) - 1;
+   fcw->Qmod2 = (op->mldts.q_m[2] >> 1) - 1;
+   fcw->Qmod3 = (op->mldts.q_m[3] >> 1) - 1;
+   /* Mark some layers as disabled */
+   if (op->mldts.num_layers == 2) {
+   fcw->Qmod2 = 3;
+   fcw->Qmod3 = 3;
+   }
+   if (op->mldts.num_layers == 3)
+   fcw->Qmod3 = 3;
+   fcw->Rrep = op->mldts.r_rep;
+   fcw->Crep = op->mldts.c_rep;
+}
+
+/* Fill in descriptor for one MLD-TS processing operation. */
+static inline int
+vrb2_dma_desc_mldts_fill(struct rte_bbdev_mldts_op *op,
+   struct acc_dma_req_desc *desc,
+   struct rte_mbuf *input_q, struct rte_mbuf *input_r,
+   struct rte_mbuf *output,
+   uint32_t *in_offset, uint32_t *out_offset)
+{
+   uint16_t qsize_per_re[VRB2_MLD_LAY_SIZE] = {8, 12, 16}; /* Layer 2 to 
4. */
+   uint16_t rsize_per_re[VRB2_MLD_LAY_SIZE] = {14, 26, 42};
+   uint16_t sc_factor_per_rrep[VRB2_MLD_RREP_SIZE] = {12, 6, 4, 3, 0, 2};
+   uint16_t i, outsize_per_re = 0;
+   uint32_t sc_num, r_num, q_size, r_size, out_size;
+
+   /* Prevent out of range access. */
+   if (op->mldts.r_rep > 5)
+   op->mldts.r_rep = 5;
+   if (op->mldts.num_layers < 2)
+   op->mldts.num_layers = 2;
+   if (op->mldts.num_layers > 4)
+   op->mldts.num_layers = 4;
+   for (i = 0; i < op->mldts.num_layers; i++)
+   outsize_per_re += op->mldts.q_m[i];
+   sc_num = op->mldts.num_rbs * RTE_BBDEV_SCPERRB * (op->mldts.c_rep + 1);
+   r_num = op->mldts.num_rbs * sc_factor_per_rrep[op->mldts.r_rep];
+   q_size = qsize_per_re[op->mldts.num_layers - 2] * sc_num;
+   r_size = rsize_per_re[op->mldts.num_layers - 2] * r_num;
+   out_size =  sc_num * outsize_per_re;
+
+   /* FCW already done. */
+   acc_header_init(desc);
+   desc->data_ptrs[1].address = rte_pktmbuf_iova_offset(input_q, 
*in_offset);
+   desc->data_ptrs[1].blen = q_size;
+   desc->data_ptrs[1].blkid = ACC_DMA_BLKID_IN;
+   desc->data_ptrs[1].last = 0;
+   desc->data_ptrs[1].dma_ext = 0;
+   desc->data_ptrs[2].address = rte_pktmbuf_iova_offset(input_r, 
*in_offset);
+   desc->data_ptrs[2].blen = r_size;
+   desc->data_ptrs[2].blkid = ACC_DMA_BLKID_IN_MLD_R;
+   desc->data_ptrs[2].last = 1;
+   desc->data_ptrs[2].dma_ext = 0;
+   desc->data_ptrs[3].address = rte_pktmbuf_iova_offset(output, 
*out_offset);
+   desc->data_ptrs[3].blen = out_size;
+   desc->data_ptrs[3].blkid = ACC_DMA_BLKID_OUT_HARD;
+   desc->data_ptrs[3].last = 1;
+   desc->data_ptrs[3].dma_ext = 0;
+   desc->m2dlen = 3;
+   desc->d2mlen = 1;
+   desc->op_addr = op;
+   desc->cbs_in_tb = 1;
+
+   return 0;
+}
+
+/* Check whether the MLD operation can be processed as a single operation. */
+static inline bool
+vrb2_check_mld_r_constraint(struct rte_bbdev_mldts_op *op) {
+   uint8_t layer_idx, rrep_idx;
+   uint16_t max_rb[VRB2_MLD_LAY_SIZE][VRB2_MLD_RREP_SIZE] = {
+   {188, 275, 275, 275, 0, 275},
+   {101, 202, 275, 275, 0, 275},
+   {62, 124, 186, 248, 0, 275} };
+
+   if (op->mldts.c_rep == 0)
+   return true;
+
+   layer_idx = RTE_MIN(op->mldts.num_layers - VRB2_M

[PATCH v6 11/12] baseband/acc: add support for VRB2 engine error detection

[Nicolas Chautru]

Adding missing incremental functionality for the VRB2
variant. Notably detection of engine error during the
dequeue. Minor cosmetic edits.

Signed-off-by: Nicolas Chautru 
Reviewed-by: Maxime Coquelin 
---
 drivers/baseband/acc/rte_vrb_pmd.c  | 19 ---
 drivers/baseband/acc/vrb1_pf_enum.h | 17 -
 2 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index 4c7a92833b..76baf1bbc3 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -1501,6 +1501,7 @@ vrb_fcw_td_fill(const struct rte_bbdev_dec_op *op, struct 
acc_fcw_td *fcw)
fcw->ea = op->turbo_dec.cb_params.e;
fcw->eb = op->turbo_dec.cb_params.e;
}
+
if (op->turbo_dec.rv_index == 0)
fcw->k0_start_col = ACC_FCW_TD_RVIDX_0;
else if (op->turbo_dec.rv_index == 1)
@@ -2075,7 +2076,7 @@ enqueue_ldpc_enc_n_op_cb(struct acc_queue *q, struct 
rte_bbdev_enc_op **ops,
return num;
 }
 
-/* Enqueue one encode operations for device for a partial TB
+/* Enqueue one encode operations for VRB1 device for a partial TB
  * all codes blocks have same configuration multiplexed on the same descriptor.
  */
 static inline void
@@ -2419,7 +2420,7 @@ enqueue_dec_one_op_cb(struct acc_queue *q, struct 
rte_bbdev_dec_op *op,
return 1;
 }
 
-/** Enqueue one decode operations for device in CB mode */
+/** Enqueue one decode operations for device in CB mode. */
 static inline int
 vrb_enqueue_ldpc_dec_one_op_cb(struct acc_queue *q, struct rte_bbdev_dec_op 
*op,
uint16_t total_enqueued_cbs, bool same_op)
@@ -2983,7 +2984,6 @@ vrb_enqueue_ldpc_dec_cb(struct rte_bbdev_queue_data 
*q_data,
break;
}
avail -= 1;
-
rte_bbdev_log(INFO, "Op %d %d %d %d %d %d %d %d %d %d %d %d\n",
i, ops[i]->ldpc_dec.op_flags, ops[i]->ldpc_dec.rv_index,
ops[i]->ldpc_dec.iter_max, ops[i]->ldpc_dec.iter_count,
@@ -3111,6 +3111,7 @@ vrb_dequeue_enc_one_op_cb(struct acc_queue *q, struct 
rte_bbdev_enc_op **ref_op,
op->status |= ((rsp.input_err) ? (1 << RTE_BBDEV_DATA_ERROR) : 0);
op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
+   op->status |= ((rsp.engine_hung) ? (1 << RTE_BBDEV_ENGINE_ERROR) : 0);
 
if (desc->req.last_desc_in_batch) {
(*aq_dequeued)++;
@@ -3226,6 +3227,7 @@ vrb_dequeue_enc_one_op_tb(struct acc_queue *q, struct 
rte_bbdev_enc_op **ref_op,
op->status |= ((rsp.input_err) ? (1 << RTE_BBDEV_DATA_ERROR) : 
0);
op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
+   op->status |= ((rsp.engine_hung) ? (1 << 
RTE_BBDEV_ENGINE_ERROR) : 0);
 
if (desc->req.last_desc_in_batch) {
(*aq_dequeued)++;
@@ -3272,6 +3274,8 @@ vrb_dequeue_dec_one_op_cb(struct rte_bbdev_queue_data 
*q_data,
op->status |= ((rsp.input_err) ? (1 << RTE_BBDEV_DATA_ERROR) : 0);
op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
+   op->status |= rsp.engine_hung << RTE_BBDEV_ENGINE_ERROR;
+
if (op->status != 0) {
/* These errors are not expected. */
q_data->queue_stats.dequeue_err_count++;
@@ -3325,6 +3329,7 @@ vrb_dequeue_ldpc_dec_one_op_cb(struct 
rte_bbdev_queue_data *q_data,
op->status |= rsp.input_err << RTE_BBDEV_DATA_ERROR;
op->status |= rsp.dma_err << RTE_BBDEV_DRV_ERROR;
op->status |= rsp.fcw_err << RTE_BBDEV_DRV_ERROR;
+   op->status |= rsp.engine_hung << RTE_BBDEV_ENGINE_ERROR;
if (op->status != 0)
q_data->queue_stats.dequeue_err_count++;
 
@@ -3406,6 +3411,7 @@ vrb_dequeue_dec_one_op_tb(struct acc_queue *q, struct 
rte_bbdev_dec_op **ref_op,
op->status |= ((rsp.input_err) ? (1 << RTE_BBDEV_DATA_ERROR) : 
0);
op->status |= ((rsp.dma_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
op->status |= ((rsp.fcw_err) ? (1 << RTE_BBDEV_DRV_ERROR) : 0);
+   op->status |= ((rsp.engine_hung) ? (1 << 
RTE_BBDEV_ENGINE_ERROR) : 0);
 
if (check_bit(op->ldpc_dec.op_flags, 
RTE_BBDEV_LDPC_CRC_TYPE_24A_CHECK))
tb_crc_check ^= desc->rsp.add_info_1;
@@ -3457,7 +3463,6 @@ vrb_dequeue_enc(struct rte_bbdev_queue_data *q_data,
if (avail == 0)
return 0;
op = acc_op_tail(q, 0);
-
cbm = op->turbo_enc.code_block_mode;
 
for (i = 0; i < avail; i++) {
@@ -3768,9 +3

[PATCH v6 12/12] baseband/acc: add configure helper for VRB2

[Nicolas Chautru]

This allows to configure the VRB2 device using a
companion configuration function within the DPDK
bbdev-test environment.

Signed-off-by: Nicolas Chautru 
Reviewed-by: Maxime Coquelin 
---
 drivers/baseband/acc/acc100_pmd.h |   2 +
 drivers/baseband/acc/rte_acc100_pmd.c |   6 +-
 drivers/baseband/acc/rte_vrb_pmd.c| 321 ++
 drivers/baseband/acc/vrb_cfg.h|  16 ++
 4 files changed, 344 insertions(+), 1 deletion(-)

diff --git a/drivers/baseband/acc/acc100_pmd.h 
b/drivers/baseband/acc/acc100_pmd.h
index a48298650c..5a8965fa53 100644
--- a/drivers/baseband/acc/acc100_pmd.h
+++ b/drivers/baseband/acc/acc100_pmd.h
@@ -34,6 +34,8 @@
 #define ACC100_VENDOR_ID   (0x8086)
 #define ACC100_PF_DEVICE_ID(0x0d5c)
 #define ACC100_VF_DEVICE_ID(0x0d5d)
+#define VRB1_PF_DEVICE_ID  (0x57C0)
+#define VRB2_PF_DEVICE_ID  (0x57C2)
 
 /* Values used in writing to the registers */
 #define ACC100_REG_IRQ_EN_ALL  0x1FF83FF  /* Enable all interrupts */
diff --git a/drivers/baseband/acc/rte_acc100_pmd.c 
b/drivers/baseband/acc/rte_acc100_pmd.c
index 5362d39c30..cfda1add86 100644
--- a/drivers/baseband/acc/rte_acc100_pmd.c
+++ b/drivers/baseband/acc/rte_acc100_pmd.c
@@ -5187,6 +5187,10 @@ rte_acc_configure(const char *dev_name, struct 
rte_acc_conf *conf)
return acc100_configure(dev_name, conf);
else if (pci_dev->id.device_id == ACC101_PF_DEVICE_ID)
return acc101_configure(dev_name, conf);
-   else
+   else if (pci_dev->id.device_id == VRB1_PF_DEVICE_ID)
return vrb1_configure(dev_name, conf);
+   else if (pci_dev->id.device_id == VRB2_PF_DEVICE_ID)
+   return vrb2_configure(dev_name, conf);
+
+   return -ENXIO;
 }
diff --git a/drivers/baseband/acc/rte_vrb_pmd.c 
b/drivers/baseband/acc/rte_vrb_pmd.c
index 76baf1bbc3..ae230b828a 100644
--- a/drivers/baseband/acc/rte_vrb_pmd.c
+++ b/drivers/baseband/acc/rte_vrb_pmd.c
@@ -4774,3 +4774,324 @@ vrb1_configure(const char *dev_name, struct 
rte_acc_conf *conf)
rte_bbdev_log_debug("PF Tip configuration complete for %s", dev_name);
return 0;
 }
+
+/* Initial configuration of a VRB2 device prior to running configure(). */
+int
+vrb2_configure(const char *dev_name, struct rte_acc_conf *conf)
+{
+   rte_bbdev_log(INFO, "vrb2_configure");
+   uint32_t value, address, status;
+   int qg_idx, template_idx, vf_idx, acc, i, aq_reg, static_allocation, 
numEngines;
+   int numQgs, numQqsAcc, totalQgs;
+   int qman_func_id[8] = {0, 2, 1, 3, 4, 5, 0, 0};
+   struct rte_bbdev *bbdev = rte_bbdev_get_named_dev(dev_name);
+   int rlim, alen, timestamp;
+
+   /* Compile time checks. */
+   RTE_BUILD_BUG_ON(sizeof(struct acc_dma_req_desc) != 256);
+   RTE_BUILD_BUG_ON(sizeof(union acc_dma_desc) != 256);
+   RTE_BUILD_BUG_ON(sizeof(struct acc_fcw_td) != 24);
+   RTE_BUILD_BUG_ON(sizeof(struct acc_fcw_te) != 32);
+
+   if (bbdev == NULL) {
+   rte_bbdev_log(ERR,
+   "Invalid dev_name (%s), or device is not yet initialised",
+   dev_name);
+   return -ENODEV;
+   }
+   struct acc_device *d = bbdev->data->dev_private;
+
+   /* Store configuration. */
+   rte_memcpy(&d->acc_conf, conf, sizeof(d->acc_conf));
+
+   /* Explicitly releasing AXI as this may be stopped after PF FLR/BME. */
+   address = VRB2_PfDmaAxiControl;
+   value = 1;
+   acc_reg_write(d, address, value);
+
+   /* Set the fabric mode. */
+   address = VRB2_PfFabricM2iBufferReg;
+   value = VRB2_FABRIC_MODE;
+   acc_reg_write(d, address, value);
+
+   /* Set default descriptor signature. */
+   address = VRB2_PfDmaDescriptorSignature;
+   value = 0;
+   acc_reg_write(d, address, value);
+
+   /* Enable the Error Detection in DMA. */
+   value = VRB2_CFG_DMA_ERROR;
+   address = VRB2_PfDmaErrorDetectionEn;
+   acc_reg_write(d, address, value);
+
+   /* AXI Cache configuration. */
+   value = VRB2_CFG_AXI_CACHE;
+   address = VRB2_PfDmaAxcacheReg;
+   acc_reg_write(d, address, value);
+
+   /* AXI Response configuration. */
+   acc_reg_write(d, VRB2_PfDmaCfgRrespBresp, 0x0);
+
+   /* Default DMA Configuration (Qmgr Enabled) */
+   acc_reg_write(d, VRB2_PfDmaConfig0Reg, 0);
+   acc_reg_write(d, VRB2_PfDmaQmanenSelect, 0x);
+   acc_reg_write(d, VRB2_PfDmaQmanen, 0);
+
+   /* Default RLIM/ALEN configuration. */
+   rlim = 0;
+   alen = 3;
+   timestamp = 0;
+   address = VRB2_PfDmaConfig1Reg;
+   value = (1 << 31) + (rlim << 8) + (timestamp << 6) + alen;
+   acc_reg_write(d, address, value);
+
+   /* Default FFT configuration. */
+   for (template_idx = 0; template_idx < VRB2_FFT_NUM; template_idx++) {
+   acc_reg_write(d, VRB2_PfFftConfig0 + template_idx * 0x1000, 
VRB2_FFT_CFG_0);
+   acc_r

[PATCH v1 0/1] doc: bbdev device discovery clarification

[Nicolas Chautru]

Adding more information in bbdev documentation related to the
bbdev device discovery from info_get which was not very verbose so far.
Notably for FEC and FFT operations which have extra parameters to
manage different implementation variants.

Also use code snippet to refer to info structure and keep the doc
in sync moving forward.

This is on top of this serie
https://patches.dpdk.org/project/dpdk/list/?series=29744

Nicolas Chautru (1):
  doc: bbdev device discovery clarification

 doc/guides/prog_guide/bbdev.rst | 60 -
 lib/bbdev/rte_bbdev.h   |  6 
 2 files changed, 57 insertions(+), 9 deletions(-)

-- 
2.34.1

[PATCH v1 1/1] doc: bbdev device discovery clarification

[Nicolas Chautru]

Adding more context and information related the data exposed
through device discovery notably for FEC and FFT operations.

Signed-off-by: Nicolas Chautru 
---
 doc/guides/prog_guide/bbdev.rst | 60 -
 lib/bbdev/rte_bbdev.h   |  6 
 2 files changed, 57 insertions(+), 9 deletions(-)

diff --git a/doc/guides/prog_guide/bbdev.rst b/doc/guides/prog_guide/bbdev.rst
index c43e478eda..01a8a6d79b 100644
--- a/doc/guides/prog_guide/bbdev.rst
+++ b/doc/guides/prog_guide/bbdev.rst
@@ -261,16 +261,58 @@ information:
   structure, this is where capabilities reside along with other specifics like:
   maximum queue sizes and priority level.
 
-.. code-block:: c
+.. literalinclude:: ../../../lib/bbdev/rte_bbdev.h
+   :language: c
+   :start-after: Structure rte_bbdev_driver_info 8<
+   :end-before: >8 End of structure rte_bbdev_driver_info.
 
-struct rte_bbdev_info {
-int socket_id;
-const char *dev_name;
-const struct rte_device *device;
-uint16_t num_queues;
-bool started;
-struct rte_bbdev_driver_info drv;
-};
+.. literalinclude:: ../../../lib/bbdev/rte_bbdev.h
+   :language: c
+   :start-after: Structure rte_bbdev_info 8<
+   :end-before: >8 End of structure rte_bbdev_info.
+
+Capabilities details for LDPC Decoder
+~
+
+On top of the ``RTE_BBDEV_LDPC_<*>`` capabilities the device also exposes the 
LLR numerical
+representation expected by the decoder as a fractional fixed-point 
representation.
+For instance, when the representation (``llr_size``, ``llr_decimals``) = (8, 
2) respectively,
+this means that each input LLR in the data provided by the application must be 
computed as 8 total
+bits (including sign bit) where 2 of these are fractions bits (also referred 
to as S8.2 format).
+It is up to the user application during LLR generation to scale the LLR 
according to this
+optimal numerical representation. Any mis-scaled LLR would cause wireless 
performance degradation.
+
+The ``harq_buffer_size`` exposes the amount of dedicated DDR made available 
for the device operation.
+This is specific for accelerator non-integrated on the CPU (separate PCIe 
device) which may
+include separate on-card memory.
+
+Capabilities details for FFT function
+~
+
+The total number of distinct time windows supported for the post-FFT 
point-wise multiplication is
+exposed as ``fft_windows_num``. The ``window_index`` provided for each cyclic 
shift in each
+``rte_bbdev_op_fft`` operation is expected to be limited to that size.
+
+The information related to the width of each of these pre-configured window is 
also exposed
+using the ``fft_window_width`` array. This provides the number of non-null 
samples used for each
+window index when scaling back the size to a reference of 1024 FFT. The actual 
shape size is
+effectively scaled up or down based on the dynamic size of the FFT operation 
being used.
+
+This allows to distinguish different version of the flexible pointwise 
windowing applied to the
+FFT and exposes this platform configuration to the application.
+
+Other optional capabilities exposed during device discovery
+~~~
+
+The device status can be used to expose additional information related to the 
state of the
+platform notably based on its configuration state or related to error 
management
+(correctable or non).
+
+The queue topology exposed to the device is provided on top of the 
capabilities. This provides
+the number of queues available for the exposed bbdev device (the physical 
device may have more)
+for each operation as well as the different level of priority available for 
arbitration.
+These are based on the arrays and parameters ``num_queues``, 
``queue_priority``,
+``max_num_queues``, ``queue_size_lim``.
 
 
 Operation Processing
diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h
index d12e2e7fbc..925c78cae1 100644
--- a/lib/bbdev/rte_bbdev.h
+++ b/lib/bbdev/rte_bbdev.h
@@ -313,6 +313,8 @@ int
 rte_bbdev_stats_reset(uint16_t dev_id);
 
 /** Device information supplied by the device's driver */
+
+/* Structure rte_bbdev_driver_info 8< */
 struct rte_bbdev_driver_info {
/** Driver name */
const char *driver_name;
@@ -352,6 +354,7 @@ struct rte_bbdev_driver_info {
/** FFT windowing width for 2048 FFT - size defined in capability. */
uint16_t *fft_window_width;
 };
+/* >8 End of structure rte_bbdev_driver_info. */
 
 /** Macro used at end of bbdev PMD list */
 #define RTE_BBDEV_END_OF_CAPABILITIES_LIST() \
@@ -361,6 +364,8 @@ struct rte_bbdev_driver_info {
  * Device information structure used by an application to discover a devices
  * capabilities and current configuration
  */
+
+/* Structure rte_bbdev_info 8< */
 struct rte_bbdev_info {
int socket_id;  /**< NUMA socket that device is on */
const char *dev_name;  /**< Unique device na

[PATCH v2 1/3] net/ark: support for single function with multiple port

[Ed Czeck]

Support the creation of multiple ports from one ark device via
the use of ark pmd extension.  I.e., one device with q queue can
seen a p ports each with q/p queues.

Add unique dev_private data for each port to manage queue assignment.

This patch repairs a latent issue uncovered during testing.
Fixes: 6799275eeea6 ("net/ark: support virtual functions")
Cc: sta...@dpdk.org
Backporting is not requested.

Signed-off-by: Ed Czeck 
---
 drivers/net/ark/ark_ethdev.c| 15 ++-
 drivers/net/ark/ark_ethdev_rx.c |  6 +++---
 drivers/net/ark/ark_ethdev_tx.c |  2 +-
 drivers/net/ark/ark_global.h|  3 +++
 4 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index 3ddcc9b461..90d3c8abe6 100644
--- a/drivers/net/ark/ark_ethdev.c
+++ b/drivers/net/ark/ark_ethdev.c
@@ -300,6 +300,7 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
int ret;
int port_count = 1;
int p;
+   uint16_t num_queues;
bool rqpacing = false;
 
ark->eth_dev = dev;
@@ -427,6 +428,7 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
ark->user_ext.dev_get_port_count(dev,
 ark->user_data[dev->data->port_id]);
ark->num_ports = port_count;
+   num_queues = ark_api_num_queues_per_port(ark->mpurx.v, port_count);
 
for (p = 0; p < port_count; p++) {
struct rte_eth_dev *eth_dev;
@@ -452,7 +454,18 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
}
 
eth_dev->device = &pci_dev->device;
-   eth_dev->data->dev_private = ark;
+   /* Device requires new dev_private data */
+   eth_dev->data->dev_private =
+   rte_zmalloc_socket(name,
+  sizeof(struct ark_adapter),
+  RTE_CACHE_LINE_SIZE,
+  rte_socket_id());
+
+   memcpy(eth_dev->data->dev_private, ark,
+  sizeof(struct ark_adapter));
+   ark = eth_dev->data->dev_private;
+   ark->qbase = p * num_queues;
+
eth_dev->dev_ops = ark->eth_dev->dev_ops;
eth_dev->tx_pkt_burst = ark->eth_dev->tx_pkt_burst;
eth_dev->rx_pkt_burst = ark->eth_dev->rx_pkt_burst;
diff --git a/drivers/net/ark/ark_ethdev_rx.c b/drivers/net/ark/ark_ethdev_rx.c
index cbc0416bc2..38bc69dff4 100644
--- a/drivers/net/ark/ark_ethdev_rx.c
+++ b/drivers/net/ark/ark_ethdev_rx.c
@@ -68,7 +68,7 @@ struct ark_rx_queue {
 static int
 eth_ark_rx_hw_setup(struct rte_eth_dev *dev,
struct ark_rx_queue *queue,
-   uint16_t rx_queue_id __rte_unused, uint16_t rx_queue_idx)
+   uint16_t rx_queue_idx)
 {
rte_iova_t queue_base;
rte_iova_t phys_addr_q_base;
@@ -124,7 +124,7 @@ eth_ark_dev_rx_queue_setup(struct rte_eth_dev *dev,
uint32_t i;
int status;
 
-   int qidx = queue_idx;
+   int qidx = ark->qbase + queue_idx;
 
/* We may already be setup, free memory prior to re-allocation */
if (dev->data->rx_queues[queue_idx] != NULL) {
@@ -215,7 +215,7 @@ eth_ark_dev_rx_queue_setup(struct rte_eth_dev *dev,
}
/* MPU Setup */
if (status == 0)
-   status = eth_ark_rx_hw_setup(dev, queue, qidx, queue_idx);
+   status = eth_ark_rx_hw_setup(dev, queue, queue_idx);
 
if (unlikely(status != 0)) {
struct rte_mbuf **mbuf;
diff --git a/drivers/net/ark/ark_ethdev_tx.c b/drivers/net/ark/ark_ethdev_tx.c
index 5940a592a2..4792754f19 100644
--- a/drivers/net/ark/ark_ethdev_tx.c
+++ b/drivers/net/ark/ark_ethdev_tx.c
@@ -229,7 +229,7 @@ eth_ark_tx_queue_setup(struct rte_eth_dev *dev,
struct ark_tx_queue *queue;
int status;
 
-   int qidx = queue_idx;
+   int qidx = ark->qbase + queue_idx;
 
if (!rte_is_power_of_2(nb_desc)) {
ARK_PMD_LOG(ERR,
diff --git a/drivers/net/ark/ark_global.h b/drivers/net/ark/ark_global.h
index 71d0b53e03..2f198edfe4 100644
--- a/drivers/net/ark/ark_global.h
+++ b/drivers/net/ark/ark_global.h
@@ -112,7 +112,10 @@ struct ark_adapter {
ark_pkt_chkr_t pc;
ark_pkt_dir_t pd;
 
+   /* For single function, multiple ports */
int num_ports;
+   uint16_t qbase;
+
bool isvf;
 
/* Packet generator/checker args */
-- 
2.34.1

[PATCH v2 2/3] net/ark: remove RQ pacing firmware from PMD

[Ed Czeck]

features and function have been removed from FPGA firmware

Signed-off-by: Ed Czeck 
---
v2:
* restore previously incorrectly deleted line
---
 drivers/net/ark/ark_ethdev.c | 60 ---
 drivers/net/ark/ark_global.h |  3 --
 drivers/net/ark/ark_rqp.c| 70 
 drivers/net/ark/ark_rqp.h| 58 --
 drivers/net/ark/meson.build  |  1 -
 5 files changed, 15 insertions(+), 177 deletions(-)
 delete mode 100644 drivers/net/ark/ark_rqp.c
 delete mode 100644 drivers/net/ark/ark_rqp.h

diff --git a/drivers/net/ark/ark_ethdev.c b/drivers/net/ark/ark_ethdev.c
index 90d3c8abe6..0ffd4b9e9e 100644
--- a/drivers/net/ark/ark_ethdev.c
+++ b/drivers/net/ark/ark_ethdev.c
@@ -17,7 +17,6 @@
 #include "ark_mpu.h"
 #include "ark_ddm.h"
 #include "ark_udm.h"
-#include "ark_rqp.h"
 #include "ark_pktdir.h"
 #include "ark_pktgen.h"
 #include "ark_pktchkr.h"
@@ -107,36 +106,32 @@ static const struct rte_pci_id pci_id_ark_map[] = {
  * This structure is used to statically define the capabilities
  * of supported devices.
  * Capabilities:
- *  rqpacing -
- * Some HW variants require that PCIe read-requests be correctly throttled.
- * This is called "rqpacing" and has to do with credit and flow control
- * on certain Arkville implementations.
+ *isvf -- defined for function id that are virtual
  */
 struct ark_caps {
-   bool rqpacing;
bool isvf;
 };
 struct ark_dev_caps {
uint32_t  device_id;
struct ark_caps  caps;
 };
-#define SET_DEV_CAPS(id, rqp, vf)  \
-   {id, {.rqpacing = rqp, .isvf = vf} }
+#define SET_DEV_CAPS(id, vf)   \
+   {id, {.isvf = vf} }
 
 static const struct ark_dev_caps
 ark_device_caps[] = {
-SET_DEV_CAPS(0x100d, true, false),
-SET_DEV_CAPS(0x100e, true, false),
-SET_DEV_CAPS(0x100f, true, false),
-SET_DEV_CAPS(0x1010, false, false),
-SET_DEV_CAPS(0x1017, true, false),
-SET_DEV_CAPS(0x1018, true, false),
-SET_DEV_CAPS(0x1019, true, false),
-SET_DEV_CAPS(0x101a, true, false),
-SET_DEV_CAPS(0x101b, true, false),
-SET_DEV_CAPS(0x101c, true, true),
-SET_DEV_CAPS(0x101e, false, false),
-SET_DEV_CAPS(0x101f, false, false),
+SET_DEV_CAPS(0x100d, false),
+SET_DEV_CAPS(0x100e, false),
+SET_DEV_CAPS(0x100f, false),
+SET_DEV_CAPS(0x1010, false),
+SET_DEV_CAPS(0x1017, false),
+SET_DEV_CAPS(0x1018, false),
+SET_DEV_CAPS(0x1019, false),
+SET_DEV_CAPS(0x101a, false),
+SET_DEV_CAPS(0x101b, false),
+SET_DEV_CAPS(0x101c, true),
+SET_DEV_CAPS(0x101e, false),
+SET_DEV_CAPS(0x101f, false),
 {.device_id = 0,}
 };
 
@@ -301,7 +296,6 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
int port_count = 1;
int p;
uint16_t num_queues;
-   bool rqpacing = false;
 
ark->eth_dev = dev;
 
@@ -319,7 +313,6 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
p = 0;
while (ark_device_caps[p].device_id != 0) {
if (pci_dev->id.device_id == ark_device_caps[p].device_id) {
-   rqpacing = ark_device_caps[p].caps.rqpacing;
ark->isvf = ark_device_caps[p].caps.isvf;
break;
}
@@ -344,12 +337,6 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
ark->pktgen.v  = (void *)&ark->bar0[ARK_PKTGEN_BASE];
ark->pktchkr.v  = (void *)&ark->bar0[ARK_PKTCHKR_BASE];
 
-   if (rqpacing) {
-   ark->rqpacing =
-   (struct ark_rqpace_t *)(ark->bar0 + ARK_RCPACING_BASE);
-   } else {
-   ark->rqpacing = NULL;
-   }
ark->started = 0;
ark->pkt_dir_v = ARK_PKT_DIR_INIT_VAL;
 
@@ -368,17 +355,6 @@ eth_ark_dev_init(struct rte_eth_dev *dev)
ark->sysctrl.t32[4], __func__);
return -1;
}
-   if (ark->sysctrl.t32[3] != 0) {
-   if (ark->rqpacing) {
-   if (ark_rqp_lasped(ark->rqpacing)) {
-   ARK_PMD_LOG(ERR, "Arkville Evaluation System - "
-   "Timer has Expired\n");
-   return -1;
-   }
-   ARK_PMD_LOG(WARNING, "Arkville Evaluation System - "
-   "Timer is Running\n");
-   }
-   }
 
ARK_PMD_LOG(DEBUG,
"HW Sanity test has PASSED, expected constant"
@@ -550,9 +526,6 @@ ark_config_device(struct rte_eth_dev *dev)
   

[PATCH v2 3/3] net/ark: support for large dataroom in FPGA

[Ed Czeck]

Allow for non-standard dataroom sizes for upstream data
motion when using a custom mbuf pool.

- New firmware version for UDM (Upstream Data Mover)
- New layout on ark_rx_meta data

Signed-off-by: Ed Czeck 
---
 doc/guides/nics/ark.rst | 1 +
 drivers/net/ark/ark_ethdev_rx.c | 8 
 drivers/net/ark/ark_ext.h   | 9 +
 drivers/net/ark/ark_udm.h   | 5 +++--
 4 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/doc/guides/nics/ark.rst b/doc/guides/nics/ark.rst
index e1683cf782..bcc9f505df 100644
--- a/doc/guides/nics/ark.rst
+++ b/doc/guides/nics/ark.rst
@@ -334,6 +334,7 @@ with Arkville releases 21.05, 21.08 and 21.11. LTS versions 
of DPDK remain
 compatible with the corresponding Arkville version.  If other combinations
 are required, please contact Atomic Rules support.
 
+* DPDK 23.11 requires Arkville 23.11.
 * DPDK 22.07 requires Arkville 22.07.
 * DPDK 22.03 requires Arkville 22.03.
 * DPDK 21.05 requires Arkville 21.05.
diff --git a/drivers/net/ark/ark_ethdev_rx.c b/drivers/net/ark/ark_ethdev_rx.c
index 38bc69dff4..24f1c65690 100644
--- a/drivers/net/ark/ark_ethdev_rx.c
+++ b/drivers/net/ark/ark_ethdev_rx.c
@@ -9,6 +9,7 @@
 #include "ark_logs.h"
 #include "ark_mpu.h"
 #include "ark_udm.h"
+#include "ark_ext.h"
 
 #define ARK_RX_META_SIZE 32
 #define ARK_RX_META_OFFSET (RTE_PKTMBUF_HEADROOM - ARK_RX_META_SIZE)
@@ -166,6 +167,13 @@ eth_ark_dev_rx_queue_setup(struct rte_eth_dev *dev,
queue->mb_pool = mb_pool;
queue->dataroom = rte_pktmbuf_data_room_size(mb_pool) -
RTE_PKTMBUF_HEADROOM;
+
+   /* Check pool's private data to confirm pool structure */
+   if (mb_pool->private_data_size != 0) {
+   struct rte_pmd_ark_lmbuf_mempool_priv *pool_priv = 
rte_mempool_get_priv(mb_pool);
+   if (strncmp(pool_priv->cookie, ARK_MEMPOOL_COOKIE, 
sizeof(pool_priv->cookie)) == 0)
+   queue->dataroom = pool_priv->dataroom;
+   }
queue->headroom = RTE_PKTMBUF_HEADROOM;
queue->phys_qid = qidx;
queue->queue_index = queue_idx;
diff --git a/drivers/net/ark/ark_ext.h b/drivers/net/ark/ark_ext.h
index d235d0ff85..6d37449195 100644
--- a/drivers/net/ark/ark_ext.h
+++ b/drivers/net/ark/ark_ext.h
@@ -5,6 +5,7 @@
 #ifndef _ARK_EXT_H_
 #define _ARK_EXT_H_
 
+#include 
 #include 
 
 /* The following section lists function prototypes for Arkville's
@@ -16,6 +17,14 @@
  * See documentation for compiling and use of extensions.
  */
 
+/* private data optionally attached to mempool for rx */
+struct rte_pmd_ark_lmbuf_mempool_priv {
+   struct rte_pktmbuf_pool_private pool_private;
+   char cookie[4];
+   uint32_t dataroom;
+};
+#define ARK_MEMPOOL_COOKIE "ARK1"
+
 /**
  * Extension prototype, required implementation if extensions are used.
  * Called during device probe to initialize the user structure
diff --git a/drivers/net/ark/ark_udm.h b/drivers/net/ark/ark_udm.h
index f0685c95c7..ec53ec7e79 100644
--- a/drivers/net/ark/ark_udm.h
+++ b/drivers/net/ark/ark_udm.h
@@ -20,7 +20,8 @@
  */
 struct ark_rx_meta {
uint32_t user_meta[5];  /* user defined based on fpga code */
-   uint8_t  reserved[10];
+   uint32_t pkt_len32;
+   uint8_t  reserved[6];
uint16_t pkt_len;
 } __rte_packed;
 
@@ -33,7 +34,7 @@ struct ark_rx_meta {
 #define ARK_RX_WRITE_TIME_NS 2500
 #define ARK_UDM_SETUP 0
 #define ARK_UDM_MODID 0x4d445500
-#define ARK_UDM_MODVER 0x37313232
+#define ARK_UDM_MODVER 0x3732
 
 struct ark_udm_setup_t {
union {
-- 
2.34.1

[PATCH] eal/linux: verify mmu type for DPDK support (ppc64le)

[David Christensen]

IBM POWER systems support more than one type of memory management unit
(MMU).  The Power ISA 3.0 specification, which applies to P9 and later
CPUs, defined a new Radix MMU which, among other things, allows an
anonymous memory page mapping to be converted into a hugepage mapping
at a specific address. This is a required feature in DPDK so we need
to test the MMU type when POWER systems are used and provide a more
useful error message for the user when running on an unsupported
system.

Bugzilla ID: 1221
Suggested-by: Thomas Monjalon 
Signed-off-by: David Christensen 
---
 lib/eal/linux/eal.c | 63 +
 1 file changed, 63 insertions(+)

diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c
index 5f4b2fb0054a..1c546564fa9c 100644
--- a/lib/eal/linux/eal.c
+++ b/lib/eal/linux/eal.c
@@ -910,6 +910,62 @@ is_iommu_enabled(void)
return n > 2;
 }
 
+/*
+ * IBM POWER systems support more than one type of memory management unit 
(MMU).
+ * The Power ISA 3.0 specification, which applies to P9 and later CPUs, defined
+ * a new Radix MMU which, among other things, allows an anonymous memory page
+ * mapping to be converted into a hugepage mapping at a specific address. This
+ * is a required feature in DPDK so we need to test the MMU type when POWER
+ * systems are used.
+ */
+static bool
+is_mmu_supported(void)
+{
+#ifdef RTE_ARCH_PPC_64
+   static const char proc_cpuinfo[] = "/proc/cpuinfo";
+   static const char str_mmu[] = "MMU";
+   static const char str_radix[] = "Radix";
+   char buf[512];
+   char *ret = NULL;
+   FILE *f = fopen(proc_cpuinfo, "r");
+
+   if (f == NULL) {
+   RTE_LOG(ERR, EAL, "Cannot open %s\n", proc_cpuinfo);
+   return false;
+   }
+
+   /*
+* Example "MMU" in /proc/cpuinfo:
+* ...
+* model: 8335-GTW
+* machine  : PowerNV 8335-GTW
+* firmware : OPAL
+* MMU  : Radix
+* ... or ...
+* model: IBM,9009-22A
+* machine  : CHRP IBM,9009-22A
+* MMU  : Hash
+*/
+   while (fgets(buf, sizeof(buf), f) != NULL) {
+   ret = strstr(buf, str_mmu);
+   if (ret == NULL)
+   continue;
+   ret += sizeof(str_mmu) - 1;
+   ret = strchr(ret, ':');
+   if (ret == NULL)
+   continue;
+   ret = strstr(ret, str_radix);
+   break;
+   }
+   fclose(f);
+   if (ret == NULL)
+   rte_eal_init_alert("DPDK on PPC64 requires radix-mmu.");
+   return (ret != NULL);
+#else
+   return true;
+#endif
+}
+
 static __rte_noreturn void *
 eal_worker_thread_loop(void *arg)
 {
@@ -983,6 +1039,13 @@ rte_eal_init(int argc, char **argv)
return -1;
}
 
+   /* verify if mmu is supported */
+   if (!is_mmu_supported()) {
+   rte_eal_init_alert("unsupported mmu type.");
+   rte_errno = ENOTSUP;
+   return -1;
+   }
+
if (!__atomic_compare_exchange_n(&run_once, &has_run, 1, 0,
__ATOMIC_RELAXED, __ATOMIC_RELAXED)) {
rte_eal_init_alert("already called initialization.");
-- 
2.39.1

RE: [PATCH v2] ethdev: add TCP/IP modify field IDs

[Suanming Mou]

Hi,

> -Original Message-
> From: Ferruh Yigit 
> Sent: Tuesday, October 10, 2023 6:24 PM
> To: Suanming Mou ; Ori Kam ;
> Aman Singh ; Yuying Zhang
> ; NBU-Contact-Thomas Monjalon (EXTERNAL)
> ; Andrew Rybchenko
> 
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v2] ethdev: add TCP/IP modify field IDs
> 
> On 9/8/2023 4:49 AM, Suanming Mou wrote:
> > Currently, get TCP/IP header or data length information from traffic
> > is missing in the modify field IDs. This commit adds the missing TCP
> > data_offset, IPv4 IHL/total_len, IPv6 payload_len to modify filed IDs.
> > This allows users be able to manager more TCP/IP fields.
> >
> > Signed-off-by: Suanming Mou 
> > ---
> >
> > v2: fix typo tcp_date_off -> tcp_data_off
> >
> > ---
> >  app/test-pmd/cmdline_flow.c | 1 +
> >  lib/ethdev/rte_flow.h   | 4 
> >  2 files changed, 5 insertions(+)
> >
> 
> Hi Suanming,
> 
> Patch looks good. But, testpmd modify flow action support seems not
> documented at all, can you please first add it [1], later update that 
> document with
> this patch?
> 
> Also can you please check if `rte_flow.rst` also needs to be updated or not?

Sure, will check and update.
Thanks
> 
> 
> [1]: `doc/guides/testpmd_app_ug/testpmd_funcs.rst`, `Flow rules management`
> section

[PATCH 0/3] rewrite fastpath routines

[Vamsi Attunuru]

This series adds new fastpath routines for cn10k & cn9k endpoint
devices and supports 32B Tx desciptor format which improves the
performance.

Shijith Thotton (1):
  net/octeon_ep: support 32B IQ descriptor size

Vamsi Attunuru (2):
  net/octeon_ep: clean up receive routine
  net/octeon_ep: add new fastpath routines

 drivers/net/octeon_ep/cnxk_ep_rx.c| 309 ++
 drivers/net/octeon_ep/cnxk_ep_tx.c| 209 +
 drivers/net/octeon_ep/cnxk_ep_vf.c|  12 +-
 drivers/net/octeon_ep/cnxk_ep_vf.h|  13 ++
 drivers/net/octeon_ep/meson.build |   2 +
 drivers/net/octeon_ep/otx2_ep_vf.c|  11 +-
 drivers/net/octeon_ep/otx_ep_common.h | 127 ++-
 drivers/net/octeon_ep/otx_ep_ethdev.c |  69 +-
 drivers/net/octeon_ep/otx_ep_rxtx.c   | 263 +++---
 drivers/net/octeon_ep/otx_ep_rxtx.h   |  38 +++-
 drivers/net/octeon_ep/otx_ep_vf.c |   8 +
 11 files changed, 804 insertions(+), 257 deletions(-)
 create mode 100644 drivers/net/octeon_ep/cnxk_ep_rx.c
 create mode 100644 drivers/net/octeon_ep/cnxk_ep_tx.c

-- 
2.25.1

[PATCH 1/3] net/octeon_ep: support 32B IQ descriptor size

[Vamsi Attunuru]

From: Shijith Thotton 

Update input queue setup to consider descriptor size in driver conf.
The default instruction size for otx2 and cnxk devices has been updated
to 32 bytes.

Signed-off-by: Shijith Thotton 
---
 drivers/net/octeon_ep/cnxk_ep_vf.c| 10 +-
 drivers/net/octeon_ep/otx2_ep_vf.c| 10 +-
 drivers/net/octeon_ep/otx_ep_common.h |  4 
 drivers/net/octeon_ep/otx_ep_rxtx.c   |  8 +++-
 drivers/net/octeon_ep/otx_ep_vf.c |  8 
 5 files changed, 33 insertions(+), 7 deletions(-)

diff --git a/drivers/net/octeon_ep/cnxk_ep_vf.c 
b/drivers/net/octeon_ep/cnxk_ep_vf.c
index 92c2d2ca5c..7b3669fe0c 100644
--- a/drivers/net/octeon_ep/cnxk_ep_vf.c
+++ b/drivers/net/octeon_ep/cnxk_ep_vf.c
@@ -106,6 +106,14 @@ cnxk_ep_vf_setup_iq_regs(struct otx_ep_device *otx_ep, 
uint32_t iq_no)
return -EIO;
}
 
+   /* Configure input queue instruction size. */
+   if (otx_ep->conf->iq.instr_type == OTX_EP_32BYTE_INSTR)
+   reg_val &= ~(CNXK_EP_R_IN_CTL_IS_64B);
+   else
+   reg_val |= CNXK_EP_R_IN_CTL_IS_64B;
+   oct_ep_write64(reg_val, otx_ep->hw_addr + CNXK_EP_R_IN_CONTROL(iq_no));
+   iq->desc_size = otx_ep->conf->iq.instr_type;
+
/* Write the start of the input queue's ring and its size  */
oct_ep_write64(iq->base_addr_dma, otx_ep->hw_addr + 
CNXK_EP_R_IN_INSTR_BADDR(iq_no));
oct_ep_write64(iq->nb_desc, otx_ep->hw_addr + 
CNXK_EP_R_IN_INSTR_RSIZE(iq_no));
@@ -354,7 +362,7 @@ static const struct otx_ep_config default_cnxk_ep_conf = {
/* IQ attributes */
.iq= {
.max_iqs   = OTX_EP_CFG_IO_QUEUES,
-   .instr_type= OTX_EP_64BYTE_INSTR,
+   .instr_type= OTX_EP_32BYTE_INSTR,
.pending_list_size = (OTX_EP_MAX_IQ_DESCRIPTORS *
  OTX_EP_CFG_IO_QUEUES),
},
diff --git a/drivers/net/octeon_ep/otx2_ep_vf.c 
b/drivers/net/octeon_ep/otx2_ep_vf.c
index ced3a415a5..f72b8d25d7 100644
--- a/drivers/net/octeon_ep/otx2_ep_vf.c
+++ b/drivers/net/octeon_ep/otx2_ep_vf.c
@@ -256,6 +256,14 @@ otx2_vf_setup_iq_regs(struct otx_ep_device *otx_ep, 
uint32_t iq_no)
return -EIO;
}
 
+   /* Configure input queue instruction size. */
+   if (otx_ep->conf->iq.instr_type == OTX_EP_32BYTE_INSTR)
+   reg_val &= ~(SDP_VF_R_IN_CTL_IS_64B);
+   else
+   reg_val |= SDP_VF_R_IN_CTL_IS_64B;
+   oct_ep_write64(reg_val, otx_ep->hw_addr + SDP_VF_R_IN_CONTROL(iq_no));
+   iq->desc_size = otx_ep->conf->iq.instr_type;
+
/* Write the start of the input queue's ring and its size  */
oct_ep_write64(iq->base_addr_dma, otx_ep->hw_addr + 
SDP_VF_R_IN_INSTR_BADDR(iq_no));
oct_ep_write64(iq->nb_desc, otx_ep->hw_addr + 
SDP_VF_R_IN_INSTR_RSIZE(iq_no));
@@ -500,7 +508,7 @@ static const struct otx_ep_config default_otx2_ep_conf = {
/* IQ attributes */
.iq= {
.max_iqs   = OTX_EP_CFG_IO_QUEUES,
-   .instr_type= OTX_EP_64BYTE_INSTR,
+   .instr_type= OTX_EP_32BYTE_INSTR,
.pending_list_size = (OTX_EP_MAX_IQ_DESCRIPTORS *
  OTX_EP_CFG_IO_QUEUES),
},
diff --git a/drivers/net/octeon_ep/otx_ep_common.h 
b/drivers/net/octeon_ep/otx_ep_common.h
index c150cbe619..90e059cad0 100644
--- a/drivers/net/octeon_ep/otx_ep_common.h
+++ b/drivers/net/octeon_ep/otx_ep_common.h
@@ -11,6 +11,7 @@
 
 #define OTX_EP_MAX_RINGS_PER_VF(8)
 #define OTX_EP_CFG_IO_QUEUESOTX_EP_MAX_RINGS_PER_VF
+#define OTX_EP_32BYTE_INSTR (32)
 #define OTX_EP_64BYTE_INSTR (64)
 /*
  * Backpressure for SDP is configured on Octeon, and the minimum queue sizes
@@ -215,6 +216,9 @@ struct otx_ep_instr_queue {
/* Number of  descriptors in this ring. */
uint32_t nb_desc;
 
+   /* Size of the descriptor. */
+   uint8_t desc_size;
+
/* Input ring index, where the driver should write the next packet */
uint32_t host_write_index;
 
diff --git a/drivers/net/octeon_ep/otx_ep_rxtx.c 
b/drivers/net/octeon_ep/otx_ep_rxtx.c
index b37fc8109f..5b759d759b 100644
--- a/drivers/net/octeon_ep/otx_ep_rxtx.c
+++ b/drivers/net/octeon_ep/otx_ep_rxtx.c
@@ -484,7 +484,7 @@ otx_ep_ring_doorbell(struct otx_ep_device *otx_ep 
__rte_unused,
 static inline int
 post_iqcmd(struct otx_ep_instr_queue *iq, uint8_t *iqcmd)
 {
-   uint8_t *iqptr, cmdsize;
+   uint8_t *iqptr;
 
/* This ensures that the read index does not wrap around to
 * the same position if queue gets full before OCTEON 9 could
@@ -494,10 +494,8 @@ post_iqcmd(struct otx_ep_instr_queue *iq, uint8_t *iqcmd)
return OTX_EP_IQ_SEND_FAILED;
 
/* Copy cmd into iq */
-   cmdsize = 64;
-   iqptr   = iq->base_addr + (iq->host_write_index << 6

[PATCH 2/3] net/octeon_ep: clean up receive routine

[Vamsi Attunuru]

Patch improves Rx routine and pkt count update routines,
packet count update routines need to drain inflight ISM
memory updates while decrementing the packet count register.

Signed-off-by: Vamsi Attunuru 
---
 drivers/net/octeon_ep/otx_ep_rxtx.c | 162 
 1 file changed, 68 insertions(+), 94 deletions(-)

diff --git a/drivers/net/octeon_ep/otx_ep_rxtx.c 
b/drivers/net/octeon_ep/otx_ep_rxtx.c
index 5b759d759b..ea7c9a5d62 100644
--- a/drivers/net/octeon_ep/otx_ep_rxtx.c
+++ b/drivers/net/octeon_ep/otx_ep_rxtx.c
@@ -442,7 +442,14 @@ otx_vf_update_read_index(struct otx_ep_instr_queue *iq)
 * when count above halfway to saturation.
 */
rte_write32(val, iq->inst_cnt_reg);
-   *iq->inst_cnt_ism = 0;
+   rte_mb();
+
+   rte_write64(OTX2_SDP_REQUEST_ISM, iq->inst_cnt_reg);
+   while (__atomic_load_n(iq->inst_cnt_ism, __ATOMIC_RELAXED) >= 
val) {
+   rte_write64(OTX2_SDP_REQUEST_ISM, iq->inst_cnt_reg);
+   rte_mb();
+   }
+
iq->inst_cnt_ism_prev = 0;
}
rte_write64(OTX2_SDP_REQUEST_ISM, iq->inst_cnt_reg);
@@ -565,9 +572,7 @@ prepare_xmit_gather_list(struct otx_ep_instr_queue *iq, 
struct rte_mbuf *m, uint
 
finfo = &iq->req_list[iq->host_write_index].finfo;
*dptr = rte_mem_virt2iova(finfo->g.sg);
-   ih->s.tlen = pkt_len + ih->s.fsz;
-   ih->s.gsz = frags;
-   ih->s.gather = 1;
+   ih->u64 |= ((1ULL << 62) | ((uint64_t)frags << 48) | (pkt_len + 
ih->s.fsz));
 
while (frags--) {
finfo->g.sg[(j >> 2)].ptr[(j & mask)] = rte_mbuf_data_iova(m);
@@ -750,36 +755,26 @@ otx2_ep_xmit_pkts(void *tx_queue, struct rte_mbuf **pkts, 
uint16_t nb_pkts)
 static uint32_t
 otx_ep_droq_refill(struct otx_ep_droq *droq)
 {
-   struct otx_ep_droq_desc *desc_ring;
+   struct otx_ep_droq_desc *desc_ring = droq->desc_ring;
struct otx_ep_droq_info *info;
struct rte_mbuf *buf = NULL;
uint32_t desc_refilled = 0;
 
-   desc_ring = droq->desc_ring;
-
while (droq->refill_count && (desc_refilled < droq->nb_desc)) {
-   /* If a valid buffer exists (happens if there is no dispatch),
-* reuse the buffer, else allocate.
-*/
-   if (droq->recv_buf_list[droq->refill_idx] != NULL)
-   break;
-
buf = rte_pktmbuf_alloc(droq->mpool);
/* If a buffer could not be allocated, no point in
 * continuing
 */
-   if (buf == NULL) {
+   if (unlikely(!buf)) {
droq->stats.rx_alloc_failure++;
break;
}
info = rte_pktmbuf_mtod(buf, struct otx_ep_droq_info *);
-   memset(info, 0, sizeof(*info));
+   info->length = 0;
 
droq->recv_buf_list[droq->refill_idx] = buf;
desc_ring[droq->refill_idx].buffer_ptr =
rte_mbuf_data_iova_default(buf);
-
-
droq->refill_idx = otx_ep_incr_index(droq->refill_idx, 1,
droq->nb_desc);
 
@@ -791,21 +786,18 @@ otx_ep_droq_refill(struct otx_ep_droq *droq)
 }
 
 static struct rte_mbuf *
-otx_ep_droq_read_packet(struct otx_ep_device *otx_ep,
-   struct otx_ep_droq *droq, int next_fetch)
+otx_ep_droq_read_packet(struct otx_ep_device *otx_ep, struct otx_ep_droq 
*droq, int next_fetch)
 {
volatile struct otx_ep_droq_info *info;
-   struct rte_mbuf *droq_pkt2 = NULL;
-   struct rte_mbuf *droq_pkt = NULL;
-   struct rte_net_hdr_lens hdr_lens;
-   struct otx_ep_droq_info *info2;
+   struct rte_mbuf *mbuf_next = NULL;
+   struct rte_mbuf *mbuf = NULL;
uint64_t total_pkt_len;
uint32_t pkt_len = 0;
int next_idx;
 
-   droq_pkt  = droq->recv_buf_list[droq->read_idx];
-   droq_pkt2  = droq->recv_buf_list[droq->read_idx];
-   info = rte_pktmbuf_mtod(droq_pkt, struct otx_ep_droq_info *);
+   mbuf = droq->recv_buf_list[droq->read_idx];
+   info = rte_pktmbuf_mtod(mbuf, struct otx_ep_droq_info *);
+
/* make sure info is available */
rte_rmb();
if (unlikely(!info->length)) {
@@ -826,32 +818,25 @@ otx_ep_droq_read_packet(struct otx_ep_device *otx_ep,
assert(0);
}
}
+
if (next_fetch) {
next_idx = otx_ep_incr_index(droq->read_idx, 1, droq->nb_desc);
-   droq_pkt2  = droq->recv_buf_list[next_idx];
-   info2 = rte_pktmbuf_mtod(droq_pkt2, struct otx_ep_droq_info *);
-   rte_prefetch_non_temporal((const void *)info2);
+   mbuf_next = droq->recv_buf_list[next_idx];
+   rte_prefetch0(rte_pktmbuf_mtod(mbuf_next, void *));
}
 
-   info->

[PATCH 3/3] net/octeon_ep: add new fastpath routines

[Vamsi Attunuru]

Adds new fastpath routines for cn10k & cn9k endpoint
devices and assigns the fastpath routines based on
the offload flags.

Patch also adds misc changes to improve performance
and code-readability.

Signed-off-by: Vamsi Attunuru 
---
 drivers/net/octeon_ep/cnxk_ep_rx.c| 309 ++
 drivers/net/octeon_ep/cnxk_ep_tx.c| 209 +
 drivers/net/octeon_ep/cnxk_ep_vf.c|   2 +
 drivers/net/octeon_ep/cnxk_ep_vf.h|  13 ++
 drivers/net/octeon_ep/meson.build |   2 +
 drivers/net/octeon_ep/otx2_ep_vf.c|   1 +
 drivers/net/octeon_ep/otx_ep_common.h | 125 ++-
 drivers/net/octeon_ep/otx_ep_ethdev.c |  69 +-
 drivers/net/octeon_ep/otx_ep_rxtx.c   |  93 +---
 drivers/net/octeon_ep/otx_ep_rxtx.h   |  38 +++-
 10 files changed, 704 insertions(+), 157 deletions(-)

diff --git a/drivers/net/octeon_ep/cnxk_ep_rx.c 
b/drivers/net/octeon_ep/cnxk_ep_rx.c
new file mode 100644
index 00..74f0011283
--- /dev/null
+++ b/drivers/net/octeon_ep/cnxk_ep_rx.c
@@ -0,0 +1,309 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell.
+ */
+
+#include "otx_ep_common.h"
+#include "otx2_ep_vf.h"
+#include "otx_ep_rxtx.h"
+
+static inline int
+cnxk_ep_rx_refill_mbuf(struct otx_ep_droq *droq, uint32_t count)
+{
+   struct otx_ep_droq_desc *desc_ring = droq->desc_ring;
+   struct rte_mbuf **recv_buf_list = droq->recv_buf_list;
+   uint32_t refill_idx = droq->refill_idx;
+   struct rte_mbuf *buf;
+   uint32_t i;
+   int rc;
+
+   rc = rte_pktmbuf_alloc_bulk(droq->mpool, &recv_buf_list[refill_idx], 
count);
+   if (unlikely(rc)) {
+   droq->stats.rx_alloc_failure++;
+   return rc;
+   }
+
+   for (i = 0; i < count; i++) {
+   buf = recv_buf_list[refill_idx];
+   desc_ring[refill_idx].buffer_ptr = 
rte_mbuf_data_iova_default(buf);
+   refill_idx++;
+   }
+
+   droq->refill_idx = otx_ep_incr_index(droq->refill_idx, count, 
droq->nb_desc);
+   droq->refill_count -= count;
+
+   return 0;
+}
+
+static inline void
+cnxk_ep_rx_refill(struct otx_ep_droq *droq)
+{
+   uint32_t desc_refilled = 0, count;
+   uint32_t nb_desc = droq->nb_desc;
+   uint32_t refill_idx = droq->refill_idx;
+   int rc;
+
+   if (unlikely(droq->read_idx == refill_idx))
+   return;
+
+   if (refill_idx < droq->read_idx) {
+   count = droq->read_idx - refill_idx;
+   rc = cnxk_ep_rx_refill_mbuf(droq, count);
+   if (unlikely(rc)) {
+   droq->stats.rx_alloc_failure++;
+   return;
+   }
+   desc_refilled = count;
+   } else {
+   count = nb_desc - refill_idx;
+   rc = cnxk_ep_rx_refill_mbuf(droq, count);
+   if (unlikely(rc)) {
+   droq->stats.rx_alloc_failure++;
+   return;
+   }
+
+   desc_refilled = count;
+   count = droq->read_idx;
+   rc = cnxk_ep_rx_refill_mbuf(droq, count);
+   if (unlikely(rc)) {
+   droq->stats.rx_alloc_failure++;
+   return;
+   }
+   desc_refilled += count;
+   }
+
+   /* Flush the droq descriptor data to memory to be sure
+* that when we update the credits the data in memory is
+* accurate.
+*/
+   rte_io_wmb();
+   rte_write32(desc_refilled, droq->pkts_credit_reg);
+}
+
+static inline uint32_t
+cnxk_ep_check_rx_pkts(struct otx_ep_droq *droq)
+{
+   uint32_t new_pkts;
+   uint32_t val;
+
+   /* Batch subtractions from the HW counter to reduce PCIe traffic
+* This adds an extra local variable, but almost halves the
+* number of PCIe writes.
+*/
+   val = __atomic_load_n(droq->pkts_sent_ism, __ATOMIC_RELAXED);
+   new_pkts = val - droq->pkts_sent_ism_prev;
+   droq->pkts_sent_ism_prev = val;
+
+   if (val > (uint32_t)(1 << 31)) {
+   /* Only subtract the packet count in the HW counter
+* when count above halfway to saturation.
+*/
+   rte_write64((uint64_t)val, droq->pkts_sent_reg);
+   rte_mb();
+
+   rte_write64(OTX2_SDP_REQUEST_ISM, droq->pkts_sent_reg);
+   while (__atomic_load_n(droq->pkts_sent_ism, __ATOMIC_RELAXED) 
>= val) {
+   rte_write64(OTX2_SDP_REQUEST_ISM, droq->pkts_sent_reg);
+   rte_mb();
+   }
+
+   droq->pkts_sent_ism_prev = 0;
+   }
+   rte_write64(OTX2_SDP_REQUEST_ISM, droq->pkts_sent_reg);
+   droq->pkts_pending += new_pkts;
+
+   return new_pkts;
+}
+
+static inline int16_t __rte_hot
+cnxk_ep_rx_pkts_to_process(struct otx_ep_droq *droq, uint16_t nb_pkts)
+{
+   if (droq->pkts_pending < nb_pkts)
+   cnxk_ep_check_rx_pkts(d

Re: [PATCH] doc: remove confusing command to send patch

[fengchengwen]

Acked-by: Chengwen Feng 

On 2023/10/11 0:26, Thomas Monjalon wrote:
> In the contributor guide, it was said that no need to Cc maintainers
> for new additions, probably for new directories not having a maintainer.
> There is no harm, and it is a good habit, to always Cc maintainers.
> 
> Remove this case as it can mislead to not Cc maintainers when needed.
> 
> Signed-off-by: Thomas Monjalon 
> ---
>  doc/guides/contributing/patches.rst | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/doc/guides/contributing/patches.rst 
> b/doc/guides/contributing/patches.rst
> index e286d9e6d5..d114ceba2b 100644
> --- a/doc/guides/contributing/patches.rst
> +++ b/doc/guides/contributing/patches.rst
> @@ -561,10 +561,6 @@ Script ``get-maintainer.sh`` can be used to select 
> maintainers automatically::
>  
>git send-email --to-cmd ./devtools/get-maintainer.sh --cc dev@dpdk.org 
> 000*.patch
>  
> -New additions can be sent without a maintainer::
> -
> -   git send-email --to dev@dpdk.org 000*.patch
> -
>  You can test the emails by sending it to yourself or with the ``--dry-run`` 
> option.
>  
>  If the patch is in relation to a previous email thread you can add it to the 
> same thread using the Message ID::
> 

Re: [PATCH] ethdev: add calculate hash function

[fengchengwen]

Hi,

On 2023/10/10 19:05, Ferruh Yigit wrote:
> On 9/26/2023 12:37 PM, Ori Kam wrote:
>> rte_flow supports insert by index table[1].
>>
>> Using the above table, the application can create rules
>> that are based on hash.
>> For example application can create the following logic in order
>> to create load balancing:
>> 1. Create insert by index table with 2 rules, that hashes based on dmac
>> 2. Insert to index 0 a rule that sends the traffic to port A.
>> 3. Insert to index 1 a rule that sends the traffic to port B.
>>
>> Let's also assume that before this table, there is a 5 tuple
>> match table that jumps to the above table.
>>
>> So each packet that matches one of the 5 tuple rules is RSSed
>> to port A or B, based on dmac hash.
>>
>> The issue arises when there is a miss on the 5 tuple table,
>> which resulted due to the packet being the first packet of this flow, or
>> fragmented packet or any other reason.
>> In this case, the application must calculate what would be the
>> hash calculated by the HW so it can send the packet to the correct
>> port.
>>
>> This new API allows applications to calculate the hash value of a given
>> packet for a given table.
>>
>> [1] - 
>> http://patches.dpdk.org/project/dpdk/patch/20230208030624.78465-2-akozy...@nvidia.com/
>>
>> Signed-off-by: Ori Kam 
>> ---
>>  app/test-pmd/cmdline_flow.c  | 86 +++-
>>  app/test-pmd/config.c| 54 ++
>>  app/test-pmd/testpmd.h   |  2 +
>>  lib/ethdev/rte_flow.c| 21 +
>>  lib/ethdev/rte_flow.h| 32 ++
>>  lib/ethdev/rte_flow_driver.h |  5 +++
>>  lib/ethdev/version.map   |  1 +
>>  7 files changed, 200 insertions(+), 1 deletion(-)
>>
> 
> This is a new rte_flow API but unfortunately there isn't any
> review/comment, at least it is experimental API. If there is no
> objection/discussion in next few days, I will merge the feature.
> 
> Probably it will be another rte flow feature that only NVIDIA knows and
> uses. While mentioned from using, is the driver update for the feature

The hns3 driver support subset of rte_flow, we found the rte_flow feature is 
very flexible.
And its implementation varies according to vendors.

Can the rte_flow be standardized ?

> planned for this release?
> 
> 
> Meanwhile, can you please update the documentation, `rte_flow.rst` and
> `testpmd_funcs.rst`?
> Also can you please rebase on top of latest next-net, this patch
> conflicts with merged group set miss action feature.
> 
> .
> 

RE: [PATCH v4] app/testpmd: enable cli for programmable action

[Zhang, Qi Z]

> -Original Message-
> From: Ferruh Yigit 
> Sent: Tuesday, October 10, 2023 6:49 PM
> To: Zhang, Qi Z ; Singh, Aman Deep
> ; Zhang, Yuying 
> Cc: dev@dpdk.org; Dumitrescu, Cristian ;
> or...@nvidia.com
> Subject: Re: [PATCH v4] app/testpmd: enable cli for programmable action
> 
> On 10/7/2023 11:47 AM, Qi Zhang wrote:
> > Parsing command line for rte_flow_action_prog.
> >
> > Syntax:
> >
> > "prog name  [arguments   \
> >   ... end]"
> >
> 
> Can you please put full rte flow command in the commit log? Like what is the
> 'pattern' for above command?

The pattern part should be independent of the action part,

though for our P4 device, we will prefer use rte_flow_flex_item, something like:

flow create 0 pattern flex item is xxx pattern is xxx / flex item is xxx 
pattern is / actions prog name ..

but it does not limit PMD to support flow like below

flow create 0 pattern eth / ipv4 src is 1.1.1.1 / actions prog name ..

So I think it may not be necessary to highlight the pattern format here.

> 
> 
> > Use parse_string0 to parse name string.
> > Use parse_hex to parse hex string.
> > Use struct action_prog_data to store parsed result.
> >
> > Example:
> >
> > Action with 2 arguments:
> >
> > "prog name action0 arguments field0 03FF field1 55AA end"
> >
> > Action without argument:
> >
> > "prog name action1"
> >
> > Signed-off-by: Qi Zhang 
> >
> 
> Is there an existing driver implementation, checking it helps to understand
> feature implementation?

This work is still ongoing, currently we target to upstream on DPDK 24.03

> 
> 
> > ---
> >
> > v4:
> > - be more generous on the max size of name and value.
> >
> > v3:
> > - refine struct action_prog_data
> > - enlarge the max size
> >
> > v2:
> > - fix title
> > - minor coding style refine.
> >
> >  app/test-pmd/cmdline_flow.c | 232
> > 
> >  1 file changed, 232 insertions(+)
> >
> 
> Hi Qi,
> 
> Can you please update documentation too,
> `doc/guides/testpmd_app_ug/testpmd_funcs.rst`, `Flow rules management`
> section.

Sure.

> 
> 
> > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> > index 21828c144c..ae5556e704 100644
> > --- a/app/test-pmd/cmdline_flow.c
> > +++ b/app/test-pmd/cmdline_flow.c
> > @@ -719,6 +719,13 @@ enum index {
> > ACTION_IPV6_EXT_PUSH,
> > ACTION_IPV6_EXT_PUSH_INDEX,
> > ACTION_IPV6_EXT_PUSH_INDEX_VALUE,
> > +   ACTION_PROG,
> > +   ACTION_PROG_NAME,
> > +   ACTION_PROG_NAME_STRING,
> > +   ACTION_PROG_ARGUMENTS,
> > +   ACTION_PROG_ARG_NAME,
> > +   ACTION_PROG_ARG_VALUE,
> > +   ACTION_PROG_ARG_END,
> >  };
> >
> >  /** Maximum size for pattern in struct rte_flow_item_raw. */ @@
> > -749,6 +756,23 @@ struct action_rss_data {
> > uint16_t queue[ACTION_RSS_QUEUE_NUM];  };
> >
> > +#define ACTION_PROG_NAME_SIZE_MAX 256 #define
> ACTION_PROG_ARG_NUM_MAX
> > +16 #define ACTION_PROG_ARG_VALUE_SIZE_MAX 64
> > +
> > +/** Storage for struct rte_flow_action_prog including external data.
> > +*/ struct action_prog_data {
> > +   struct rte_flow_action_prog conf;
> > +   struct {
> > +   char name[ACTION_PROG_NAME_SIZE_MAX];
> > +   struct rte_flow_action_prog_argument
> args[ACTION_PROG_ARG_NUM_MAX];
> > +   struct {
> > +   char names[ACTION_PROG_NAME_SIZE_MAX];
> > +   uint8_t
> value[ACTION_PROG_ARG_VALUE_SIZE_MAX];
> > +   } arg_data[ACTION_PROG_ARG_NUM_MAX];
> > +   } data;
> > +};
> > +
> >  /** Maximum data size in struct rte_flow_action_raw_encap. */
> > #define ACTION_RAW_ENCAP_MAX_DATA 512  #define
> RAW_ENCAP_CONFS_MAX_NUM
> > 8 @@ -2169,6 +2193,7 @@ static const enum index next_action[] = {
> > ACTION_QUOTA_QU,
> > ACTION_IPV6_EXT_REMOVE,
> > ACTION_IPV6_EXT_PUSH,
> > +   ACTION_PROG,
> > ZERO,
> >  };
> >
> > @@ -2510,6 +2535,13 @@ static const enum index
> action_represented_port[] = {
> > ZERO,
> >  };
> >
> > +static const enum index action_prog[] = {
> > +   ACTION_PROG_NAME,
> > +   ACTION_PROG_ARGUMENTS,
> > +   ACTION_NEXT,
> > +   ZERO,
> > +};
> > +
> >  static int parse_set_raw_encap_decap(struct context *, const struct token 
> > *,
> >  const char *, unsigned int,
> >  void *, unsigned int);
> > @@ -2786,6 +2818,18 @@ static int
> >  parse_qu_mode_name(struct context *ctx, const struct token *token,
> >const char *str, unsigned int len, void *buf,
> >unsigned int size);
> > +static int
> > +parse_vc_action_prog(struct context *, const struct token *,
> > +const char *, unsigned int, void *,
> > +unsigned int);
> > +static int
> > +parse_vc_action_prog_arg_name(struct context *, const struct token *,
> > + const char *, unsigned int, void *,
> > + unsigned int);
> > +static int
> > +parse_vc_action_prog_arg_value(struct context *, const struct token *,
> > +  

[PATCH] net/cpfl: update CP channel API

[beilei . xing]

From: Beilei Xing 

Update the cpchnl2 function type according to the definition in
MEV 1.0 release.

Signed-off-by: Beilei Xing 
---
 drivers/net/cpfl/cpfl_cpchnl.h  | 19 ++-
 drivers/net/cpfl/cpfl_ethdev.h  |  2 +-
 drivers/net/cpfl/cpfl_representor.c | 20 ++--
 3 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/net/cpfl/cpfl_cpchnl.h b/drivers/net/cpfl/cpfl_cpchnl.h
index 2eefcbcc10..667fadcac4 100644
--- a/drivers/net/cpfl/cpfl_cpchnl.h
+++ b/drivers/net/cpfl/cpfl_cpchnl.h
@@ -22,9 +22,6 @@ enum cpchnl2_ops {
 
 #define CPCHNL2_ETH_LENGTH_OF_ADDRESS  6
 
-#define CPCHNL2_FUNC_TYPE_PF   0
-#define CPCHNL2_FUNC_TYPE_SRIOV1
-
 /* vport statuses - must match the DB ones - see enum cp_vport_status*/
 #define CPCHNL2_VPORT_STATUS_CREATED   0
 #define CPCHNL2_VPORT_STATUS_ENABLED   1
@@ -136,8 +133,10 @@ CPCHNL2_CHECK_STRUCT_LEN(3792, cpchnl2_queue_groups);
  * @brief function types
  */
 enum cpchnl2_func_type {
-   CPCHNL2_FTYPE_LAN_PF = 0,
-   CPCHNL2_FTYPE_LAN_VF = 1,
+   CPCHNL2_FTYPE_LAN_VF = 0x0,
+   CPCHNL2_FTYPE_LAN_VM = 0x1,
+   CPCHNL2_FTYPE_LAN_PF = 0x2,
+   CPCHNL2_FTYPE_LAN_IMC_BMC = 0x3,
CPCHNL2_FTYPE_LAN_MAX
 };
 
@@ -176,7 +175,7 @@ struct cpchnl2_vport_info {
 */
u16 vsi_id;
u8 vport_status;/* enum cpchnl2_vport_status */
-   /* 0 - LAN PF, 1 - LAN VF. Rest - reserved. Can be later expanded to 
other PEs */
+   /* 0 - LAN VF, 2 - LAN PF. Rest - reserved. Can be later expanded to 
other PEs */
u8 func_type;
/* Valid only if "type" above is VF, indexing is relative to PF 
specified above. */
u16 vf_id;
@@ -216,7 +215,9 @@ struct cpchnl2_vport_info {
u16 default_rx_qid; /* Default LAN RX Queue ID */
u16 vport_flags; /* see: VPORT_FLAGS */
u8 egress_port;
-   u8 pad_reserved[5];
+   /* Host LAN APF: 0; ACC LAN APF: 4; IMC LAN APF: 5; ACC LAN CPF: 4; IMC 
LAN CPF: 5 */
+   u8 host_id;
+   u8 pad_reserved[4];
 };
 CPCHNL2_CHECK_STRUCT_LEN(96, cpchnl2_vport_info);
 
@@ -226,7 +227,7 @@ CPCHNL2_CHECK_STRUCT_LEN(96, cpchnl2_vport_info);
 
 /**
  * @brief Used for CPCHNL2_OP_GET_VPORT_LIST opcode request
- * @param func_type Func type: 0 - LAN_PF, 1 - LAN_VF. Rest - reserved (see 
enum cpchnl2_func_type)
+ * @param func_type Func type: 0 - LAN_VF, 2 - LAN_PF. Rest - reserved (see 
enum cpchnl2_func_type)
  * @param pf_id Always relevant, indexing is according to LAN PE 0-15, while 
only 0-4 APFs and 8-12
  *CPFs are valid
  * @param vf_id Valid only if "type" above is VF, indexing is relative to PF 
specified above
@@ -241,7 +242,7 @@ CPCHNL2_CHECK_STRUCT_LEN(8, cpchnl2_get_vport_list_request);
 
 /**
  * @brief Used for CPCHNL2_OP_GET_VPORT_LIST opcode response
- * @param func_type Func type: 0 - LAN_PF, 1 - LAN_VF. Rest - reserved. Can be 
later extended to
+ * @param func_type Func type: 0 - LAN_VF, 2 - LAN_PF. Rest - reserved. Can be 
later extended to
  *other PE types
  * @param pf_id Always relevant, indexing is according to LAN PE 0-15, while 
only 0-4 APFs and 8-12
  *CPFs are valid
diff --git a/drivers/net/cpfl/cpfl_ethdev.h b/drivers/net/cpfl/cpfl_ethdev.h
index efb0eb5251..bb53fca7c0 100644
--- a/drivers/net/cpfl/cpfl_ethdev.h
+++ b/drivers/net/cpfl/cpfl_ethdev.h
@@ -296,7 +296,7 @@ cpfl_get_vsi_id(struct cpfl_itf *itf)
} else if (itf->type == CPFL_ITF_TYPE_VPORT) {
vport_id = ((struct cpfl_vport *)itf)->base.vport_id;
 
-   vport_identity.func_type = CPCHNL2_FUNC_TYPE_PF;
+   vport_identity.func_type = CPCHNL2_FTYPE_LAN_PF;
/* host: CPFL_HOST0_CPF_ID, acc: CPFL_ACC_CPF_ID */
vport_identity.pf_id = CPFL_ACC_CPF_ID;
vport_identity.vf_id = 0;
diff --git a/drivers/net/cpfl/cpfl_representor.c 
b/drivers/net/cpfl/cpfl_representor.c
index de3b426727..cb253f7af4 100644
--- a/drivers/net/cpfl/cpfl_representor.c
+++ b/drivers/net/cpfl/cpfl_representor.c
@@ -348,12 +348,12 @@ cpfl_repr_link_update(struct rte_eth_dev *ethdev,
if (wait_to_complete) {
if (repr->repr_id.type == RTE_ETH_REPRESENTOR_PF) {
/* PF */
-   vi.func_type = CPCHNL2_FUNC_TYPE_PF;
+   vi.func_type = CPCHNL2_FTYPE_LAN_PF;
vi.pf_id = cpfl_func_id_get(repr->repr_id.host_id, 
repr->repr_id.pf_id);
vi.vf_id = 0;
} else {
/* VF */
-   vi.func_type = CPCHNL2_FUNC_TYPE_SRIOV;
+   vi.func_type = CPCHNL2_FTYPE_LAN_VF;
vi.pf_id = CPFL_HOST0_APF;
vi.vf_id = repr->repr_id.vf_id;
}
@@ -455,14 +455,14 @@ cpfl_match_repr_with_vport(const struct cpfl_repr_id 
*repr_id,
int func_id;
 
if (repr_id->type == RTE_ETH_REPRES

[PATCH v5] app/testpmd: enable cli for programmable action

[Qi Zhang]

Parsing command line for rte_flow_action_prog.

Syntax:

"prog name  [arguments   \
   ... end]"

Use parse_string0 to parse name string.
Use parse_hex to parse hex string.
Use struct action_prog_data to store parsed result.

Example:

Action with 2 arguments:

"prog name action0 arguments field0 03FF field1 55AA end"

Action without argument:

"prog name action1"

Signed-off-by: Qi Zhang 
---
v5:
- complete testpmd document.

v4:
- be more generous on the max size of name and value.

v3:
- refine struct action_prog_data
- enlarge the max size

v2:
- fix title
- minor coding style refine.

 app/test-pmd/cmdline_flow.c | 232 
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  17 ++
 2 files changed, 249 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 70eef3e34d..d9152f9485 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -721,6 +721,13 @@ enum index {
ACTION_IPV6_EXT_PUSH,
ACTION_IPV6_EXT_PUSH_INDEX,
ACTION_IPV6_EXT_PUSH_INDEX_VALUE,
+   ACTION_PROG,
+   ACTION_PROG_NAME,
+   ACTION_PROG_NAME_STRING,
+   ACTION_PROG_ARGUMENTS,
+   ACTION_PROG_ARG_NAME,
+   ACTION_PROG_ARG_VALUE,
+   ACTION_PROG_ARG_END,
 };
 
 /** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -751,6 +758,23 @@ struct action_rss_data {
uint16_t queue[ACTION_RSS_QUEUE_NUM];
 };
 
+#define ACTION_PROG_NAME_SIZE_MAX 256
+#define ACTION_PROG_ARG_NUM_MAX 16
+#define ACTION_PROG_ARG_VALUE_SIZE_MAX 64
+
+/** Storage for struct rte_flow_action_prog including external data. */
+struct action_prog_data {
+   struct rte_flow_action_prog conf;
+   struct {
+   char name[ACTION_PROG_NAME_SIZE_MAX];
+   struct rte_flow_action_prog_argument 
args[ACTION_PROG_ARG_NUM_MAX];
+   struct {
+   char names[ACTION_PROG_NAME_SIZE_MAX];
+   uint8_t value[ACTION_PROG_ARG_VALUE_SIZE_MAX];
+   } arg_data[ACTION_PROG_ARG_NUM_MAX];
+   } data;
+};
+
 /** Maximum data size in struct rte_flow_action_raw_encap. */
 #define ACTION_RAW_ENCAP_MAX_DATA 512
 #define RAW_ENCAP_CONFS_MAX_NUM 8
@@ -2178,6 +2202,7 @@ static const enum index next_action[] = {
ACTION_QUOTA_QU,
ACTION_IPV6_EXT_REMOVE,
ACTION_IPV6_EXT_PUSH,
+   ACTION_PROG,
ZERO,
 };
 
@@ -2519,6 +2544,13 @@ static const enum index action_represented_port[] = {
ZERO,
 };
 
+static const enum index action_prog[] = {
+   ACTION_PROG_NAME,
+   ACTION_PROG_ARGUMENTS,
+   ACTION_NEXT,
+   ZERO,
+};
+
 static int parse_set_raw_encap_decap(struct context *, const struct token *,
 const char *, unsigned int,
 void *, unsigned int);
@@ -2795,6 +2827,18 @@ static int
 parse_qu_mode_name(struct context *ctx, const struct token *token,
   const char *str, unsigned int len, void *buf,
   unsigned int size);
+static int
+parse_vc_action_prog(struct context *, const struct token *,
+const char *, unsigned int, void *,
+unsigned int);
+static int
+parse_vc_action_prog_arg_name(struct context *, const struct token *,
+ const char *, unsigned int, void *,
+ unsigned int);
+static int
+parse_vc_action_prog_arg_value(struct context *, const struct token *,
+  const char *, unsigned int, void *,
+  unsigned int);
 static int comp_none(struct context *, const struct token *,
 unsigned int, char *, unsigned int);
 static int comp_boolean(struct context *, const struct token *,
@@ -7543,6 +7587,48 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_tx_queue,
tx_queue)),
},
+   [ACTION_PROG] = {
+   .name = "prog",
+   .help = "match a programmable action",
+   .priv = PRIV_ACTION(PROG, sizeof(struct action_prog_data)),
+   .next = NEXT(action_prog),
+   .call = parse_vc_action_prog,
+   },
+   [ACTION_PROG_NAME] = {
+   .name = "name",
+   .help = "programble action name",
+   .next = NEXT(action_prog, NEXT_ENTRY(ACTION_PROG_NAME_STRING)),
+   .args = ARGS(ARGS_ENTRY(struct action_prog_data, data.name)),
+   },
+   [ACTION_PROG_NAME_STRING] = {
+   .name = "{string}",
+   .type = "STRING",
+   .help = "programmable action name string",
+   .call = parse_string0,
+   },
+   [ACTION_PROG_ARGUMENTS] = {
+   .name = "arguments",
+   .help = "programmable action name",
+   .next = NEXT(action_prog, NEXT_ENTRY(ACTION_PROG_ARG_NA

[PATCH v6] app/testpmd: enable cli for programmable action

[Qi Zhang]

Parsing command line for rte_flow_action_prog.

Syntax:

"prog name  [arguments   \
   ... end]"

Use parse_string0 to parse name string.
Use parse_hex to parse hex string.
Use struct action_prog_data to store parsed result.

Example:

Action with 2 arguments:

"prog name action0 arguments field0 03FF field1 55AA end"

Action without argument:

"prog name action1"

Signed-off-by: Qi Zhang 
---
v6:
- fix typo.

v5:
- complete testpmd document.

v4:
- be more generous on the max size of name and value.

v3:
- refine struct action_prog_data
- enlarge the max size

v2:
- fix title
- minor coding style refine.

 app/test-pmd/cmdline_flow.c | 232 
 doc/guides/testpmd_app_ug/testpmd_funcs.rst |  17 ++
 2 files changed, 249 insertions(+)

diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 70eef3e34d..d9152f9485 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -721,6 +721,13 @@ enum index {
ACTION_IPV6_EXT_PUSH,
ACTION_IPV6_EXT_PUSH_INDEX,
ACTION_IPV6_EXT_PUSH_INDEX_VALUE,
+   ACTION_PROG,
+   ACTION_PROG_NAME,
+   ACTION_PROG_NAME_STRING,
+   ACTION_PROG_ARGUMENTS,
+   ACTION_PROG_ARG_NAME,
+   ACTION_PROG_ARG_VALUE,
+   ACTION_PROG_ARG_END,
 };
 
 /** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -751,6 +758,23 @@ struct action_rss_data {
uint16_t queue[ACTION_RSS_QUEUE_NUM];
 };
 
+#define ACTION_PROG_NAME_SIZE_MAX 256
+#define ACTION_PROG_ARG_NUM_MAX 16
+#define ACTION_PROG_ARG_VALUE_SIZE_MAX 64
+
+/** Storage for struct rte_flow_action_prog including external data. */
+struct action_prog_data {
+   struct rte_flow_action_prog conf;
+   struct {
+   char name[ACTION_PROG_NAME_SIZE_MAX];
+   struct rte_flow_action_prog_argument 
args[ACTION_PROG_ARG_NUM_MAX];
+   struct {
+   char names[ACTION_PROG_NAME_SIZE_MAX];
+   uint8_t value[ACTION_PROG_ARG_VALUE_SIZE_MAX];
+   } arg_data[ACTION_PROG_ARG_NUM_MAX];
+   } data;
+};
+
 /** Maximum data size in struct rte_flow_action_raw_encap. */
 #define ACTION_RAW_ENCAP_MAX_DATA 512
 #define RAW_ENCAP_CONFS_MAX_NUM 8
@@ -2178,6 +2202,7 @@ static const enum index next_action[] = {
ACTION_QUOTA_QU,
ACTION_IPV6_EXT_REMOVE,
ACTION_IPV6_EXT_PUSH,
+   ACTION_PROG,
ZERO,
 };
 
@@ -2519,6 +2544,13 @@ static const enum index action_represented_port[] = {
ZERO,
 };
 
+static const enum index action_prog[] = {
+   ACTION_PROG_NAME,
+   ACTION_PROG_ARGUMENTS,
+   ACTION_NEXT,
+   ZERO,
+};
+
 static int parse_set_raw_encap_decap(struct context *, const struct token *,
 const char *, unsigned int,
 void *, unsigned int);
@@ -2795,6 +2827,18 @@ static int
 parse_qu_mode_name(struct context *ctx, const struct token *token,
   const char *str, unsigned int len, void *buf,
   unsigned int size);
+static int
+parse_vc_action_prog(struct context *, const struct token *,
+const char *, unsigned int, void *,
+unsigned int);
+static int
+parse_vc_action_prog_arg_name(struct context *, const struct token *,
+ const char *, unsigned int, void *,
+ unsigned int);
+static int
+parse_vc_action_prog_arg_value(struct context *, const struct token *,
+  const char *, unsigned int, void *,
+  unsigned int);
 static int comp_none(struct context *, const struct token *,
 unsigned int, char *, unsigned int);
 static int comp_boolean(struct context *, const struct token *,
@@ -7543,6 +7587,48 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_tx_queue,
tx_queue)),
},
+   [ACTION_PROG] = {
+   .name = "prog",
+   .help = "match a programmable action",
+   .priv = PRIV_ACTION(PROG, sizeof(struct action_prog_data)),
+   .next = NEXT(action_prog),
+   .call = parse_vc_action_prog,
+   },
+   [ACTION_PROG_NAME] = {
+   .name = "name",
+   .help = "programble action name",
+   .next = NEXT(action_prog, NEXT_ENTRY(ACTION_PROG_NAME_STRING)),
+   .args = ARGS(ARGS_ENTRY(struct action_prog_data, data.name)),
+   },
+   [ACTION_PROG_NAME_STRING] = {
+   .name = "{string}",
+   .type = "STRING",
+   .help = "programmable action name string",
+   .call = parse_string0,
+   },
+   [ACTION_PROG_ARGUMENTS] = {
+   .name = "arguments",
+   .help = "programmable action name",
+   .next = NEXT(action_prog, NEXT_ENTRY(A

[PATCH] doc: update matching versions for idpf and cpfl

[beilei . xing]

From: Beilei Xing 

Update recommended matching list for idpf PMD and cpfl PMD.

Signed-off-by: Beilei Xing 
---
 doc/guides/nics/cpfl.rst | 2 ++
 doc/guides/nics/idpf.rst | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/doc/guides/nics/cpfl.rst b/doc/guides/nics/cpfl.rst
index ae5487f2f6..54db6e3c8f 100644
--- a/doc/guides/nics/cpfl.rst
+++ b/doc/guides/nics/cpfl.rst
@@ -33,6 +33,8 @@ Here is the suggested matching list which has been tested and 
verified.
++==+
|23.07   |  0.9.1   |
++--+
+   |23.11   |   1.0|
+   ++--+
 
 
 Configuration
diff --git a/doc/guides/nics/idpf.rst b/doc/guides/nics/idpf.rst
index c55f81fb24..c2e786056f 100644
--- a/doc/guides/nics/idpf.rst
+++ b/doc/guides/nics/idpf.rst
@@ -31,6 +31,8 @@ Here is the suggested matching list which has been tested and 
verified.
++===+==+
|23.07   |0.0.710|  0.9.1   |
++---+--+
+   |23.11   |0.0.720|   1.0|
+   ++---+--+
 
 
 Configuration
-- 
2.34.1

Re: [PATCH v6 2/3] test: add dispatcher test suite

[Mattias Rönnblom]

On 2023-10-10 13:56, David Marchand wrote:

On Mon, Oct 9, 2023 at 8:22 PM Mattias Rönnblom
 wrote:

+static int
+test_dispatcher(void)
+{
+   return unit_test_suite_runner(&test_suite);
+}
+
+REGISTER_FAST_TEST(dispatcher_autotest, false, true, test_dispatcher);


Since this test expects some lcores, wdyt of adding:

@@ -1044,6 +1044,12 @@ static struct unit_test_suite test_suite = {
  static int
  test_dispatcher(void)
  {
+   if (rte_lcore_count() < NUM_SERVICE_CORES + 1) {
+   printf("Not enough cores for dispatcher_autotest,
expecting at least %u\n",
+   NUM_SERVICE_CORES + 1);
+   return TEST_SKIPPED;
+   }
+
 return unit_test_suite_runner(&test_suite);
  }

This should avoid the failures we get with some CI env.
(additionnally, I tested this on my laptop and the test runs fine)




Indeed, this is a much better way than to fail the test case.

I'm thinking this is best done in test_setup(), since it's related to 
the setup. In case other test cases are added that required a different 
setup, there may be no minimum lcore requirement.


You will get multiple (four, for the moment) print-outs though, in case 
you run with fewer than 4 lcores.


I'll also make sure I skip (and not fail) the tests in case the DSW 
event device is not included in the build.

[PATCH] net/mlx5: fix wrong decap action checking in sample flow

[Jiawei Wang]

This patch uses the temp variable to check the current action type,
to avoid overlap  the sample action following the decap.

Fixes: 7356aec64c48 ("net/mlx5: fix mirror flow split with L3 encapsulation")
Cc: sta...@dpdk.org

Signed-off-by: Jiawei Wang 
Acked-by: Suanming Mou 
---
 drivers/net/mlx5/mlx5_flow.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 8ad85e6027..772f6afb66 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -6159,6 +6159,7 @@ flow_check_match_action(const struct rte_flow_action 
actions[],
 {
const struct rte_flow_action_sample *sample;
const struct rte_flow_action_raw_decap *decap;
+   const struct rte_flow_action *action_cur = NULL;
int actions_n = 0;
uint32_t ratio = 0;
int sub_type = 0;
@@ -6219,12 +6220,12 @@ flow_check_match_action(const struct rte_flow_action 
actions[],
break;
case RTE_FLOW_ACTION_TYPE_RAW_DECAP:
decap = actions->conf;
-   while ((++actions)->type == RTE_FLOW_ACTION_TYPE_VOID)
+   action_cur = actions;
+   while ((++action_cur)->type == 
RTE_FLOW_ACTION_TYPE_VOID)
;
-   actions_n++;
-   if (actions->type == RTE_FLOW_ACTION_TYPE_RAW_ENCAP) {
+   if (action_cur->type == RTE_FLOW_ACTION_TYPE_RAW_ENCAP) 
{
const struct rte_flow_action_raw_encap *encap =
-   actions->conf;
+   
action_cur->conf;
if (decap->size <=
MLX5_ENCAPSULATION_DECISION_SIZE &&
encap->size >
-- 
2.18.1

Re: [PATCH v6 3/3] doc: add dispatcher programming guide

[Mattias Rönnblom]

On 2023-10-10 15:31, David Marchand wrote:

On Mon, Oct 9, 2023 at 8:23 PM Mattias Rönnblom
 wrote:

[snip]


+A module may use more than one event handler, for convenience or to
+further decouple sub-modules. However, the dispatcher may impose an
+upper limit of the number handlers. In addition, installing a large
+number of handlers increase dispatcher overhead, although this does
+not nessarily translate to a system-level performance degradation. See


necessarily*



Will fix.


[snip]


+Event Clustering
+
+
+The dispatcher maintains the order of events destined for the same
+handler.
+
+*Order* here refers to the order in which the events were delivered
+from the event device to the dispatcher (i.e., in the event array
+populated by ``rte_event_dequeue_burst()``), in relation to the order
+in which the dispatcher deliveres these events to the application.
+
+The dispatcher *does not* guarantee to maintain the order of events
+delivered to *different* handlers.
+
+For example, assume that ``MODULE_A_QUEUE_ID`` expands to the value 0,
+and ``MODULE_B_STAGE_0_QUEUE_ID`` expands to the value 1. Then
+consider a scenario where the following events are dequeued from the
+event device (qid is short for event queue id).
+
+.. code-block::


Surprisingly, Ubuntu in GHA sphinx complains about this code-block
directive while generating on my Fedora runs fine...

FAILED: doc/guides/html
/usr/bin/python3 ../buildtools/call-sphinx-build.py
/usr/bin/sphinx-build 23.11.0-rc0
/home/runner/work/dpdk/dpdk/doc/guides
/home/runner/work/dpdk/dpdk/build/doc/guides -a -W

Warning, treated as error:
/home/runner/work/dpdk/dpdk/doc/guides/prog_guide/dispatcher_lib.rst:253:Error
in "code-block" directive:
1 argument(s) required, 0 supplied.

.. code-block::

 [e0: qid=1], [e1: qid=1], [e2: qid=0], [e3: qid=1]

Looking at 
https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-code-block,
I suspect there is probably a difference in the default settings of
sphinx in those Ubuntu containers.

This is pseudo-code / close to C, so we could probably mark this block
as "C", but "none" works fine too.
WDYT?




I'm also running Ubuntu, and thus didn't experience this issue.

"none" seems better to me, to avoid potential future failures of syntax 
highlighting.


Thanks!

[PATCH] net/mlx5: support no host PF configuration

[Jiawei Wang]

From: Xueming Li 

In BlueField, a new firmware configuration option NUM_OF_PF=0 disables
PF on the x86 host side, no HPF on the ARM side, and the only RDMA port
on the ARM side is the bonding device(PF0). A device probe with devargs
of representor=pf[0-1]vf[...] will probe PF0 and PF1 one by one, and
it's possible that PF1 device scan results in no switch ports.

This patch supports the new configuration by allowing a PF scan with
empty switch ports.

Signed-off-by: Xueming Li 
Signed-off-by: Jiawei Wang 
---
 drivers/net/mlx5/linux/mlx5_os.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
index d5ef695e6d..75f53ade8e 100644
--- a/drivers/net/mlx5/linux/mlx5_os.c
+++ b/drivers/net/mlx5/linux/mlx5_os.c
@@ -2195,13 +2195,6 @@ mlx5_os_pci_probe_pf(struct mlx5_common_device *cdev,
 list[ns].info.master))
ns++;
}
-   if (!ns) {
-   DRV_LOG(ERR,
-   "Unable to recognize master/representors on the 
IB device with multiple ports.");
-   rte_errno = ENOENT;
-   ret = -rte_errno;
-   goto exit;
-   }
} else {
/*
 * The existence of several matching entries (nd > 1) means
-- 
2.18.1

[PATCH] net/mlx5: fix the E-Switch mirror flow rule validation

[Jiawei Wang]

The port action and jump to flow table action are not supported
in the mirror flows (RTE_FLOW_ACTION_TYPE_SAMPLE with sample ratio=1)
in E-Switch domain (transfer attribute set) without presented encap
action.

The encap action is supported for uplink port only. So, if flow with
mirroring contains  encap action application should provide encap
and uplink port actions in the mirror action list and PMD validates
this condition (to make sure we cover the hardware limitation).

This patch adds the validation for E-Switch mirror flow rule checking
and rejects as invalid.

Fixes: 6a951567c159 ("net/mlx5: support E-Switch mirroring and jump in one 
flow")
Cc: sta...@dpdk.org

Signed-off-by: Jiawei Wang 
---
 doc/guides/nics/mlx5.rst|  5 ++
 drivers/net/mlx5/mlx5_flow_dv.c | 93 +
 2 files changed, 76 insertions(+), 22 deletions(-)

diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 7bee57d9dd..16c322578a 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5.rst
@@ -545,6 +545,11 @@ Limitations
 sample actions list.
   - For E-Switch mirroring flow, supports ``RAW ENCAP``, ``Port ID``,
 ``VXLAN ENCAP``, ``NVGRE ENCAP`` in the sample actions list.
+  - For E-Switch mirroring flow with sample ratio = 1, the ``ENCAP`` action
+support for uplink port only.
+  - For E-Switch mirroring flow with sample ratio = 1, the ``PORT`` action and
+``JUMP`` action are not supported without presented ``ENCAP`` action in the
+sample actions list.
   - For ConnectX-5 trusted device, the application metadata with SET_TAG index 0
 is not supported before ``RTE_FLOW_ACTION_TYPE_SAMPLE`` action.
 
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 3dc2fe5c71..8c9a00ef85 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -6029,6 +6029,7 @@ flow_dv_modify_clone_free_cb(void *tool_ctx, struct 
mlx5_list_entry *entry)
  */
 static int
 flow_dv_validate_action_sample(uint64_t *action_flags,
+  uint64_t *sub_action_flags,
   const struct rte_flow_action *action,
   struct rte_eth_dev *dev,
   const struct rte_flow_attr *attr,
@@ -6037,14 +6038,15 @@ flow_dv_validate_action_sample(uint64_t *action_flags,
   const struct rte_flow_action_rss **sample_rss,
   const struct rte_flow_action_count **count,
   int *fdb_mirror,
+  uint16_t *sample_port_id,
   bool root,
   struct rte_flow_error *error)
 {
struct mlx5_priv *priv = dev->data->dev_private;
struct mlx5_sh_config *dev_conf = &priv->sh->config;
const struct rte_flow_action_sample *sample = action->conf;
+   const struct rte_flow_action_port_id *port = NULL;
const struct rte_flow_action *act;
-   uint64_t sub_action_flags = 0;
uint16_t queue_index = 0x;
int actions_n = 0;
int ret;
@@ -6091,20 +6093,20 @@ flow_dv_validate_action_sample(uint64_t *action_flags,
switch (act->type) {
case RTE_FLOW_ACTION_TYPE_QUEUE:
ret = mlx5_flow_validate_action_queue(act,
- sub_action_flags,
+ *sub_action_flags,
  dev,
  attr, error);
if (ret < 0)
return ret;
queue_index = ((const struct rte_flow_action_queue *)
(act->conf))->index;
-   sub_action_flags |= MLX5_FLOW_ACTION_QUEUE;
+   *sub_action_flags |= MLX5_FLOW_ACTION_QUEUE;
++actions_n;
break;
case RTE_FLOW_ACTION_TYPE_RSS:
*sample_rss = act->conf;
ret = mlx5_flow_validate_action_rss(act,
-   sub_action_flags,
+   *sub_action_flags,
dev, attr,
item_flags,
error);
@@ -6120,48 +6122,57 @@ flow_dv_validate_action_sample(uint64_t *action_flags,
"or level in the same flow");
if (*sample_rss != NULL && (*sample_rss)->queue_num)
queue_index = (*sample_rss)->queue[0];
-   sub_action_flags |= 

Re: [PATCH v6 2/3] test: add dispatcher test suite

[Mattias Rönnblom]

On 2023-10-10 16:02, David Marchand wrote:

On Mon, Oct 9, 2023 at 8:22 PM Mattias Rönnblom
 wrote:


Add unit tests for the dispatcher.


Fyi, this patch is the first external user of rte_event_maintain and
it revealed an issue:
http://mails.dpdk.org/archives/test-report/2023-October/475671.html



"External" as in calling it over a shared object boundary.


I sent a fix, can you have a look?


Will do.


https://patchwork.dpdk.org/project/dpdk/patch/20231010140029.66159-1-david.march...@redhat.com/

Thanks.

Re: [PATCH] eventdev: fix symbol export for port maintenance

[Mattias Rönnblom]

On 2023-10-10 16:00, David Marchand wrote:

Trying to call rte_event_maintain out of the eventdev library triggers
a link failure, as the tracepoint symbol associated to this inline
helper was not exported.

Fixes: 54f17843a887 ("eventdev: add port maintenance API")
Cc: sta...@dpdk.org

Signed-off-by: David Marchand 
---
Caught by the CI when testing the dispatcher library.
See for example:
https://github.com/ovsrobot/dpdk/actions/runs/6460514355/job/17538348529#step:19:5506

---
  lib/eventdev/version.map | 1 +
  1 file changed, 1 insertion(+)

diff --git a/lib/eventdev/version.map b/lib/eventdev/version.map
index b03c10d99f..249eb115b1 100644
--- a/lib/eventdev/version.map
+++ b/lib/eventdev/version.map
@@ -5,6 +5,7 @@ DPDK_24 {
__rte_eventdev_trace_deq_burst;
__rte_eventdev_trace_enq_burst;
__rte_eventdev_trace_eth_tx_adapter_enqueue;
+   __rte_eventdev_trace_maintain;
__rte_eventdev_trace_timer_arm_burst;
__rte_eventdev_trace_timer_arm_tmo_tick_burst;
__rte_eventdev_trace_timer_cancel_burst;


I can't say I know why it's needed, but the change seems consistent with 
other Eventdev trace points.


Maybe Jerin can comment on this? If not, I can dig into the details.

Re: [PATCH] eventdev: fix symbol export for port maintenance

[Jerin Jacob]

On Tue, Oct 10, 2023 at 7:30 PM David Marchand
 wrote:
>
> Trying to call rte_event_maintain out of the eventdev library triggers
> a link failure, as the tracepoint symbol associated to this inline
> helper was not exported.
>
> Fixes: 54f17843a887 ("eventdev: add port maintenance API")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand 

Acked-by: Jerin Jacob 

David, If it is stopping dispatcher library integration, please take
this patch through main tree, if not, I will add through event tree
for rc2.


> ---
> Caught by the CI when testing the dispatcher library.
> See for example:
> https://github.com/ovsrobot/dpdk/actions/runs/6460514355/job/17538348529#step:19:5506
>
> ---
>  lib/eventdev/version.map | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/lib/eventdev/version.map b/lib/eventdev/version.map
> index b03c10d99f..249eb115b1 100644
> --- a/lib/eventdev/version.map
> +++ b/lib/eventdev/version.map
> @@ -5,6 +5,7 @@ DPDK_24 {
> __rte_eventdev_trace_deq_burst;
> __rte_eventdev_trace_enq_burst;
> __rte_eventdev_trace_eth_tx_adapter_enqueue;
> +   __rte_eventdev_trace_maintain;
> __rte_eventdev_trace_timer_arm_burst;
> __rte_eventdev_trace_timer_arm_tmo_tick_burst;
> __rte_eventdev_trace_timer_cancel_burst;
> --
> 2.41.0
>