[PATCH] eal: introduce missing rte_thread wrappers

[David Vodak]

Function rte_ctrl_thread_create has been replaced by rte_thread_create_control,
encouraging Linux users to switch from the pthread_t API to the rte_thread API.
However the rte_thread API does not provide wrappers for all pthread functions.
This commit introduces equivalent functions for pthread_timedjoin_np,
pthread_getname_np and pthread_cancel.

Bugzilla ID: 1330
---
 lib/eal/include/rte_thread.h | 49 
 lib/eal/unix/rte_thread.c| 20 +++
 lib/eal/version.map  |  3 +++
 3 files changed, 72 insertions(+)

diff --git a/lib/eal/include/rte_thread.h b/lib/eal/include/rte_thread.h
index 8da9d4d3fb..49a068eda7 100644
--- a/lib/eal/include/rte_thread.h
+++ b/lib/eal/include/rte_thread.h
@@ -463,6 +463,55 @@ int rte_thread_value_set(rte_thread_key key, const void 
*value);
  */
 void *rte_thread_value_get(rte_thread_key key);
 
+/**
+ * Try to join with a terminated thread. If thread has not yet terminated,
+ * then the call blocks until a maximum time, specified in abstime.
+ *
+ * @param thread_id
+ *   Id of the thread.
+ *
+ * @param retval
+ *   Exit status of the thread.
+ *
+ * @param abstime
+ *   Maximum time of call blocking, measured against the CLOCK_REALTIME clock.
+ *
+ * @return
+ *   On success, return 0.
+ *   On failure, return a positive errno-style error number.
+ */
+int rte_thread_timedjoin_np(rte_thread_t thread_id, void **retval, const 
struct timespec *abstime);
+
+/**
+ * Get name of the thread.
+ *
+ * @param thread_id
+ *   Id of the thread.
+ *
+ * @param name
+ *   Name of the thread.
+ *
+ * @param size
+ *   The number of bytes available in name.
+ *
+ * @return
+ *   On success, return 0.
+ *   On failure, return a positive errno-style error number.
+ */
+int rte_thread_getname_np(rte_thread_t thread_id, char name[], size_t size);
+
+/**
+ * Send a cancelation request to a thread.
+ *
+ * @param thread_id
+ *   Id of the thread.
+ *
+ * @return
+ *   On success, return 0.
+ *   On failure, return a positive errno-style error number.
+ */
+int rte_thread_cancel(rte_thread_t thread_id);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/eal/unix/rte_thread.c b/lib/eal/unix/rte_thread.c
index 36a21ab2f9..79986bee6a 100644
--- a/lib/eal/unix/rte_thread.c
+++ b/lib/eal/unix/rte_thread.c
@@ -378,3 +378,23 @@ rte_thread_get_affinity_by_id(rte_thread_t thread_id,
return pthread_getaffinity_np((pthread_t)thread_id.opaque_id,
sizeof(*cpuset), cpuset);
 }
+
+int
+rte_thread_timedjoin_np(rte_thread_t thread_id, void **retval,
+   const struct timespec *abstime)
+{
+   return pthread_timedjoin_np((pthread_t) thread_id.opaque_id, retval,
+   abstime);
+}
+
+int
+rte_thread_getname_np(rte_thread_t thread_id, char name[], size_t size)
+{
+   return pthread_getname_np((pthread_t) thread_id.opaque_id, name, size);
+}
+
+int
+rte_thread_cancel(rte_thread_t thread_id)
+{
+   return pthread_cancel((pthread_t) thread_id.opaque_id);
+}
diff --git a/lib/eal/version.map b/lib/eal/version.map
index 5e0cd47c82..66ac45b7de 100644
--- a/lib/eal/version.map
+++ b/lib/eal/version.map
@@ -310,6 +310,9 @@ DPDK_24 {
rte_thread_unregister;
rte_thread_value_get;
rte_thread_value_set;
+   rte_thread_timedjoin_np; # WINDOWS_NO_EXPORT
+   rte_thread_getname_np; # WINDOWS_NO_EXPORT
+   rte_thread_cancel; # WINDOWS_NO_EXPORT
rte_uuid_compare;
rte_uuid_is_null;
rte_uuid_parse;
-- 
2.43.0

Re: DPDK Release Status Meeting 2023-11-23

[Thomas Monjalon]

27/11/2023 03:51, Ruifeng Wang:
> On 2023/11/26 8:44 PM, Luca Boccassi wrote:
> > On Sun, 26 Nov 2023 at 01:55, Ruifeng Wang  wrote:
> >> On 2023/11/24 4:53 PM, Mcnamara, John wrote:
> >>> Release status meeting minutes 2023-11-23
> >>>   * LCOREs autotest timing out on ARM:
> >>>
> >>>
> >>> https://build.opensuse.org/package/live_build_log/home:bluca:dpdk/dpdk/Debian_12/aarch64
> >>
> >> The failure relates to test environment. 50s is not enough for lcores
> >> test to finish.
> >>
> >> Due to a relative bigger RTE_MAX_LCORE value on ARM, the unit test case
> >> would take a longer time to finish iterations.
> >> In one of my run, the case took about 100s.
> > 
> > Right, but this test is part of the "fast suite", and more than a
> > minute is not exactly fast. So one of the following should ideally
> > happen:
> 
> Agree.
> 
> > 1) Test is moved out of the fast suite
> > 2) Test has its individual timeout sized appropriately so that it
> > never fails regardless of the environment
> > 3) Test is capped so that it doesn't grow with the number of cores
> > without limits
> 
> I'm for option 3. The case should be kept in fast suite. Time taken 
> should be capped.

More than 1 second is a bit slow.
Please make the test really faster.

Re: net/virtio: duplicated xstats

[Ferruh Yigit]

On 11/24/2023 9:18 AM, Edwin Brossette wrote:
> Hello,
> 
> I noticed a small inconsistency in the virtio pmd's xstats.
> The stat "rx_q0_errors" appears twice.
> I also think the stats "rx_q0_packets", "rx_q0_bytes", "tx_q0_packets"
> and "tx_q0_bytes" are duplicates of "rx_q0_good_packets",
> "rx_q0_good_bytes", "tx_q0_good_packets" and "tx_q0_good_bytes"
> 

Ack, I didn't reproduce but from code I can see this inconsistency can
occur.


> I believe this issue probably appeared after this commit:
> 
> f30e69b41f94: ethdev: add device flag to bypass auto-filled queue xstats
> http://scm.6wind.com/vendor/dpdk.org/dpdk/commit/?id=f30e69b41f949cd4a9afb6ff39de196e661708e2
>  
> 
> 
> From what I understand, the rxq0_error stat was originally reported by
> the librte. However, changes were made so it is reported by the pmd instead.
> The flag RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS was temporarily set to keep
> the old behaviour so that every pmd could have time to adapt the change.
> But it seems the flag was forgotten in the virtio pmd and as a result,
> some stats are fetched at two different times when displaying xstats.
> 

Motivation is move queue stats from "basic stats" to "xstats".

'RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS' is a temporary flag, as you said,
and when driver sets it, ethdev layer copies queue stats from basic
stats to xstats.
In long term expectation is driver itself implement queue stats in
xstats and unset the flag, when all drivers implement this, flag will be
removed.


The issue with virtio is it already has queue stats in the xstats, with
the flag some queue stats duplicated.
It seems it is not forgotten to be removed, but it was mistake to add
flag at first place. So OK to remove the flag from virtio PMD.



> First in lib_rte_ethdev:
> https://git.dpdk.org/dpdk/tree/lib/ethdev/rte_ethdev.c#n3266
> 
> (you can see the check on the RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS flag
> before the snprintf on |eth_dev_rxq_stats_strings[]| )
> 
> And a second time in the virtio pmd:
> https://git.dpdk.org/dpdk/tree/drivers/net/virtio/virtio_ethdev.c#n705
>  pmd
> (see the snprintf on|rte_virtio_rxq_stat_strings|[] )
> 
> This problem can be reproduced on testpmd simply by displaying the
> xstats on a port with the net_virtio driver:
> 
> Reproduction:
> ===
> 
>     1) start dpdk-testpmd:
> 
> modprobe -a uio_pci_generic
> dpdk-devbind -b uio_pci_generic 03:00.0
> dpdk-devbind -b uio_pci_generic 04:00.0
> 
> dpdk-devbind -s
> 
> Network devices using DPDK-compatible driver
> 
> :03:00.0 'Virtio 1.0 network device 1041' drv=uio_pci_generic
> unused=vfio-pci
> :04:00.0 'Virtio 1.0 network device 1041' drv=uio_pci_generic
> unused=vfio-pci
> [...]
> 
> dpdk-testpmd -a :03:00.0 -a :04:00.0 -- -i --rxq=1 --txq=1
> --coremask=0x4 --total-num-mbufs=25
> EAL: Detected CPU lcores: 3
> EAL: Detected NUMA nodes: 1
> EAL: Detected static linkage of DPDK
> EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
> EAL: Selected IOVA mode 'PA'
> EAL: VFIO support initialized
> EAL: Probe PCI driver: net_virtio (1af4:1041) device: :03:00.0
> (socket -1)
> EAL: Probe PCI driver: net_virtio (1af4:1041) device: :04:00.0
> (socket -1)
> Interactive-mode selected
> Warning: NUMA should be configured manually by using --port-numa-config
> and --ring-numa-config parameters along with --numa.
> testpmd: create a new mbuf pool : n=25, size=2176, socket=0
> testpmd: preferred mempool ops selected: ring_mp_mc
> Configuring Port 0 (socket 0)
> Port 0: 52:54:00:B0:8F:88
> Configuring Port 1 (socket 0)
> Port 1: 52:54:00:EF:09:1F
> Checking link statuses...
> Done
> 
>     2) port info:
> 
> show port info 0
> 
> * Infos for port 0  *
> MAC address: 52:54:00:B0:8F:88
> Device name: :03:00.0
> Driver name: net_virtio
> Firmware-version: not available
> Devargs:
> Connect to socket: 0
> memory allocation on the socket: 0
> Link status: up
> Link speed: Unknown
> Link duplex: full-duplex
> Autoneg status: On
> MTU: 1500
> Promiscuous mode: enabled
> Allmulticast mode: disabled
> Maximum number of MAC addresses: 64
> Maximum number of MAC addresses of hash filtering: 0
> VLAN offload:
>   strip off, filter off, extend off, qinq strip off
> No RSS offload flow type is supported.
> Minimum size of RX buffer: 64
> Maximum configurable length of RX packet: 9728
> Maximum configurable size of LRO aggregated packet: 0
> Current number of RX queues: 1
> Max possible RX queues: 1
> Max possible number of RXDs per queue: 32768
> Min possible number of RXDs per queue: 32
> RXDs number alignment: 1
> Current number of TX queues: 1
> Max possible TX queues: 1
> Max possible number of TXDs per queue: 32768

Re: [PATCH] net/virtio: fix duplicated rxq xstats

[Ferruh Yigit]

On 11/24/2023 1:52 PM, edwin.brosse...@6wind.com wrote:
> From: Edwin Brossette 
> 
> The flag RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS was temporarily set while
> moving queue stats from 'struct rte_eth_stats' to the individual pmds,
> as explained in commit f30e69b41f94 ("ethdev: add device flag to bypass
> auto-filled queue xstats").
> 
> This flag was added so every pmd would keep its original behavior until
> the change was implemented. However, this flag was not removed
> afterwards in the virtio pmd and as a result, some queue stats are
> displayed twice when trying to get them: once in lib_rte_ethdev, and a
> second time in the virtio pmd.
> 
> Remove this flag so stats are printed only once.
> 
> Fixes: f30e69b41f94 ("ethdev: add device flag to bypass auto-filled queue 
> xstats")
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Edwin Brossette 
> 

Reviewed-by: Ferruh Yigit 

Re: net/virtio: duplicated xstats

[Ferruh Yigit]

On 11/27/2023 10:19 AM, Ferruh Yigit wrote:
> On 11/24/2023 9:18 AM, Edwin Brossette wrote:
>> Hello,
>>
>> I noticed a small inconsistency in the virtio pmd's xstats.
>> The stat "rx_q0_errors" appears twice.
>> I also think the stats "rx_q0_packets", "rx_q0_bytes", "tx_q0_packets"
>> and "tx_q0_bytes" are duplicates of "rx_q0_good_packets",
>> "rx_q0_good_bytes", "tx_q0_good_packets" and "tx_q0_good_bytes"
>>
> 
> Ack, I didn't reproduce but from code I can see this inconsistency can
> occur.
> 
> 
>> I believe this issue probably appeared after this commit:
>>
>> f30e69b41f94: ethdev: add device flag to bypass auto-filled queue xstats
>> http://scm.6wind.com/vendor/dpdk.org/dpdk/commit/?id=f30e69b41f949cd4a9afb6ff39de196e661708e2
>>  
>> 
>>
>> From what I understand, the rxq0_error stat was originally reported by
>> the librte. However, changes were made so it is reported by the pmd instead.
>> The flag RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS was temporarily set to keep
>> the old behaviour so that every pmd could have time to adapt the change.
>> But it seems the flag was forgotten in the virtio pmd and as a result,
>> some stats are fetched at two different times when displaying xstats.
>>
> 
> Motivation is move queue stats from "basic stats" to "xstats".
> 
> 'RTE_ETH_DEV_AUTOFILL_QUEUE_XSTATS' is a temporary flag, as you said,
> and when driver sets it, ethdev layer copies queue stats from basic
> stats to xstats.
> In long term expectation is driver itself implement queue stats in
> xstats and unset the flag, when all drivers implement this, flag will be
> removed.
> 
> 
> The issue with virtio is it already has queue stats in the xstats, with
> the flag some queue stats duplicated.
> It seems it is not forgotten to be removed, but it was mistake to add
> flag at first place. So OK to remove the flag from virtio PMD.
> 

Fixed Maxime's email.

Re: [PATCH] lib/ethdev: modified the definition of 'NVGRE_ENCAP'

[Ferruh Yigit]

On 11/24/2023 1:36 PM, David Marchand wrote:
> On Fri, Nov 24, 2023 at 4:31 AM Sunyang Wu  wrote:
>>
>> Fix the issue of incorrect definition of 'NVGRE_ENCAP', and
>> modified the error comments of 'rte_flow_action_nvgre_encap'.
>>
>> Fixes: c2beb1d ("ethdev: add missing items/actions to flow object converter")
>> Fixes: 3850cf0 ("ethdev: add tunnel encap/decap actions")
> 
> Please use the format for Fixes tag described in the contributing guide.
> 
> Fixes: c2beb1d469d2 ("ethdev: add missing items/actions to flow object
> converter")
> Fixes: 3850cf0c8c37 ("ethdev: add tunnel encap/decap actions")
> 
>> Cc: sta...@dpdk.org
> 
> Copying more maintainers.
> Apart from readability, I think this patch does not fix any real bug, does it?
> 

It is a genuine fix, that used struct was wrong, but as size of both
structs are same, practically functionality should be same.

I think risk is low with this patch and we can get it even at this stage
of release, but also it is safe to postpone it to next release. I leave
decision to David.


Reviewed-by: Ferruh Yigit 

>>
>> Signed-off-by: Joey Xing 
>> Signed-off-by: Sunyang Wu 
> 
> 

Re: [PATCH] doc: clarify mirroring limitations in mlx5 guide

[Thomas Monjalon]

07/11/2023 16:10, Jiawei Wang:
> Update the description of flow mirroring to make clear
> what are the limitations of the mlx5 driver.
> 
> Signed-off-by: Jiawei Wang 
> Acked-by: Thomas Monjalon 

Applied, thanks.

Re: [PATCH] doc/mlx4: set limitation for RSS

[Thomas Monjalon]

19/11/2023 14:24, Raslan Darawsheh:
> This adds a limitation explanation on RSS queue usage
> for MLX4 pmd.
> 
> MLX4 pmd requires a power of two queues to do RSS
> but, the user can still open more queues which can be utilized
> through flow API.
> 
> Signed-off-by: Raslan Darawsheh 

Applied with few indent fixes, thanks.

Re: [PATCH v3 1/6] doc: add RSS hash algorithm feature

[Ferruh Yigit]

On 11/25/2023 1:47 AM, Huisong Li wrote:
> Add hash algorithm feature introduced by 23.11 and fix some RSS features
> description.
> 
> Fixes: 34ff088cc241 ("ethdev: set and query RSS hash algorithm")
> 
> Signed-off-by: Huisong Li 
> Acked-by: Chengwen Feng 
> ---
>  doc/guides/nics/features.rst | 26 ++
>  1 file changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
> index 1a1dc16c1e..0d38c5c525 100644
> --- a/doc/guides/nics/features.rst
> +++ b/doc/guides/nics/features.rst
> @@ -277,10 +277,12 @@ RSS hash
>  Supports RSS hashing on RX.
>  
>  * **[uses] user config**: ``dev_conf.rxmode.mq_mode`` = 
> ``RTE_ETH_MQ_RX_RSS_FLAG``.
> -* **[uses] user config**: ``dev_conf.rx_adv_conf.rss_conf``.
> +* **[uses] user config**: ``rss_conf.rss_hf``.
>

Feature title is "RSS hash", it can be two things,
1. "Receive Side Scaling" support
2. Provide RSS hash to application

When this document first prepared RSS hash value was always provided to
the application when RSS enabled.
So intention with this feature was "Receive Side Scaling" support, hence
'RTE_ETH_MQ_RX_RSS_FLAG' added.

Later providing RSS has to the application separated as optimization,
'RTE_ETH_RX_OFFLOAD_RSS_HASH' & 'RTE_MBUF_F_RX_RSS_HASH' added for this
support.


As the intention of this feature is "Receive Side Scaling" support, we
shouldn't reduce configuration struct to 'rss_conf.rss_hf'.

Instead perhaps can expand to:
'rte_eth_conf.rx_adv_conf.rss_conf', 'rte_eth_rss_conf'



>  * **[uses] rte_eth_rxconf,rte_eth_rxmode**: 
> ``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
>  * **[provides] rte_eth_dev_info**: ``flow_type_rss_offloads``.
>  * **[provides] mbuf**: ``mbuf.ol_flags:RTE_MBUF_F_RX_RSS_HASH``, 
> ``mbuf.rss``.
> +* **[related]  API**: ``rte_eth_dev_configure``, 
> ``rte_eth_dev_rss_hash_update``
> +  ``rte_eth_dev_rss_hash_conf_get()``.
>  

ack

>  
>  .. _nic_features_inner_rss:
> @@ -288,7 +290,7 @@ Supports RSS hashing on RX.
>  Inner RSS
>  -
>  
> -Supports RX RSS hashing on Inner headers.
> +Supports RX RSS hashing on Inner headers by rte_flow API.
>  

This should be clarified with details below, not sure if it required to
limit description to rte_flow.


And I guess similar confusion exist with the providing hash to user.
Need to check if rte_flow implementation puts hash to mbuf along with
doing the RSS, or if it checks 'RTE_ETH_RX_OFFLOAD_RSS_HASH' offload,
and update below items accordingly.


>  * **[uses]rte_flow_action_rss**: ``level``.
>  * **[uses]rte_eth_rxconf,rte_eth_rxmode**: 
> ``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
> @@ -303,9 +305,25 @@ RSS key update
>  Supports configuration of Receive Side Scaling (RSS) hash computation. 
> Updating
>  Receive Side Scaling (RSS) hash key.
>  
> -* **[implements] eth_dev_ops**: ``rss_hash_update``, ``rss_hash_conf_get``.
> +* **[implements] eth_dev_ops**: ``dev_configure``, ``rss_hash_update``, 
> ``rss_hash_conf_get``.
> +* **[uses] user config**: ``rss_conf.rss_key``, ``rss_conf.rss_key_len``
>  * **[provides]   rte_eth_dev_info**: ``hash_key_size``.
> -* **[related]API**: ``rte_eth_dev_rss_hash_update()``,
> +* **[related]API**: ``rte_eth_dev_configure``, 
> ``rte_eth_dev_rss_hash_update()``,
> +  ``rte_eth_dev_rss_hash_conf_get()``.
> +

ack

There is an inconsistency in the documentation but I think it is good to
use '()' when documenting API, like: 'rte_eth_dev_configure()'


> +
> +.. _nic_features_rss_hash_algo_update:
> +
> +RSS hash algorithm update
> +-
> +
> +Supports configuration of Receive Side Scaling (RSS) hash algorithm. Updating
> +RSS hash algorithm.
> +
> +* **[implements] eth_dev_ops**: ``dev_configure``, ``rss_hash_update``, 
> ``rss_hash_conf_get``.
> +* **[uses] user config**: ``rss_conf.algorithm``
> +* **[provides]   rte_eth_dev_info**: ``rss_algo_capa``.
> +* **[related]API**: ``rte_eth_dev_configure``, 
> ``rte_eth_dev_rss_hash_update()``,
>``rte_eth_dev_rss_hash_conf_get()``.
>  
>  


This document describes features listed in the 'default.ini', so we
shouldn't have above.

And I don't think RSS hash algorithm update is a big enough feature to
list in the feature list, perhaps it can be embedded in the RSS support
block, what do you think?

Re: [PATCH v3 2/6] doc: add link up/down feature

[Ferruh Yigit]

On 11/25/2023 1:47 AM, Huisong Li wrote:
> Add link up/down feature for features.rst.
> 
> Fixes: 915e67837586 ("ethdev: API for link up and down")
> Cc: sta...@dpdk.org
> 

Documentation is added after feature, so above fixes line is not correct.

I am not sure if this is fix, I think more like it is extending the
document.


With fixes line fix,
Acked-by: Ferruh Yigit 


> Signed-off-by: Huisong Li 
> Acked-by: Chengwen Feng 
> ---
>  doc/guides/nics/features.rst | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
> index 0d38c5c525..f14962a6c3 100644
> --- a/doc/guides/nics/features.rst
> +++ b/doc/guides/nics/features.rst
> @@ -45,6 +45,10 @@ Supports getting the link speed, duplex mode and link 
> state (up/down).
>  * **[implements] rte_eth_dev_data**: ``dev_link``.
>  * **[related]API**: ``rte_eth_link_get()``, 
> ``rte_eth_link_get_nowait()``.
>  
> +Set link up/down an Ethernet device.
> +
> +* **[implements] eth_dev_ops**: ``dev_set_link_up``, ``dev_set_link_down``.
> +* **[related]API**: ``rte_eth_dev_set_link_up()``, 
> ``rte_eth_dev_set_link_down()``.
>  
>  .. _nic_features_link_status_event:
>  

Re: [PATCH v3 0/6] doc/features: fix some features and add new features

[Ferruh Yigit]

On 11/25/2023 1:47 AM, Huisong Li wrote:
> The support for setting RSS hash algorithm has been introduced to 23.11,
> but doesn't add feature for it. So this series add this feature and perfect
> RSS other features by the way.
> 
> In addition, serval features, like "set link up/down", "TM", "dump device
> private information" and "loopback mode", had beed supported, but they are
> absent from the freatures list.
> 
> ---
>  -v3:
>- fix description of the patchset cover
>- remove '/features' in 'doc/features' tag for every patch.
>- add Acked-by: Chengwen Feng 
>- retrigger CI build because of wrong CI warning
> 
>  -v2:
>- add loopback mode feature.
> 
> Huisong Li (6):
>   doc: add RSS hash algorithm feature
>   doc: add link up/down feature
>   doc: add features for link speeds
>   doc: add Traffic Manager feature
>   doc: add dump device private information feature
>   doc: add feature for loopback mode
> 
>  

Hi Huisong,

Some of the patches above adds new features to the 'features.rst', but
features.rst document describes features that drivers mark in feature
list in .ini file, all features are listed in the 'default.ini'.

When a new feature is added into 'default.ini', it can be described in
'features.rst' and later all driver .ini files should be updated to
reflect if they support this feature or not.


And I think no need to document all features, but ones can be important
enough or differentiating features for users to know, this line is not
easy to draw, so perhaps we can use community consensus to select.

In this patch following features are added:
- Link speed configuration
- Traffic manager
- Device private information dump
- Loopback configuration


I think 'Traffic manager' can be a new feature, but I am not sure about
rest. It would be nice to get more comments.

[PATCH v2] net/mlx5: fix jump action validation

[Michael Baum]

Currently PMD doesn't allow to jump to the same group in order to
avoid dead loop. But this also prevent experienced user to create
flow with less Hops in order to have better performance.

For example, rules in [1] should have better performance then [2].

Furthermore, this protection will not really prevent dead loop, i.e
[3]. So just remove this protection and user should take the
responsibility to avoid dead loop.

This patch enables jumping to the same group.

[1]:
flow create 0 group 1 priority 1 pattern eth / ipv4 / udp / gtp / end
actions raw_decap / raw_encap / jump group 1 / end
flow create 0 group 1 priority 0 pattern eth / ipv4 src is 1.0.0.1 / tcp
/ end actions queues index 1 / end

[2]:
flow create 0 group 1 priority 0 pattern eth / ipv4 / udp / gtp / end
actions raw_decap / raw_encap / jump group 2 / end
flow create 0 group 2 priority 0 pattern eth / ipv4 src is 1.0.0.1 / tcp
/ end actions queues index 1 / end

[3]:
flow create 0 group 1 pattern eth / end actions jump group 2 / end
flow create 0 group 2 pattern eth / end actions jump group 1 / end

Fixes: f78f747f41d0 ("net/mlx5: allow jump to group lower than current")
Cc: dek...@mellanox.com
Cc: sta...@dpdk.org

Signed-off-by: Michael Baum 
Acked-by: Matan Azrad 
---

V2: change commit message to fix template.

 drivers/net/mlx5/mlx5_flow_dv.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 115d730317..5d0cb4278b 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -5484,13 +5484,6 @@ flow_dv_validate_action_jump(struct rte_eth_dev *dev,
   &grp_info, error);
if (ret)
return ret;
-   if (attributes->group == target_group &&
-   !(action_flags & (MLX5_FLOW_ACTION_TUNNEL_SET |
- MLX5_FLOW_ACTION_TUNNEL_MATCH)))
-   return rte_flow_error_set(error, EINVAL,
- RTE_FLOW_ERROR_TYPE_ACTION, NULL,
- "target group must be other than"
- " the current flow group");
if (table == 0)
return rte_flow_error_set(error, EINVAL,
  RTE_FLOW_ERROR_TYPE_ACTION_CONF,
-- 
2.25.1

Re: [PATCH v3 1/6] doc: add RSS hash algorithm feature

[lihuisong (C)]

在 2023/11/27 20:19, Ferruh Yigit 写道:

On 11/25/2023 1:47 AM, Huisong Li wrote:

Add hash algorithm feature introduced by 23.11 and fix some RSS features
description.

Fixes: 34ff088cc241 ("ethdev: set and query RSS hash algorithm")

Signed-off-by: Huisong Li 
Acked-by: Chengwen Feng 
---
  doc/guides/nics/features.rst | 26 ++
  1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 1a1dc16c1e..0d38c5c525 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -277,10 +277,12 @@ RSS hash
  Supports RSS hashing on RX.
  
  * **[uses] user config**: ``dev_conf.rxmode.mq_mode`` = ``RTE_ETH_MQ_RX_RSS_FLAG``.

-* **[uses] user config**: ``dev_conf.rx_adv_conf.rss_conf``.
+* **[uses] user config**: ``rss_conf.rss_hf``.


Feature title is "RSS hash", it can be two things,
1. "Receive Side Scaling" support
2. Provide RSS hash to application

When this document first prepared RSS hash value was always provided to
the application when RSS enabled.
So intention with this feature was "Receive Side Scaling" support, hence
'RTE_ETH_MQ_RX_RSS_FLAG' added.

Later providing RSS has to the application separated as optimization,
'RTE_ETH_RX_OFFLOAD_RSS_HASH' & 'RTE_MBUF_F_RX_RSS_HASH' added for this
support.

What should I do for above two comments？
To tell application how to use it?


As the intention of this feature is "Receive Side Scaling" support, we
shouldn't reduce configuration struct to 'rss_conf.rss_hf'.

Instead perhaps can expand to:
'rte_eth_conf.rx_adv_conf.rss_conf', 'rte_eth_rss_conf'


 I just pick their common part.😁

ok, will fix it.





  * **[uses] rte_eth_rxconf,rte_eth_rxmode**: 
``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
  * **[provides] rte_eth_dev_info**: ``flow_type_rss_offloads``.
  * **[provides] mbuf**: ``mbuf.ol_flags:RTE_MBUF_F_RX_RSS_HASH``, ``mbuf.rss``.
+* **[related]  API**: ``rte_eth_dev_configure``, 
``rte_eth_dev_rss_hash_update``
+  ``rte_eth_dev_rss_hash_conf_get()``.
  

ack

  
  .. _nic_features_inner_rss:

@@ -288,7 +290,7 @@ Supports RSS hashing on RX.
  Inner RSS
  -
  
-Supports RX RSS hashing on Inner headers.

+Supports RX RSS hashing on Inner headers by rte_flow API.
  

This should be clarified with details below, not sure if it required to
limit description to rte_flow.

But this block like rte_flow_action_rss is from rte_flow.
And ethdev ops doesn't support inner RSS.
So I think it is ok.



And I guess similar confusion exist with the providing hash to user.
Need to check if rte_flow implementation puts hash to mbuf along with
doing the RSS, or if it checks 'RTE_ETH_RX_OFFLOAD_RSS_HASH' offload,
and update below items accordingly.

Do we need to tell user how to use it here?
I feel this document is a little simple and main to list interface for user.
In addition, it is better that the more detail about RSS should be 
presented  in rte_flow features.




  * **[uses]rte_flow_action_rss**: ``level``.
  * **[uses]rte_eth_rxconf,rte_eth_rxmode**: 
``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
@@ -303,9 +305,25 @@ RSS key update
  Supports configuration of Receive Side Scaling (RSS) hash computation. 
Updating
  Receive Side Scaling (RSS) hash key.
  
-* **[implements] eth_dev_ops**: ``rss_hash_update``, ``rss_hash_conf_get``.

+* **[implements] eth_dev_ops**: ``dev_configure``, ``rss_hash_update``, 
``rss_hash_conf_get``.
+* **[uses] user config**: ``rss_conf.rss_key``, ``rss_conf.rss_key_len``
  * **[provides]   rte_eth_dev_info**: ``hash_key_size``.
-* **[related]API**: ``rte_eth_dev_rss_hash_update()``,
+* **[related]API**: ``rte_eth_dev_configure``, 
``rte_eth_dev_rss_hash_update()``,
+  ``rte_eth_dev_rss_hash_conf_get()``.
+

ack

There is an inconsistency in the documentation but I think it is good to
use '()' when documenting API, like: 'rte_eth_dev_configure()'

+1 will fix it.




+
+.. _nic_features_rss_hash_algo_update:
+
+RSS hash algorithm update
+-
+
+Supports configuration of Receive Side Scaling (RSS) hash algorithm. Updating
+RSS hash algorithm.
+
+* **[implements] eth_dev_ops**: ``dev_configure``, ``rss_hash_update``, 
``rss_hash_conf_get``.
+* **[uses] user config**: ``rss_conf.algorithm``
+* **[provides]   rte_eth_dev_info**: ``rss_algo_capa``.
+* **[related]API**: ``rte_eth_dev_configure``, 
``rte_eth_dev_rss_hash_update()``,
``rte_eth_dev_rss_hash_conf_get()``.
  
  


This document describes features listed in the 'default.ini', so we
shouldn't have above.

And I don't think RSS hash algorithm update is a big enough feature to
list in the feature list, perhaps it can be embedded in the RSS support
block, what do you think?

Yes it is not a bit feature.
so put it to RSS hash, right?





.

Re: [PATCH v3 2/6] doc: add link up/down feature

[lihuisong (C)]

在 2023/11/27 20:24, Ferruh Yigit 写道:

On 11/25/2023 1:47 AM, Huisong Li wrote:

Add link up/down feature for features.rst.

Fixes: 915e67837586 ("ethdev: API for link up and down")
Cc: sta...@dpdk.org


Documentation is added after feature, so above fixes line is not correct.

I am not sure if this is fix, I think more like it is extending the
document.


With fixes line fix,
Acked-by: Ferruh Yigit 


Ok  just to add Cc stable.

Signed-off-by: Huisong Li 
Acked-by: Chengwen Feng 
---
  doc/guides/nics/features.rst | 4 
  1 file changed, 4 insertions(+)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 0d38c5c525..f14962a6c3 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -45,6 +45,10 @@ Supports getting the link speed, duplex mode and link state 
(up/down).
  * **[implements] rte_eth_dev_data**: ``dev_link``.
  * **[related]API**: ``rte_eth_link_get()``, ``rte_eth_link_get_nowait()``.
  
+Set link up/down an Ethernet device.

+
+* **[implements] eth_dev_ops**: ``dev_set_link_up``, ``dev_set_link_down``.
+* **[related]API**: ``rte_eth_dev_set_link_up()``, 
``rte_eth_dev_set_link_down()``.
  
  .. _nic_features_link_status_event:
  


.

Re: [PATCH v3 0/6] doc/features: fix some features and add new features

[lihuisong (C)]

在 2023/11/27 20:35, Ferruh Yigit 写道:

On 11/25/2023 1:47 AM, Huisong Li wrote:

The support for setting RSS hash algorithm has been introduced to 23.11,
but doesn't add feature for it. So this series add this feature and perfect
RSS other features by the way.

In addition, serval features, like "set link up/down", "TM", "dump device
private information" and "loopback mode", had beed supported, but they are
absent from the freatures list.

---
  -v3:
- fix description of the patchset cover
- remove '/features' in 'doc/features' tag for every patch.
- add Acked-by: Chengwen Feng 
- retrigger CI build because of wrong CI warning

  -v2:
- add loopback mode feature.

Huisong Li (6):
   doc: add RSS hash algorithm feature
   doc: add link up/down feature
   doc: add features for link speeds
   doc: add Traffic Manager feature
   doc: add dump device private information feature
   doc: add feature for loopback mode

  

Hi Huisong,

Some of the patches above adds new features to the 'features.rst', but
features.rst document describes features that drivers mark in feature
list in .ini file, all features are listed in the 'default.ini'.

When a new feature is added into 'default.ini', it can be described in
'features.rst' and later all driver .ini files should be updated to
reflect if they support this feature or not.

correct.


And I think no need to document all features, but ones can be important
enough or differentiating features for users to know, this line is not

agree with you.

easy to draw, so perhaps we can use community consensus to select.

In this patch following features are added:
- Link speed configuration
- Traffic manager
- Device private information dump
- Loopback configuration


I think 'Traffic manager' can be a new feature, but I am not sure about
rest. It would be nice to get more comments.
Link speed is also important for NIC. Fixed speed and Link autoneg is 
from this.

I think it can be a new feature. what do you think?
How about add others to the following block?
"Other dev ops not represented by a Feature"

.

[PATCH 2/3] net/hns3: fix VF wrong clear reset status

[Dengdui Huang]

The function hns3_clear_reset_event is used to clear PF
reset status, The VF shouldn't use it.

This patch fix it.

Fixes: 1eee1ea75c0e ("net/hns3: fix IMP or global reset")
Cc: sta...@dpdk.org

Signed-off-by: Dengdui Huang 
---
 drivers/net/hns3/hns3_intr.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hns3/hns3_intr.c b/drivers/net/hns3/hns3_intr.c
index c5a3e3797c..52b5435a23 100644
--- a/drivers/net/hns3/hns3_intr.c
+++ b/drivers/net/hns3/hns3_intr.c
@@ -2749,7 +2749,8 @@ hns3_reset_post(struct hns3_adapter *hns)
/* IMP will wait ready flag before reset */
hns3_notify_reset_ready(hw, false);
hns3_clear_reset_level(hw, &hw->reset.pending);
-   hns3_clear_reset_event(hw);
+   if (!hns->is_vf)
+   hns3_clear_reset_event(hw);
__atomic_store_n(&hns->hw.reset.resetting, 0, __ATOMIC_RELAXED);
hw->reset.attempts = 0;
hw->reset.stats.success_cnt++;
@@ -2799,7 +2800,8 @@ hns3_reset_fail_handle(struct hns3_adapter *hns)
struct timeval tv;
 
hns3_clear_reset_level(hw, &hw->reset.pending);
-   hns3_clear_reset_event(hw);
+   if (!hns->is_vf)
+   hns3_clear_reset_event(hw);
if (hns3_reset_err_handle(hns)) {
hw->reset.stage = RESET_STAGE_PREWAIT;
hns3_schedule_reset(hns);
-- 
2.33.0

[PATCH 0/3] fix some bug for hns3

[Dengdui Huang]

Dengdui Huang (3):
  net/hns3: fix reset detect be ignored
  net/hns3: fix VF wrong clear reset status
  net/hns3: fix the VF reset interrupted possibly

 drivers/net/hns3/hns3_ethdev.c|  5 -
 drivers/net/hns3/hns3_ethdev.h| 12 
 drivers/net/hns3/hns3_ethdev_vf.c | 19 +--
 drivers/net/hns3/hns3_intr.c  |  4 ++--
 4 files changed, 35 insertions(+), 5 deletions(-)

-- 
2.33.0

[PATCH 3/3] net/hns3: fix the VF reset interrupted possibly

[Dengdui Huang]

Currently, the VF reset interrupt is enabled before the reset
process is completed. If the VF reset is triggered by an IMP
reset, the initialization of IMP is may not completed, and the
VF reset interrupt may continue to be reported. In this scenario,
the VF reset being performed by the driver does not need to be
interrupted. Therefore, for VF reset, the driver has to enable
the interrupt after the end of reset.

Fixes: a5475d61fa3 ("net/hns3: support VF")
Cc: sta...@dpdk.org

Signed-off-by: Dengdui Huang 
---
 drivers/net/hns3/hns3_ethdev.h| 12 
 drivers/net/hns3/hns3_ethdev_vf.c | 19 +--
 drivers/net/hns3/hns3_intr.c  |  6 ++
 3 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
index 668f141e32..12d8299def 100644
--- a/drivers/net/hns3/hns3_ethdev.h
+++ b/drivers/net/hns3/hns3_ethdev.h
@@ -1035,6 +1035,7 @@ void hns3vf_update_link_status(struct hns3_hw *hw, 
uint8_t link_status,
  uint32_t link_speed, uint8_t link_duplex);
 void hns3vf_update_push_lsc_cap(struct hns3_hw *hw, bool supported);
 void hns3_clear_reset_event(struct hns3_hw *hw);
+void hns3vf_clear_reset_event(struct hns3_hw *hw);
 
 const char *hns3_get_media_type_name(uint8_t media_type);
 
@@ -1049,4 +1050,15 @@ is_reset_pending(struct hns3_adapter *hns)
return ret;
 }
 
+static inline void
+hns3_clear_reset_status(struct hns3_hw *hw)
+{
+   struct hns3_adapter *hns = HNS3_DEV_HW_TO_ADAPTER(hw);
+
+   if (hns->is_vf)
+   hns3vf_clear_reset_event(hw);
+   else
+   hns3_clear_reset_event(hw);
+}
+
 #endif /* HNS3_ETHDEV_H */
diff --git a/drivers/net/hns3/hns3_ethdev_vf.c 
b/drivers/net/hns3/hns3_ethdev_vf.c
index 156fb905f9..53bcc44161 100644
--- a/drivers/net/hns3/hns3_ethdev_vf.c
+++ b/drivers/net/hns3/hns3_ethdev_vf.c
@@ -531,6 +531,19 @@ hns3vf_enable_irq0(struct hns3_hw *hw)
hns3_write_dev(hw, HNS3_MISC_VECTOR_REG_BASE, 1);
 }
 
+void
+hns3vf_clear_reset_event(struct hns3_hw *hw)
+{
+   uint32_t clearval;
+   uint32_t cmdq_stat_reg;
+
+   cmdq_stat_reg = hns3_read_dev(hw, HNS3_VECTOR0_CMDQ_STAT_REG);
+   clearval = cmdq_stat_reg & ~BIT(HNS3_VECTOR0_RST_INT_B);
+   hns3_write_dev(hw, HNS3_VECTOR0_CMDQ_SRC_REG, clearval);
+
+   hns3vf_enable_irq0(hw);
+}
+
 static enum hns3vf_evt_cause
 hns3vf_check_event_cause(struct hns3_adapter *hns, uint32_t *clearval)
 {
@@ -605,8 +618,10 @@ hns3vf_interrupt_handler(void *param)
break;
}
 
-   /* Enable interrupt */
-   hns3vf_enable_irq0(hw);
+   /* Enable interrupt if it is not cause by reset */
+   if (event_cause == HNS3VF_VECTOR0_EVENT_MBX ||
+   event_cause == HNS3VF_VECTOR0_EVENT_OTHER)
+   hns3vf_enable_irq0(hw);
 }
 
 void
diff --git a/drivers/net/hns3/hns3_intr.c b/drivers/net/hns3/hns3_intr.c
index 52b5435a23..916bf30dcb 100644
--- a/drivers/net/hns3/hns3_intr.c
+++ b/drivers/net/hns3/hns3_intr.c
@@ -2749,8 +2749,7 @@ hns3_reset_post(struct hns3_adapter *hns)
/* IMP will wait ready flag before reset */
hns3_notify_reset_ready(hw, false);
hns3_clear_reset_level(hw, &hw->reset.pending);
-   if (!hns->is_vf)
-   hns3_clear_reset_event(hw);
+   hns3_clear_reset_status(hw);
__atomic_store_n(&hns->hw.reset.resetting, 0, __ATOMIC_RELAXED);
hw->reset.attempts = 0;
hw->reset.stats.success_cnt++;
@@ -2800,8 +2799,7 @@ hns3_reset_fail_handle(struct hns3_adapter *hns)
struct timeval tv;
 
hns3_clear_reset_level(hw, &hw->reset.pending);
-   if (!hns->is_vf)
-   hns3_clear_reset_event(hw);
+   hns3_clear_reset_status(hw);
if (hns3_reset_err_handle(hns)) {
hw->reset.stage = RESET_STAGE_PREWAIT;
hns3_schedule_reset(hns);
-- 
2.33.0

[PATCH 1/3] net/hns3: fix reset detect be ignored

[Dengdui Huang]

The code logic that only new reset whose level is higher than old
reset level will be addressed is added in hns3_detect_reset_event,
see commit 5be38fc6c0fc ("net/hns3: fix multiple reset detected log").
When the new reset is detected and the old reset level is HNS3_NONE_RESET
this reset will be ignored. This patch fix it.

Fixes: 5be38fc6c0fc ("net/hns3: fix multiple reset detected log")
Cc: sta...@dpdk.org

Signed-off-by: Dengdui Huang 
---
 drivers/net/hns3/hns3_ethdev.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
index 941d047bf1..ae81368f68 100644
--- a/drivers/net/hns3/hns3_ethdev.c
+++ b/drivers/net/hns3/hns3_ethdev.c
@@ -5560,7 +5560,10 @@ hns3_detect_reset_event(struct hns3_hw *hw)
new_req = HNS3_GLOBAL_RESET;
}
 
-   if (new_req != HNS3_NONE_RESET && last_req < new_req) {
+   if (new_req == HNS3_NONE_RESET)
+   return HNS3_NONE_RESET;
+
+   if (last_req == HNS3_NONE_RESET || last_req < new_req) {
hns3_schedule_delayed_reset(hns);
hns3_warn(hw, "High level reset detected, delay do reset");
}
-- 
2.33.0

Re: [PATCH 0/3] fix some bug for hns3

[Jie Hai]

On 2023/11/27 21:39, Dengdui Huang wrote:

Dengdui Huang (3):
   net/hns3: fix reset detect be ignored
   net/hns3: fix VF wrong clear reset status
   net/hns3: fix the VF reset interrupted possibly

Hi, Dengdui,

Good fix.
For the patchset,
Acked-by: Jie Hai 

Thank,
Jie Hai


  drivers/net/hns3/hns3_ethdev.c|  5 -
  drivers/net/hns3/hns3_ethdev.h| 12 
  drivers/net/hns3/hns3_ethdev_vf.c | 19 +--
  drivers/net/hns3/hns3_intr.c  |  4 ++--
  4 files changed, 35 insertions(+), 5 deletions(-)

[PATCH v4 3/5] doc: add features for link speeds

[Huisong Li]

Add features for link speeds.

Fixes: 82113036e4e5 ("ethdev: redesign link speed config")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Acked-by: Chengwen Feng 
---
 doc/guides/nics/features.rst | 11 +++
 doc/guides/nics/features/default.ini |  1 +
 2 files changed, 12 insertions(+)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 1372ede021..3a4625f079 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -34,6 +34,17 @@ Supports getting the speed capabilities that the current 
device is capable of.
 * **[related]  API**: ``rte_eth_dev_info_get()``.
 
 
+.. _nic_features_link_speeds_config:
+
+Link speed configuration
+
+
+Supports configurating fixed speed and link autonegotiation.
+
+* **[uses] user config**: ``dev_conf.link_speeds:RTE_ETH_LINK_SPEED_*``.
+* **[related]  API**: ``rte_eth_dev_configure()``.
+
+
 .. _nic_features_link_status:
 
 Link status
diff --git a/doc/guides/nics/features/default.ini 
b/doc/guides/nics/features/default.ini
index 806cb033ff..4de7d9765f 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -8,6 +8,7 @@
 ;
 [Features]
 Speed capabilities   =
+Link speed configuration =
 Link status  =
 Link status event=
 Removal event=
-- 
2.33.0

[PATCH v4 0/5] doc/features: fix some features and add new features

[Huisong Li]

The support for setting RSS hash algorithm has been introduced to 23.11,
but doesn't add feature for it. So this series add this feature to RSS hash
and perfect RSS other features by the way.

In addition, serval features or interface, like "set link up/down", "TM",
"link speeds" and "dump device private information" had beed supported,
but they are absent from the freatures list.

---
 -v4:
   - fix RSS releated feaures description based on Ferruh
   - add new features to default.ini
   - remove loopback patch.
   - move "dump device private information" to "dev ops" block.

 -v3:
   - fix description of the patchset cover
   - remove '/features' in 'doc/features' tag for every patch.
   - add Acked-by: Chengwen Feng 
   - retrigger CI build because of wrong CI warning

 -v2:
   - add loopback mode feature.

Huisong Li (5):
  doc: fix the description of RSS related feature
  doc: add link up/down feature
  doc: add features for link speeds
  doc: add Traffic Manager feature
  doc: add dump device private information ops

 doc/guides/nics/features.rst | 47 +---
 doc/guides/nics/features/default.ini |  2 ++
 2 files changed, 45 insertions(+), 4 deletions(-)

-- 
2.33.0

[PATCH v4 1/5] doc: fix the description of RSS related feature

[Huisong Li]

This patch fixes the description of RSS feature.
And the settinf ot hash algorithm is introduced by 23.11, so add it.

Fixes: 34ff088cc241 ("ethdev: set and query RSS hash algorithm")

Signed-off-by: Huisong Li 
Acked-by: Chengwen Feng 
---
 doc/guides/nics/features.rst | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 1a1dc16c1e..307dfc162e 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -277,10 +277,19 @@ RSS hash
 Supports RSS hashing on RX.
 
 * **[uses] user config**: ``dev_conf.rxmode.mq_mode`` = 
``RTE_ETH_MQ_RX_RSS_FLAG``.
-* **[uses] user config**: ``dev_conf.rx_adv_conf.rss_conf``.
+* **[uses] user config**: ``dev_conf.rx_adv_conf.rss_conf.rss_hf``. 
``rss_conf.rss_hf``
 * **[uses] rte_eth_rxconf,rte_eth_rxmode**: 
``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
 * **[provides] rte_eth_dev_info**: ``flow_type_rss_offloads``.
 * **[provides] mbuf**: ``mbuf.ol_flags:RTE_MBUF_F_RX_RSS_HASH``, ``mbuf.rss``.
+* **[related]  API**: ``rte_eth_dev_configure()``, 
``rte_eth_dev_rss_hash_update``
+  ``rte_eth_dev_rss_hash_conf_get()``.
+
+Support RSS hash algorithm on Rx.
+* **[implements] eth_dev_ops**: ``dev_configure``, ``rss_hash_update``, 
``rss_hash_conf_get``.
+* **[uses] user config**: ``rss_conf.algorithm``
+* **[provides]   rte_eth_dev_info**: ``rss_algo_capa``.
+* **[related]API**: ``rte_eth_dev_configure()``, 
``rte_eth_dev_rss_hash_update()``,
+  ``rte_eth_dev_rss_hash_conf_get()``.
 
 
 .. _nic_features_inner_rss:
@@ -288,7 +297,7 @@ Supports RSS hashing on RX.
 Inner RSS
 -
 
-Supports RX RSS hashing on Inner headers.
+Supports RX RSS hashing on Inner headers by rte_flow API.
 
 * **[uses]rte_flow_action_rss**: ``level``.
 * **[uses]rte_eth_rxconf,rte_eth_rxmode**: 
``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
@@ -303,9 +312,10 @@ RSS key update
 Supports configuration of Receive Side Scaling (RSS) hash computation. Updating
 Receive Side Scaling (RSS) hash key.
 
-* **[implements] eth_dev_ops**: ``rss_hash_update``, ``rss_hash_conf_get``.
+* **[implements] eth_dev_ops**: ``dev_configure``, ``rss_hash_update``, 
``rss_hash_conf_get``.
+* **[uses] user config**: ``rss_conf.rss_key``, ``rss_conf.rss_key_len``
 * **[provides]   rte_eth_dev_info**: ``hash_key_size``.
-* **[related]API**: ``rte_eth_dev_rss_hash_update()``,
+* **[related]API**: ``rte_eth_dev_configure()``, 
``rte_eth_dev_rss_hash_update()``,
   ``rte_eth_dev_rss_hash_conf_get()``.
 
 
-- 
2.33.0

[PATCH v4 2/5] doc: add link up/down feature

[Huisong Li]

Add link up/down feature for features.rst.

Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Acked-by: Chengwen Feng 
Acked-by: Ferruh Yigit 
---
 doc/guides/nics/features.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 307dfc162e..1372ede021 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -45,6 +45,10 @@ Supports getting the link speed, duplex mode and link state 
(up/down).
 * **[implements] rte_eth_dev_data**: ``dev_link``.
 * **[related]API**: ``rte_eth_link_get()``, ``rte_eth_link_get_nowait()``.
 
+Set link up/down an Ethernet device.
+
+* **[implements] eth_dev_ops**: ``dev_set_link_up``, ``dev_set_link_down``.
+* **[related]API**: ``rte_eth_dev_set_link_up()``, 
``rte_eth_dev_set_link_down()``.
 
 .. _nic_features_link_status_event:
 
-- 
2.33.0

[PATCH v4 5/5] doc: add dump device private information ops

[Huisong Li]

Add dump device private information to dev ops.

Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Acked-by: Chengwen Feng 
---
 doc/guides/nics/features.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 3d5fd36617..868cf8f6d9 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -1005,3 +1005,4 @@ Other dev ops not represented by a Feature
 * ``udp_tunnel_port_add``
 * ``udp_tunnel_port_del``
 * ``tx_pkt_prepare``
+* ``eth_dev_priv_dump``
-- 
2.33.0

[PATCH v4 4/5] doc: add Traffic Manager feature

[Huisong Li]

Add Traffic Manager feature.

Fixes: 5d109deffa87 ("ethdev: add traffic management API")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Acked-by: Chengwen Feng 
---
 doc/guides/nics/features.rst | 13 +
 doc/guides/nics/features/default.ini |  1 +
 2 files changed, 14 insertions(+)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 3a4625f079..3d5fd36617 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -765,6 +765,19 @@ Supports congestion management.
   ``rte_eth_cman_config_set()``, ``rte_eth_cman_config_get()``.
 
 
+.. _nic_features_traffic_manager:
+
+Traffic manager
+---
+
+Supports Traffic manager.
+
+* **[implements] rte_tm_ops**: ``capabilities_get``, ``shaper_profile_add``,
+  ``hierarchy_commit`` and so on.
+* **[related]API**: ``rte_tm_capabilities_get()``, 
``rte_tm_shaper_profile_add()``,
+  ``rte_tm_hierarchy_commit()`` and so on.
+
+
 .. _nic_features_fw_version:
 
 FW version
diff --git a/doc/guides/nics/features/default.ini 
b/doc/guides/nics/features/default.ini
index 4de7d9765f..df00f980cd 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -63,6 +63,7 @@ Tx descriptor status =
 Basic stats  =
 Extended stats   =
 Stats per queue  =
+Traffic manager  =
 FW version   =
 EEPROM dump  =
 Module EEPROM dump   =
-- 
2.33.0

Re: [PATCH] doc: add cnxk dmadev performance tuning details

[Thomas Monjalon]

> > Updated cnxk DMA driver document to explain about performance tuning
> > parameters for kernel module.
> > 
> > Signed-off-by: Amit Prakash Shukla 
> Acked-by:  Vamsi Krishna Attunuru 

Applied with some minor wording and style fixes.

Re: [PATCH v2 1/2] mempool: fix internal function documentation

[Thomas Monjalon]

06/11/2023 13:24, Andrew Rybchenko:
> On 10/23/23 12:38, Ferruh Yigit wrote:
> > - *   - >=0: Success; number of objects supplied.
> > + *   - 0: Success; number of objects supplied.
> 
> I think "number of objects supplied" does not make sense here any more.

Yes, will remove on apply.

[PATCH] net/mlx5: fix index choosing in TAG modification

[Michael Baum]

When MPLS modification support was added [1], the "tag_index" field was
added into "rte_flow_action_modify_data" structure.
As part of this change, the "RTE_FLOW_FIELD_TAG" type moved to use it
for tag array instead of using "level" field.
Using "level" is still supported for backwards compatibility when
"tag_index" field is zero.

The "mlx5_flow_field_id_to_modify_info()" function calls
"flow_hw_get_reg_id()" function with "level" without checking first
whether "tag_index" field is valid.

This patch calls first to "flow_tag_index_get()" function to get the
index before sending it to "flow_hw_get_reg_id()" function.

[1] c23626f27b09 ("ethdev: add MPLS header modification")

Fixes: 04e740e69512 ("net/mlx5: separate registers usage per port")
Cc: getel...@nvidia.com
Cc: sta...@dpdk.org

Signed-off-by: Michael Baum 
Acked-by: Ori Kam 
---
 drivers/net/mlx5/mlx5_flow_dv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 115d730317..e168325f2d 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -1925,7 +1925,7 @@ mlx5_flow_field_id_to_modify_info
if (priv->sh->config.dv_flow_en == 2)
reg = flow_hw_get_reg_id(dev,
 RTE_FLOW_ITEM_TYPE_TAG,
-data->level);
+tag_index);
else
reg = mlx5_flow_get_reg_id(dev, MLX5_APP_TAG,
   tag_index, error);
-- 
2.25.1

Re: [PATCH v2 2/2] mempool: clarify enqueue and dequeue ops return type

[Thomas Monjalon]

23/10/2023 11:43, Morten Brørup:
> > From: Ferruh Yigit [mailto:ferruh.yi...@amd.com]
> > Sent: Monday, 23 October 2023 11.39
> and dequeue ops return type
> > 
> > API documentations doesn't clarify expected return types for enqueue and
> > dequeue mempool_ops, clarifying it.
> > 
> > Fixes: 449c49b93a6b ("mempool: support handler operations")
> > Cc: sta...@dpdk.org
> > 
> > Reported-by: Morten Brørup 
> > Signed-off-by: Ferruh Yigit 
> > ---
> 
> Thank you, Ferruh.
> 
> Reviewed-by: Morten Brørup 

Series applied, thanks.

Re: [PATCH] ethdev: fix ESP packet type description

[Thomas Monjalon]

>> The correct protocol number for ESP (IP Encapsulating Security Payload)
>> packet type is 50. 51 is IPSec AH (Authentication Header).
>> 
>> Fixes: 1e84afd3906b ("mbuf: add security crypto flags and fields")
>> Signed-off-by: Alexander Kozyrev 
> Reviewed-by: Morten Brørup 

Applied, thanks

Re: [PATCH v3 1/6] doc: add RSS hash algorithm feature

[Ferruh Yigit]

On 11/27/2023 1:12 PM, lihuisong (C) wrote:
> 
> 在 2023/11/27 20:19, Ferruh Yigit 写道:
>> On 11/25/2023 1:47 AM, Huisong Li wrote:
>>> Add hash algorithm feature introduced by 23.11 and fix some RSS features
>>> description.
>>>
>>> Fixes: 34ff088cc241 ("ethdev: set and query RSS hash algorithm")
>>>
>>> Signed-off-by: Huisong Li 
>>> Acked-by: Chengwen Feng 
>>> ---
>>>   doc/guides/nics/features.rst | 26 ++
>>>   1 file changed, 22 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
>>> index 1a1dc16c1e..0d38c5c525 100644
>>> --- a/doc/guides/nics/features.rst
>>> +++ b/doc/guides/nics/features.rst
>>> @@ -277,10 +277,12 @@ RSS hash
>>>   Supports RSS hashing on RX.
>>>     * **[uses] user config**: ``dev_conf.rxmode.mq_mode`` =
>>> ``RTE_ETH_MQ_RX_RSS_FLAG``.
>>> -* **[uses] user config**: ``dev_conf.rx_adv_conf.rss_conf``.
>>> +* **[uses] user config**: ``rss_conf.rss_hf``.
>>>
>> Feature title is "RSS hash", it can be two things,
>> 1. "Receive Side Scaling" support
>> 2. Provide RSS hash to application
>>
>> When this document first prepared RSS hash value was always provided to
>> the application when RSS enabled.
>> So intention with this feature was "Receive Side Scaling" support, hence
>> 'RTE_ETH_MQ_RX_RSS_FLAG' added.
>>
>> Later providing RSS has to the application separated as optimization,
>> 'RTE_ETH_RX_OFFLOAD_RSS_HASH' & 'RTE_MBUF_F_RX_RSS_HASH' added for this
>> support.
> What should I do for above two comments？
> To tell application how to use it?
>

Just tried to give some context.


>>
>> As the intention of this feature is "Receive Side Scaling" support, we
>> shouldn't reduce configuration struct to 'rss_conf.rss_hf'.
>>
>> Instead perhaps can expand to:
>> 'rte_eth_conf.rx_adv_conf.rss_conf', 'rte_eth_rss_conf'
> 
>  I just pick their common part.😁
> 
> ok, will fix it.
> 
>>
>>
>>>   * **[uses] rte_eth_rxconf,rte_eth_rxmode**:
>>> ``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
>>>   * **[provides] rte_eth_dev_info**: ``flow_type_rss_offloads``.
>>>   * **[provides] mbuf**: ``mbuf.ol_flags:RTE_MBUF_F_RX_RSS_HASH``,
>>> ``mbuf.rss``.
>>> +* **[related]  API**: ``rte_eth_dev_configure``,
>>> ``rte_eth_dev_rss_hash_update``
>>> +  ``rte_eth_dev_rss_hash_conf_get()``.
>>>   
>> ack
>>
>>>     .. _nic_features_inner_rss:
>>> @@ -288,7 +290,7 @@ Supports RSS hashing on RX.
>>>   Inner RSS
>>>   -
>>>   -Supports RX RSS hashing on Inner headers.
>>> +Supports RX RSS hashing on Inner headers by rte_flow API.
>>>   
>> This should be clarified with details below, not sure if it required to
>> limit description to rte_flow.
> But this block like rte_flow_action_rss is from rte_flow.
> And ethdev ops doesn't support inner RSS.
> So I think it is ok.
>

Yes it is supported by rte_flow, and '[uses]' information should already
clarify it.


>>
>>
>> And I guess similar confusion exist with the providing hash to user.
>> Need to check if rte_flow implementation puts hash to mbuf along with
>> doing the RSS, or if it checks 'RTE_ETH_RX_OFFLOAD_RSS_HASH' offload,
>> and update below items accordingly.
> Do we need to tell user how to use it here?
> I feel this document is a little simple and main to list interface for
> user.
> In addition, it is better that the more detail about RSS should be
> presented  in rte_flow features.
>

No, I am not suggesting to add more detail.

My concern is 'RTE_ETH_RX_OFFLOAD_RSS_HASH' information may not be
correct, ethdev APIs checks offload flags, but does rte_flow
implementation check it?

My suggestion is double check that piece of information and fix it if
required.


>>
>>
>>>   * **[uses]    rte_flow_action_rss**: ``level``.
>>>   * **[uses]    rte_eth_rxconf,rte_eth_rxmode**:
>>> ``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
>>> @@ -303,9 +305,25 @@ RSS key update
>>>   Supports configuration of Receive Side Scaling (RSS) hash
>>> computation. Updating
>>>   Receive Side Scaling (RSS) hash key.
>>>   -* **[implements] eth_dev_ops**: ``rss_hash_update``,
>>> ``rss_hash_conf_get``.
>>> +* **[implements] eth_dev_ops**: ``dev_configure``,
>>> ``rss_hash_update``, ``rss_hash_conf_get``.
>>> +* **[uses] user config**: ``rss_conf.rss_key``,
>>> ``rss_conf.rss_key_len``
>>>   * **[provides]   rte_eth_dev_info**: ``hash_key_size``.
>>> -* **[related]    API**: ``rte_eth_dev_rss_hash_update()``,
>>> +* **[related]    API**: ``rte_eth_dev_configure``,
>>> ``rte_eth_dev_rss_hash_update()``,
>>> +  ``rte_eth_dev_rss_hash_conf_get()``.
>>> +
>> ack
>>
>> There is an inconsistency in the documentation but I think it is good to
>> use '()' when documenting API, like: 'rte_eth_dev_configure()'
> +1 will fix it.
>>
>>
>>> +
>>> +.. _nic_features_rss_hash_algo_update:
>>> +
>>> +RSS hash algorithm update
>>> +-
>>> +
>>> +Supports configuration of Receive Side Scaling (RSS) hash algorithm.
>>> Updating
>>> +RSS hash algorithm.
>>> +
>>> +* **[implement

Re: [PATCH] doc/contributing: update test guidelines for meson changes

[Thomas Monjalon]

02/10/2023 14:44, Bruce Richardson:
> With the meson test suites being reworked to be automatically generated,
> rather than having to be hard-coded in the meson.build file, we need to
> update our contributing guidelines to take account of this change.
> 
> Signed-off-by: Bruce Richardson 

Applied, thanks.

[PATCH v2] net/mlx5: fix index choosing in TAG modification

[Michael Baum]

When MPLS modification support was added [1], the "tag_index" field was
added into "rte_flow_action_modify_data" structure.
As part of this change, the "RTE_FLOW_FIELD_TAG" type moved to use it
for tag array instead of using "level" field.
Using "level" is still supported for backwards compatibility when
"tag_index" field is zero.

The "mlx5_flow_field_id_to_modify_info()" function calls
"flow_hw_get_reg_id()" function with "level" without checking first
whether "tag_index" field is valid.

This patch calls first to "flow_tag_index_get()" function to get the
index before sending it to "flow_hw_get_reg_id()" function.

[1] commit c23626f27b09 ("ethdev: add MPLS header modification")

Fixes: 04e740e69512 ("net/mlx5: separate registers usage per port")
Cc: getel...@nvidia.com
Cc: sta...@dpdk.org

Signed-off-by: Michael Baum 
Acked-by: Ori Kam 
---
v2: fix the commit reference format.

 drivers/net/mlx5/mlx5_flow_dv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 115d730317..e168325f2d 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -1925,7 +1925,7 @@ mlx5_flow_field_id_to_modify_info
if (priv->sh->config.dv_flow_en == 2)
reg = flow_hw_get_reg_id(dev,
 RTE_FLOW_ITEM_TYPE_TAG,
-data->level);
+tag_index);
else
reg = mlx5_flow_get_reg_id(dev, MLX5_APP_TAG,
   tag_index, error);
-- 
2.25.1

Re: [PATCH] doc: document basic MSVC build requirements

[Thomas Monjalon]

17/11/2023 22:19, Tyler Retzlaff:
> Document the basic requirements for download and add an option
> describing how to build with MSVC.
> 
> Signed-off-by: Tyler Retzlaff 

Applied with few indent fixes, thanks.

Re: [PATCH v3 0/6] doc/features: fix some features and add new features

[Ferruh Yigit]

On 11/27/2023 1:37 PM, lihuisong (C) wrote:
> 
> 在 2023/11/27 20:35, Ferruh Yigit 写道:
>> On 11/25/2023 1:47 AM, Huisong Li wrote:
>>> The support for setting RSS hash algorithm has been introduced to 23.11,
>>> but doesn't add feature for it. So this series add this feature and
>>> perfect
>>> RSS other features by the way.
>>>
>>> In addition, serval features, like "set link up/down", "TM", "dump
>>> device
>>> private information" and "loopback mode", had beed supported, but
>>> they are
>>> absent from the freatures list.
>>>
>>> ---
>>>   -v3:
>>>     - fix description of the patchset cover
>>>     - remove '/features' in 'doc/features' tag for every patch.
>>>     - add Acked-by: Chengwen Feng 
>>>     - retrigger CI build because of wrong CI warning
>>>
>>>   -v2:
>>>     - add loopback mode feature.
>>>
>>> Huisong Li (6):
>>>    doc: add RSS hash algorithm feature
>>>    doc: add link up/down feature
>>>    doc: add features for link speeds
>>>    doc: add Traffic Manager feature
>>>    doc: add dump device private information feature
>>>    doc: add feature for loopback mode
>>>
>>>   
>> Hi Huisong,
>>
>> Some of the patches above adds new features to the 'features.rst', but
>> features.rst document describes features that drivers mark in feature
>> list in .ini file, all features are listed in the 'default.ini'.
>>
>> When a new feature is added into 'default.ini', it can be described in
>> 'features.rst' and later all driver .ini files should be updated to
>> reflect if they support this feature or not.
> correct.
>>
>> And I think no need to document all features, but ones can be important
>> enough or differentiating features for users to know, this line is not
> agree with you.
>> easy to draw, so perhaps we can use community consensus to select.
>>
>> In this patch following features are added:
>> - Link speed configuration
>> - Traffic manager
>> - Device private information dump
>> - Loopback configuration
>>
>>
>> I think 'Traffic manager' can be a new feature, but I am not sure about
>> rest. It would be nice to get more comments.
> Link speed is also important for NIC. Fixed speed and Link autoneg is
> from this.
> I think it can be a new feature. what do you think?
>

Target is to document what a device/driver supports in DPDK, this may
help end user quickly check and see what to expect from a device/driver.

Also helps to gauge how feature complete a driver implementation is.


Is there a value to document if setting fixed speed supported for end
user? My assumption is mostly autoneg is used.


> How about add others to the following block?
> "Other dev ops not represented by a Feature"
> 

Yes there are some dev_ops, implemented by drivers but not documented in
the feature.rst .

Indeed it would be nice to document them too somehow, perhaps not as
part of the feature.rst, but it has its own document for these dev_ops,
and feature.rst can have link to them?

Re: [dpdk-dev] [PATCH v2] doc: define qualification criteria for external library

[Thomas Monjalon]

20/11/2023 18:46, Jerin Jacob:
> On Sun, Nov 19, 2023 at 2:23 PM Morten Brørup  
> wrote:
> > > From: Jerin Jacob [mailto:jerinjac...@gmail.com]
> > > On Fri, Nov 17, 2023 at 1:57 PM Morten Brørup
> > > > > From: Jerin Jacob [mailto:jerinjac...@gmail.com]
> > > > > On Thu, Sep 28, 2023 at 11:10 AM  wrote:
> > > > > > From: Jerin Jacob 
> > > > > > +- **Free availability**: The library must be freely available to
> > > > > build in either source or binary
> > > > > > +  form, with a preference for source form.
> > > >
> > > > Suggest adding:
> > > >
> > > > - **Free use and distribution license**: The library must be freely
> > > available to use and distribute without any attached conditions.
> > > >
> > > > We must require a BSD-like license, to ensure that DPDK as a whole
> > > (including 3rd party libraries) remains BSD licensed, and can be used
> > > in commercial (closed source) applications.
> > >
> > > As far as I understand, The initial scope of was “free availability”
> > > for building.
> > > Free distribution is much wider scope. I don't think, current external
> > > libraries[1] have free distribution rights.
> > > [1]
> > > https://github.com/DPDK/dpdk/blob/main/doc/guides/gpus/cuda.rst
> > > https://gitlab.com/nvidia/headers/cuda-individual/cudart/-
> > > /blob/main/LICENSE?ref_type=heads
> >
> > I didn't mean the library source code; I only meant the library in binary 
> > form.
> >
> > It is nice if the library's header files may be distributed too, but I 
> > don't see it as a requirement, especially if they are freely available 
> > elsewhere (preferably without imposing additional restrictions on the 
> > ability to use and distribute the library in binary form).
> >
> > How about this instead:
> >
> > - **License permitting free use and distribution in binary form**:
> > The library's license must allow free and unconditional use and 
> > distribution of the library in binary form.
> 
> Distribution and unconditional use is not the case for existing
> library dependencies such as
> https://gitlab.com/nvidia/headers/cuda-individual/cudart/-/blob/main/LICENSE?ref_type=heads
> 
> So I am not sure, Which is the correct thing to do. Maybe we can
> discuss more in tech board meeting if there are no other comments in
> mailing list on this topic.

I don't think we should make mandatory to have rights of redistribution.
To me, being to download and install the dependency without any restriction
is enough *for a driver*.
If distribution of the dependency is restricted,
then the driver will be disabled by the distro.
It is not our problem I think.

And I agree we must have stricter requirements for libraries dependencies.
I am OK to mandate free distribution for such library dependencies.


> > We might want lawyers to verify the wording when we have agreed on our 
> > intentions.
> >
> > > I am fine with either way, Feedback from others?

[...]

> > > > > > +- **Code readability**: When the depended library is optional,
> > > use
> > > > > stubs to reduce the ``ifdef``
> > > > > > +  clutter to enable better code readability.
> > > >
> > > > Why does everyone keep insisting that stubs make code more readable?
> > > Sometimes #ifdef is better.
> > >
> > > Could you share a case where when #ifdefs is better(Just to understand
> > > the view).?
> >
> > If an external library provides some simple functions, and a group (i.e. a 
> > subset) of functions in a DPDK library depends on that external library, 
> > then it might be more readable if those functions are enabled/disabled as a 
> > group in the DPDK library rather than individually.
> >
> > E.g. the external library provides functions for statistical processing, 
> > and the DPDK library can be built with or without statistics, depending on 
> > using the external library or not. If the DPDK library is built without 
> > statistics, it should not register statistics availability towards a 
> > management module (e.g. telemetry) if it is not really implemented within 
> > the DPDK library (because the underlying functions are stubs).
> >
> > It might also be a matter of personal preferences. When reviewing some 
> > source code, an #ifdef makes the availability of an underlying function 
> > perfectly clear. Blindly calling a function (of an external library) 
> > doesn't really show if the function is implemented for real, or just a stub.
> 
> In general theme in DPDK code base that we are trying to avoid a  lot
> of #ifdef in a given C file.
> Instead, we are doing following scheme.
> 
> https://github.com/DPDK/dpdk/blob/main/drivers/ml/cnxk/meson.build#L84
> https://github.com/DPDK/dpdk/blob/main/drivers/ml/cnxk/meson.build#L60
> https://github.com/DPDK/dpdk/blob/main/drivers/ml/cnxk/mvtvm_ml_stubs.c
> 
> > My opinion on this might be tainted by my preference for building from 
> > scratch. The distro people might see it very differently!
> 
> Yeah. I don't have a strong opinion, I can change to following, if
> there are no comments on this.

Re: [PATCH v3 1/6] doc: add RSS hash algorithm feature

[Ferruh Yigit]

On 11/27/2023 3:43 PM, Ferruh Yigit wrote:
> On 11/27/2023 1:12 PM, lihuisong (C) wrote:
>>
>> 在 2023/11/27 20:19, Ferruh Yigit 写道:
>>> On 11/25/2023 1:47 AM, Huisong Li wrote:
 Add hash algorithm feature introduced by 23.11 and fix some RSS features
 description.

 Fixes: 34ff088cc241 ("ethdev: set and query RSS hash algorithm")

 Signed-off-by: Huisong Li 
 Acked-by: Chengwen Feng 
 ---
   doc/guides/nics/features.rst | 26 ++
   1 file changed, 22 insertions(+), 4 deletions(-)

 diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
 index 1a1dc16c1e..0d38c5c525 100644
 --- a/doc/guides/nics/features.rst
 +++ b/doc/guides/nics/features.rst
 @@ -277,10 +277,12 @@ RSS hash
   Supports RSS hashing on RX.
     * **[uses] user config**: ``dev_conf.rxmode.mq_mode`` =
 ``RTE_ETH_MQ_RX_RSS_FLAG``.
 -* **[uses] user config**: ``dev_conf.rx_adv_conf.rss_conf``.
 +* **[uses] user config**: ``rss_conf.rss_hf``.

>>> Feature title is "RSS hash", it can be two things,
>>> 1. "Receive Side Scaling" support
>>> 2. Provide RSS hash to application
>>>
>>> When this document first prepared RSS hash value was always provided to
>>> the application when RSS enabled.
>>> So intention with this feature was "Receive Side Scaling" support, hence
>>> 'RTE_ETH_MQ_RX_RSS_FLAG' added.
>>>
>>> Later providing RSS has to the application separated as optimization,
>>> 'RTE_ETH_RX_OFFLOAD_RSS_HASH' & 'RTE_MBUF_F_RX_RSS_HASH' added for this
>>> support.
>> What should I do for above two comments？
>> To tell application how to use it?
>>
> 
> Just tried to give some context.
> 
> 
>>>
>>> As the intention of this feature is "Receive Side Scaling" support, we
>>> shouldn't reduce configuration struct to 'rss_conf.rss_hf'.
>>>
>>> Instead perhaps can expand to:
>>> 'rte_eth_conf.rx_adv_conf.rss_conf', 'rte_eth_rss_conf'
>>
>>  I just pick their common part.😁
>>
>> ok, will fix it.
>>
>>>
>>>
   * **[uses] rte_eth_rxconf,rte_eth_rxmode**:
 ``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
   * **[provides] rte_eth_dev_info**: ``flow_type_rss_offloads``.
   * **[provides] mbuf**: ``mbuf.ol_flags:RTE_MBUF_F_RX_RSS_HASH``,
 ``mbuf.rss``.
 +* **[related]  API**: ``rte_eth_dev_configure``,
 ``rte_eth_dev_rss_hash_update``
 +  ``rte_eth_dev_rss_hash_conf_get()``.
   
>>> ack
>>>
     .. _nic_features_inner_rss:
 @@ -288,7 +290,7 @@ Supports RSS hashing on RX.
   Inner RSS
   -
   -Supports RX RSS hashing on Inner headers.
 +Supports RX RSS hashing on Inner headers by rte_flow API.
   
>>> This should be clarified with details below, not sure if it required to
>>> limit description to rte_flow.
>> But this block like rte_flow_action_rss is from rte_flow.
>> And ethdev ops doesn't support inner RSS.
>> So I think it is ok.
>>
> 
> Yes it is supported by rte_flow, and '[uses]' information should already
> clarify it.
> 
> 
>>>
>>>
>>> And I guess similar confusion exist with the providing hash to user.
>>> Need to check if rte_flow implementation puts hash to mbuf along with
>>> doing the RSS, or if it checks 'RTE_ETH_RX_OFFLOAD_RSS_HASH' offload,
>>> and update below items accordingly.
>> Do we need to tell user how to use it here?
>> I feel this document is a little simple and main to list interface for
>> user.
>> In addition, it is better that the more detail about RSS should be
>> presented  in rte_flow features.
>>
> 
> No, I am not suggesting to add more detail.
> 
> My concern is 'RTE_ETH_RX_OFFLOAD_RSS_HASH' information may not be
> correct, ethdev APIs checks offload flags, but does rte_flow
> implementation check it?
> 
> My suggestion is double check that piece of information and fix it if
> required.
> 

Thinking twice, ethdev API or rte_flow or different ways to configure
RSS, but datapath that puts hash value to mbuf is same.
So same 'RTE_ETH_RX_OFFLOAD_RSS_HASH' check is used for both method, and
it is OK to have it documented.



> 
>>>
>>>
   * **[uses]    rte_flow_action_rss**: ``level``.
   * **[uses]    rte_eth_rxconf,rte_eth_rxmode**:
 ``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
 @@ -303,9 +305,25 @@ RSS key update
   Supports configuration of Receive Side Scaling (RSS) hash
 computation. Updating
   Receive Side Scaling (RSS) hash key.
   -* **[implements] eth_dev_ops**: ``rss_hash_update``,
 ``rss_hash_conf_get``.
 +* **[implements] eth_dev_ops**: ``dev_configure``,
 ``rss_hash_update``, ``rss_hash_conf_get``.
 +* **[uses] user config**: ``rss_conf.rss_key``,
 ``rss_conf.rss_key_len``
   * **[provides]   rte_eth_dev_info**: ``hash_key_size``.
 -* **[related]    API**: ``rte_eth_dev_rss_hash_update()``,
 +* **[related]    API**: ``rte_eth_dev_configure``,
 ``rte_eth_dev_rss_hash_update()``,
 +  ``rte_eth_dev_rss_hash_conf_get()``.
 +
>>> ack
>>>

Re: [PATCH v4 1/5] doc: fix the description of RSS related feature

[Ferruh Yigit]

On 11/27/2023 2:16 PM, Huisong Li wrote:
> This patch fixes the description of RSS feature.
> And the settinf ot hash algorithm is introduced by 23.11, so add it.
> 
> Fixes: 34ff088cc241 ("ethdev: set and query RSS hash algorithm")
> 
> Signed-off-by: Huisong Li 
> Acked-by: Chengwen Feng 
> 

Acked-by: Ferruh Yigit 

Re: [PATCH v4 5/5] doc: add dump device private information ops

[Ferruh Yigit]

On 11/27/2023 2:16 PM, Huisong Li wrote:
> Add dump device private information to dev ops.
> 
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Huisong Li 
> Acked-by: Chengwen Feng 
> 

Acked-by: Ferruh Yigit 

Re: [PATCH 2/2] known_issues: drop note about UIO with really old kernels

[Thomas Monjalon]

17/07/2023 16:14, Bruce Richardson:
> On Mon, Jul 03, 2023 at 04:59:47PM -0700, Stephen Hemminger wrote:
> > On Thu, 17 Feb 2022 08:45:17 -0800
> > Stephen Hemminger  wrote:
> > 
> > > The DPDK has not supported 3.9 kernel for a long time so the
> > > release note about UIO kernel bug in older versions is no
> > > longer relevant.
> > > 
> > > Signed-off-by: Stephen Hemminger 
> > > ---
> > > -Binding PCI devices to igb_uio fails on Linux kernel 3.9 when more than 
> > > one device is used
> > > ---
> > > -
> > > -**Description**:
> > > -   A known bug in the UIO driver included in Linux kernel version 3.9 
> > > prevents more than one PCI device to be
> > > -   bound to the igb_uio driver.
> > > -
> > > -**Implication**:
> > > -   The Poll Mode Driver (PMD) will crash on initialization.
> > > -
> > > -**Resolution/Workaround**:
> > > -   Use earlier or later kernel versions, or apply the following
> > > -   `patch  
> > > `_.
> > > -
> > > -**Affected Environment/Platform**:
> > > -   Linux systems with kernel version 3.9
> > > -
> > > -**Driver/Module**:
> > > -   igb_uio module
> > > -
> > > -
> > 
> > Could someone review this patch? It been stuck for a long time.
> 
> Acked-by: Bruce Richardson 

Applied, sorry for having missed it.

Re: [PATCH v4 0/5] doc/features: fix some features and add new features

[Ferruh Yigit]

On 11/27/2023 2:16 PM, Huisong Li wrote:
> The support for setting RSS hash algorithm has been introduced to 23.11,
> but doesn't add feature for it. So this series add this feature to RSS hash
> and perfect RSS other features by the way.
> 
> In addition, serval features or interface, like "set link up/down", "TM",
> "link speeds" and "dump device private information" had beed supported,
> but they are absent from the freatures list.
> 
> ---
>  -v4:
>- fix RSS releated feaures description based on Ferruh
>- add new features to default.ini
>- remove loopback patch.
>- move "dump device private information" to "dev ops" block.
> 
>  -v3:
>- fix description of the patchset cover
>- remove '/features' in 'doc/features' tag for every patch.
>- add Acked-by: Chengwen Feng 
>- retrigger CI build because of wrong CI warning
> 
>  -v2:
>- add loopback mode feature.
> 
> Huisong Li (5):
>   doc: fix the description of RSS related feature
>   doc: add link up/down feature
>   doc: add features for link speeds
>   doc: add Traffic Manager feature
>   doc: add dump device private information ops
> 

As mentioned before I don't know about adding link speed feature or not,
would like to get more comment.

But for the new features added, driver .ini files also needs to be
updated for that new feature, and drivers support it should mark the
support.
That is why it is best to start documenting a feature when it is first
introduced, otherwise it is more work to update it later.

Re: [PATCH] doc: ensure sphinx output is reproducible

[Thomas Monjalon]

06/07/2023 14:49, Christian Ehrhardt:
> On Mon, Jul 3, 2023 at 5:29 PM Thomas Monjalon  wrote:
> >
> > 29/06/2023 14:58, christian.ehrha...@canonical.com:
> > > From: Christian Ehrhardt 
> > >
> > > By adding -j we build in parallel, to make building on multiprocessor
> > > machines more effective. While that works it does also break
> > > reproducible builds as the order of the sphinx generated searchindex.js
> > > is depending on execution speed of the individual processes.
> > [...]
> > > -if Version(ver) >= Version('1.7'):
> > > -sphinx_cmd += ['-j', 'auto']
> >
> > What is the impact on build speed on an average machine?
> 
> Hi,
> I haven't tested this in isolation as it was just a mandatory change
> on the Debian/Ubuntu side.
> And the time for exactly and only the doc build is hidden inside the
> concurrency of meson.
> But I can compare a full build [1] and a full build with the change [2].
> 
> That is an average build machine and it is 35 seconds slower with the
> change to no more do doc builds in parallel.

I would prefer adding an option for reproducible build
(which is not a common requirement).

Re: [PATCH] examples/l3fwd-power: fix to configure the uncore env

[Bruce Richardson]

On Thu, Nov 23, 2023 at 02:58:58AM +0100, Thomas Monjalon wrote:
> 26/10/2023 17:19, Sivaprasad Tummala:
> > Updated the l3fwd-power app to configure the uncore env before invoking
> > any uncore APIs. With auto-detection in 'rte_power_uncore_init()' it is
> > too late because other APIs already called.
> 
> You are also updating the uncore API.
> 
> > +   if (env == RTE_UNCORE_PM_ENV_AUTO_DETECT)
> > +   /* Currently only intel_uncore is supported. This will be
> > +* extended with auto-detection support for multiple uncore
> > +* implementations.
> > +*/
> > +   env = RTE_UNCORE_PM_ENV_INTEL_UNCORE;
> 
> It looks like this patch does not make sense without AMD support.
> 
This patch is fixing a regression introduced by an earlier patch in this
area (referenced in the fixes line). See bugzilla for more details on it[1]

This should go into 23.11 as, without it, what was working in earlier
releases no longer does so.

Thanks,
/Bruce

[1] https://bugs.dpdk.org/show_bug.cgi?id=1304

Re: [PATCH v4 0/5] doc/features: fix some features and add new features

[Ferruh Yigit]

On 11/27/2023 2:16 PM, Huisong Li wrote:
> The support for setting RSS hash algorithm has been introduced to 23.11,
> but doesn't add feature for it. So this series add this feature to RSS hash
> and perfect RSS other features by the way.
> 
> In addition, serval features or interface, like "set link up/down", "TM",
> "link speeds" and "dump device private information" had beed supported,
> but they are absent from the freatures list.
> 
> ---
>  -v4:
>- fix RSS releated feaures description based on Ferruh
>- add new features to default.ini
>- remove loopback patch.
>- move "dump device private information" to "dev ops" block.
> 
>  -v3:
>- fix description of the patchset cover
>- remove '/features' in 'doc/features' tag for every patch.
>- add Acked-by: Chengwen Feng 
>- retrigger CI build because of wrong CI warning
> 
>  -v2:
>- add loopback mode feature.
> 
> Huisong Li (5):
>   doc: fix the description of RSS related feature
>   doc: add link up/down feature
>   doc: add features for link speeds
>   doc: add Traffic Manager feature
>   doc: add dump device private information ops
> 

Please check the warning on document generation:
https://mails.dpdk.org/archives/test-report/2023-November/519586.html

/home/runner/work/dpdk/dpdk/doc/guides/nics/features.rst:307:Unexpected
indentation.

Re: [PATCH] doc: ensure sphinx output is reproducible

[Bruce Richardson]

On Mon, Nov 27, 2023 at 05:45:52PM +0100, Thomas Monjalon wrote:
> 06/07/2023 14:49, Christian Ehrhardt:
> > On Mon, Jul 3, 2023 at 5:29 PM Thomas Monjalon  wrote:
> > >
> > > 29/06/2023 14:58, christian.ehrha...@canonical.com:
> > > > From: Christian Ehrhardt 
> > > >
> > > > By adding -j we build in parallel, to make building on multiprocessor
> > > > machines more effective. While that works it does also break
> > > > reproducible builds as the order of the sphinx generated searchindex.js
> > > > is depending on execution speed of the individual processes.
> > > [...]
> > > > -if Version(ver) >= Version('1.7'):
> > > > -sphinx_cmd += ['-j', 'auto']
> > >
> > > What is the impact on build speed on an average machine?
> > 
> > Hi,
> > I haven't tested this in isolation as it was just a mandatory change
> > on the Debian/Ubuntu side.
> > And the time for exactly and only the doc build is hidden inside the
> > concurrency of meson.
> > But I can compare a full build [1] and a full build with the change [2].
> > 
> > That is an average build machine and it is 35 seconds slower with the
> > change to no more do doc builds in parallel.
> 
> I would prefer adding an option for reproducible build
> (which is not a common requirement).
> 
Taking a slightly different tack, is it possible to sort the searchindex.js
file post-build, so that even reproducible builds get the benefits of
parallelism?

/Bruce

Re: [dpdk-dev] [PATCH v2] doc: define qualification criteria for external library

[Stephen Hemminger]

On Mon, 27 Nov 2023 17:25:55 +0100
Thomas Monjalon  wrote:

> > 
> > Distribution and unconditional use is not the case for existing
> > library dependencies such as
> > https://gitlab.com/nvidia/headers/cuda-individual/cudart/-/blob/main/LICENSE?ref_type=heads
> > 
> > So I am not sure, Which is the correct thing to do. Maybe we can
> > discuss more in tech board meeting if there are no other comments in
> > mailing list on this topic.  
> 
> I don't think we should make mandatory to have rights of redistribution.
> To me, being to download and install the dependency without any restriction
> is enough *for a driver*.
> If distribution of the dependency is restricted,
> then the driver will be disabled by the distro.
> It is not our problem I think.
> 
> And I agree we must have stricter requirements for libraries dependencies.
> I am OK to mandate free distribution for such library dependencies.

For me, the policy should meet these goals:

1. A developer should be able to test any driver and library for free.
Ok, with any dependencies as long as they are freely available, and do not 
require
giving up all rights in the process (click through agreements).

2. A distro maintainer should be able to build DPDK with the component if
any dependent packages are available for that distribution.

3. DPDK must not become a sham front end for proprietary binary blobs.
That is what Open Dataplane was, just a wrapper API around proprietary binary
blob backends.

Re: [PATCH] eal: introduce missing rte_thread wrappers

[Stephen Hemminger]

On Mon, 27 Nov 2023 10:25:02 +0100
David Vodak  wrote:

> Function rte_ctrl_thread_create has been replaced by 
> rte_thread_create_control,
> encouraging Linux users to switch from the pthread_t API to the rte_thread 
> API.
> However the rte_thread API does not provide wrappers for all pthread 
> functions.
> This commit introduces equivalent functions for pthread_timedjoin_np,
> pthread_getname_np and pthread_cancel.
> 
> Bugzilla ID: 1330
> ---
>  lib/eal/include/rte_thread.h | 49 
>  lib/eal/unix/rte_thread.c| 20 +++
>  lib/eal/version.map  |  3 +++
>  3 files changed, 72 insertions(+)
> 
> diff --git a/lib/eal/include/rte_thread.h b/lib/eal/include/rte_thread.h
> index 8da9d4d3fb..49a068eda7 100644
> --- a/lib/eal/include/rte_thread.h
> +++ b/lib/eal/include/rte_thread.h
> @@ -463,6 +463,55 @@ int rte_thread_value_set(rte_thread_key key, const void 
> *value);
>   */
>  void *rte_thread_value_get(rte_thread_key key);
>  
> +/**
> + * Try to join with a terminated thread. If thread has not yet terminated,
> + * then the call blocks until a maximum time, specified in abstime.
> + *
> + * @param thread_id
> + *   Id of the thread.
> + *
> + * @param retval
> + *   Exit status of the thread.
> + *
> + * @param abstime
> + *   Maximum time of call blocking, measured against the CLOCK_REALTIME 
> clock.
> + *
> + * @return
> + *   On success, return 0.
> + *   On failure, return a positive errno-style error number.
> + */
> +int rte_thread_timedjoin_np(rte_thread_t thread_id, void **retval, const 
> struct timespec *abstime);
> +
> +/**
> + * Get name of the thread.
> + *
> + * @param thread_id
> + *   Id of the thread.
> + *
> + * @param name
> + *   Name of the thread.
> + *
> + * @param size
> + *   The number of bytes available in name.
> + *
> + * @return
> + *   On success, return 0.
> + *   On failure, return a positive errno-style error number.
> + */
> +int rte_thread_getname_np(rte_thread_t thread_id, char name[], size_t size);
> +
> +/**
> + * Send a cancelation request to a thread.
> + *
> + * @param thread_id
> + *   Id of the thread.
> + *
> + * @return
> + *   On success, return 0.
> + *   On failure, return a positive errno-style error number.
> + */
> +int rte_thread_cancel(rte_thread_t thread_id);

The point of the thread wrappers was to limit the use to what
was supportable on all platforms. 

Re: DPDK Release Status Meeting 2023-11-23

[Stephen Hemminger]

On Mon, 27 Nov 2023 11:13:16 +0100
Thomas Monjalon  wrote:

> ish.
> > >>
> > >> Due to a relative bigger RTE_MAX_LCORE value on ARM, the unit test case
> > >> would take a longer time to finish iterations.
> > >> In one of my run, the case took about 100s.  
> > > 
> > > Right, but this test is part of the "fast suite", and more than a
> > > minute is not exactly fast. So one of the following should ideally
> > > happen:  
> > 
> > Agree.
> >   
> > > 1) Test is moved out of the fast suite
> > > 2) Test has its individual timeout sized appropriately so that it
> > > never fails regardless of the environment
> > > 3) Test is capped so that it doesn't grow with the number of cores
> > > without limits  
> > 
> > I'm for option 3. The case should be kept in fast suite. Time taken 
> > should be capped.  
> 
> More than 1 second is a bit slow.
> Please make the test really faster.

What is the test trying to exercise? Can it be done in another way?

Re: [PATCH] eal: introduce missing rte_thread wrappers

[Tyler Retzlaff]

On Mon, Nov 27, 2023 at 10:25:02AM +0100, David Vodak wrote:
> Function rte_ctrl_thread_create has been replaced by 
> rte_thread_create_control,
> encouraging Linux users to switch from the pthread_t API to the rte_thread 
> API.
> However the rte_thread API does not provide wrappers for all pthread 
> functions.
> This commit introduces equivalent functions for pthread_timedjoin_np,
> pthread_getname_np and pthread_cancel.
> 
> Bugzilla ID: 1330
> ---

NAK this series. the rte thread API is not a POSIX emulation API.

the point of EAL is not to require applications to have to conditionally
compile code around the use of EAL API or handle "not supported"
failures it defeats the purpose of being an abstraction library.

[PATCH v2] raw/cnxk_bphy: switch to dynamic logging

[Tomasz Duszynski]

Dynamically allocated log type is a standard approach among all drivers.
Switch to it.

Signed-off-by: Tomasz Duszynski 
---
v2:
- cleanup remaining plt_ log calls

 drivers/raw/cnxk_bphy/cnxk_bphy.c  | 31 +++--
 drivers/raw/cnxk_bphy/cnxk_bphy.h  | 15 ++
 drivers/raw/cnxk_bphy/cnxk_bphy_cgx.c  |  4 ++-
 drivers/raw/cnxk_bphy/cnxk_bphy_cgx.h  |  7 +
 drivers/raw/cnxk_bphy/cnxk_bphy_cgx_test.c | 32 ++
 drivers/raw/cnxk_bphy/cnxk_bphy_irq.c  |  3 +-
 drivers/raw/cnxk_bphy/rte_pmd_bphy.h   |  6 ++--
 7 files changed, 61 insertions(+), 37 deletions(-)
 create mode 100644 drivers/raw/cnxk_bphy/cnxk_bphy.h

diff --git a/drivers/raw/cnxk_bphy/cnxk_bphy.c 
b/drivers/raw/cnxk_bphy/cnxk_bphy.c
index 15dbc4c1a6..b6830530d7 100644
--- a/drivers/raw/cnxk_bphy/cnxk_bphy.c
+++ b/drivers/raw/cnxk_bphy/cnxk_bphy.c
@@ -12,6 +12,7 @@

 #include 

+#include "cnxk_bphy.h"
 #include "cnxk_bphy_irq.h"
 #include "rte_pmd_bphy.h"

@@ -81,21 +82,21 @@ bphy_rawdev_selftest(uint16_t dev_id)
goto err_desc;
if (descs != 1) {
ret = -ENODEV;
-   plt_err("Wrong number of descs reported\n");
+   BPHY_LOG(ERR, "Wrong number of descs reported");
goto err_desc;
}

ret = rte_pmd_bphy_npa_pf_func_get(dev_id, &pf_func);
if (ret || pf_func == 0)
-   plt_warn("NPA pf_func is invalid");
+   BPHY_LOG(WARNING, "NPA pf_func is invalid");

ret = rte_pmd_bphy_sso_pf_func_get(dev_id, &pf_func);
if (ret || pf_func == 0)
-   plt_warn("SSO pf_func is invalid");
+   BPHY_LOG(WARNING, "SSO pf_func is invalid");

ret = rte_pmd_bphy_intr_init(dev_id);
if (ret) {
-   plt_err("intr init failed");
+   BPHY_LOG(ERR, "intr init failed");
return ret;
}

@@ -103,7 +104,7 @@ bphy_rawdev_selftest(uint16_t dev_id)

test = rte_zmalloc("BPHY", max_irq * sizeof(*test), 0);
if (test == NULL) {
-   plt_err("intr alloc failed");
+   BPHY_LOG(ERR, "intr alloc failed");
goto err_alloc;
}

@@ -132,7 +133,7 @@ bphy_rawdev_selftest(uint16_t dev_id)
}

if (ret) {
-   plt_err("intr register failed at irq %d", i);
+   BPHY_LOG(ERR, "intr register failed at irq %d", i);
goto err_register;
}
}
@@ -142,12 +143,12 @@ bphy_rawdev_selftest(uint16_t dev_id)

for (i = 0; i < max_irq; i++) {
if (!test[i].handled_intr) {
-   plt_err("intr %u not handled", i);
+   BPHY_LOG(ERR, "intr %u not handled", i);
ret = -1;
break;
}
if (test[i].handled_data != test[i].test_data) {
-   plt_err("intr %u has wrong handler", i);
+   BPHY_LOG(ERR, "intr %u has wrong handler", i);
ret = -1;
break;
}
@@ -251,7 +252,7 @@ cnxk_bphy_irq_enqueue_bufs(struct rte_rawdev *dev,

/* get rid of last response if any */
if (qp->rsp) {
-   RTE_LOG(WARNING, PMD, "Previous response got overwritten\n");
+   BPHY_LOG(WARNING, "Previous response got overwritten");
rte_free(qp->rsp);
}
qp->rsp = rsp;
@@ -332,9 +333,8 @@ bphy_rawdev_probe(struct rte_pci_driver *pci_drv,
return 0;

if (!pci_dev->mem_resource[0].addr) {
-   plt_err("BARs have invalid values: BAR0 %p\n BAR2 %p",
-   pci_dev->mem_resource[0].addr,
-   pci_dev->mem_resource[2].addr);
+   BPHY_LOG(ERR, "BARs have invalid values: BAR0 %p\n BAR2 %p",
+pci_dev->mem_resource[0].addr, 
pci_dev->mem_resource[2].addr);
return -ENODEV;
}

@@ -346,7 +346,7 @@ bphy_rawdev_probe(struct rte_pci_driver *pci_drv,
bphy_rawdev = rte_rawdev_pmd_allocate(name, sizeof(*bphy_dev),
  rte_socket_id());
if (bphy_rawdev == NULL) {
-   plt_err("Failed to allocate rawdev");
+   BPHY_LOG(ERR, "Failed to allocate rawdev");
return -ENOMEM;
}

@@ -381,14 +381,14 @@ bphy_rawdev_remove(struct rte_pci_device *pci_dev)
return 0;

if (pci_dev == NULL) {
-   plt_err("invalid pci_dev");
+   BPHY_LOG(ERR, "invalid pci_dev");
return -EINVAL;
}

bphy_rawdev_get_name(name, pci_dev);
rawdev = rte_rawdev_pmd_get_named_dev(name);
if (rawdev == NULL) {
-   plt_err("invalid device name (%s)", name);
+   BPHY_LOG(ERR, "invalid device name (%s)", name);
   

Re: [PATCH 0/3] fix some bug for hns3

[Ferruh Yigit]

On 11/27/2023 1:55 PM, Jie Hai wrote:
> On 2023/11/27 21:39, Dengdui Huang wrote:
>> Dengdui Huang (3):
>>    net/hns3: fix reset detect be ignored
>>    net/hns3: fix VF wrong clear reset status
>>    net/hns3: fix the VF reset interrupted possibly
> Hi, Dengdui,
> 
> Good fix.
> For the patchset,
> Acked-by: Jie Hai 
> 


Hi Jie, Dengdui, is this set for this release, which is a few days away?
My suggestion is to wait next version as issues doesn't look critical.


I applied set to next-net, but leaving decision to pull it for the
release or not to Thomas/David.

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

Re: [PATCH] examples/l3fwd-power: fix to configure the uncore env

[Thomas Monjalon]

27/11/2023 17:54, Bruce Richardson:
> On Thu, Nov 23, 2023 at 02:58:58AM +0100, Thomas Monjalon wrote:
> > 26/10/2023 17:19, Sivaprasad Tummala:
> > > Updated the l3fwd-power app to configure the uncore env before invoking
> > > any uncore APIs. With auto-detection in 'rte_power_uncore_init()' it is
> > > too late because other APIs already called.
> > 
> > You are also updating the uncore API.
> > 
> > > + if (env == RTE_UNCORE_PM_ENV_AUTO_DETECT)
> > > + /* Currently only intel_uncore is supported. This will be
> > > +  * extended with auto-detection support for multiple uncore
> > > +  * implementations.
> > > +  */
> > > + env = RTE_UNCORE_PM_ENV_INTEL_UNCORE;
> > 
> > It looks like this patch does not make sense without AMD support.
> > 
> This patch is fixing a regression introduced by an earlier patch in this
> area (referenced in the fixes line). See bugzilla for more details on it[1]
> 
> This should go into 23.11 as, without it, what was working in earlier
> releases no longer does so.

Thank you for the heads-up, I've looked at it too much quickly.

Re: [PATCH] examples/l3fwd-power: fix to configure the uncore env

[Thomas Monjalon]

27/10/2023 14:37, Hunt, David:
> On 27/10/2023 13:36, Kelly, Karen wrote:
> > On 26/10/2023 16:19, Sivaprasad Tummala wrote:
> >> Updated the l3fwd-power app to configure the uncore env before invoking
> >> any uncore APIs. With auto-detection in 'rte_power_uncore_init()' it is
> >> too late because other APIs already called.
> >>
> >> Bugzilla ID: 1304
> >> Fixes: ac1edcb6621a ("power: refactor uncore power management API")
> >> Cc:karen.ke...@intel.com
> >>
> >> Signed-off-by: Sivaprasad Tummala
> >> ---
> >>   examples/l3fwd-power/main.c  | 6 ++
> >>   lib/power/rte_power_uncore.c | 7 +++
> >>   lib/power/rte_power_uncore.h | 9 +
> >>   3 files changed, 18 insertions(+), 4 deletions(-)
> > Ran on my system, bug is resolved after applying this patch.
> >
> > Tested-by: Karen Kelly 
> >
> 
> Acked-by: David Hunt 

So I merge it to fix a bug in the library, despite the patch title.
I am fixing a typo, and the commit description.
Applied

Re: [PATCH v3 1/6] doc: add RSS hash algorithm feature

[lihuisong (C)]

在 2023/11/27 23:43, Ferruh Yigit 写道:

On 11/27/2023 1:12 PM, lihuisong (C) wrote:

在 2023/11/27 20:19, Ferruh Yigit 写道:

On 11/25/2023 1:47 AM, Huisong Li wrote:

Add hash algorithm feature introduced by 23.11 and fix some RSS features
description.

Fixes: 34ff088cc241 ("ethdev: set and query RSS hash algorithm")

Signed-off-by: Huisong Li 
Acked-by: Chengwen Feng 
---
   doc/guides/nics/features.rst | 26 ++
   1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 1a1dc16c1e..0d38c5c525 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -277,10 +277,12 @@ RSS hash
   Supports RSS hashing on RX.
     * **[uses] user config**: ``dev_conf.rxmode.mq_mode`` =
``RTE_ETH_MQ_RX_RSS_FLAG``.
-* **[uses] user config**: ``dev_conf.rx_adv_conf.rss_conf``.
+* **[uses] user config**: ``rss_conf.rss_hf``.


Feature title is "RSS hash", it can be two things,
1. "Receive Side Scaling" support
2. Provide RSS hash to application

When this document first prepared RSS hash value was always provided to
the application when RSS enabled.
So intention with this feature was "Receive Side Scaling" support, hence
'RTE_ETH_MQ_RX_RSS_FLAG' added.

Later providing RSS has to the application separated as optimization,
'RTE_ETH_RX_OFFLOAD_RSS_HASH' & 'RTE_MBUF_F_RX_RSS_HASH' added for this
support.

What should I do for above two comments？
To tell application how to use it?


Just tried to give some context.

got it.
  




As the intention of this feature is "Receive Side Scaling" support, we
shouldn't reduce configuration struct to 'rss_conf.rss_hf'.

Instead perhaps can expand to:
'rte_eth_conf.rx_adv_conf.rss_conf', 'rte_eth_rss_conf'

  I just pick their common part.😁

ok, will fix it.




   * **[uses] rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
   * **[provides] rte_eth_dev_info**: ``flow_type_rss_offloads``.
   * **[provides] mbuf**: ``mbuf.ol_flags:RTE_MBUF_F_RX_RSS_HASH``,
``mbuf.rss``.
+* **[related]  API**: ``rte_eth_dev_configure``,
``rte_eth_dev_rss_hash_update``
+  ``rte_eth_dev_rss_hash_conf_get()``.
   

ack


     .. _nic_features_inner_rss:
@@ -288,7 +290,7 @@ Supports RSS hashing on RX.
   Inner RSS
   -
   -Supports RX RSS hashing on Inner headers.
+Supports RX RSS hashing on Inner headers by rte_flow API.
   

This should be clarified with details below, not sure if it required to
limit description to rte_flow.

But this block like rte_flow_action_rss is from rte_flow.
And ethdev ops doesn't support inner RSS.
So I think it is ok.


Yes it is supported by rte_flow, and '[uses]' information should already
clarify it.

Should we remove the 'rte_flow API' wrods I added in above description?




And I guess similar confusion exist with the providing hash to user.
Need to check if rte_flow implementation puts hash to mbuf along with
doing the RSS, or if it checks 'RTE_ETH_RX_OFFLOAD_RSS_HASH' offload,
and update below items accordingly.

Do we need to tell user how to use it here?
I feel this document is a little simple and main to list interface for
user.
In addition, it is better that the more detail about RSS should be
presented  in rte_flow features.


No, I am not suggesting to add more detail.

My concern is 'RTE_ETH_RX_OFFLOAD_RSS_HASH' information may not be
correct, ethdev APIs checks offload flags, but does rte_flow
implementation check it?

As far as I know, It is possibly verified in PMD if have or required.


My suggestion is double check that piece of information and fix it if
required.





   * **[uses]    rte_flow_action_rss**: ``level``.
   * **[uses]    rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
@@ -303,9 +305,25 @@ RSS key update
   Supports configuration of Receive Side Scaling (RSS) hash
computation. Updating
   Receive Side Scaling (RSS) hash key.
   -* **[implements] eth_dev_ops**: ``rss_hash_update``,
``rss_hash_conf_get``.
+* **[implements] eth_dev_ops**: ``dev_configure``,
``rss_hash_update``, ``rss_hash_conf_get``.
+* **[uses] user config**: ``rss_conf.rss_key``,
``rss_conf.rss_key_len``
   * **[provides]   rte_eth_dev_info**: ``hash_key_size``.
-* **[related]    API**: ``rte_eth_dev_rss_hash_update()``,
+* **[related]    API**: ``rte_eth_dev_configure``,
``rte_eth_dev_rss_hash_update()``,
+  ``rte_eth_dev_rss_hash_conf_get()``.
+

ack

There is an inconsistency in the documentation but I think it is good to
use '()' when documenting API, like: 'rte_eth_dev_configure()'

+1 will fix it.



+
+.. _nic_features_rss_hash_algo_update:
+
+RSS hash algorithm update
+-
+
+Supports configuration of Receive Side Scaling (RSS) hash algorithm.
Updating
+RSS hash algorithm.
+
+* **[implements] eth_dev_ops**: ``dev_configure``,
``rss_hash_update``, ``rss_hash_conf_get``.
+* **[uses] user config**: ``rss_conf.algorithm``
+* **[provides]   rte_eth_dev_info**: ``rs

Re: [PATCH v3 1/6] doc: add RSS hash algorithm feature

[lihuisong (C)]

在 2023/11/28 0:35, Ferruh Yigit 写道:

On 11/27/2023 3:43 PM, Ferruh Yigit wrote:

On 11/27/2023 1:12 PM, lihuisong (C) wrote:

在 2023/11/27 20:19, Ferruh Yigit 写道:

On 11/25/2023 1:47 AM, Huisong Li wrote:

Add hash algorithm feature introduced by 23.11 and fix some RSS features
description.

Fixes: 34ff088cc241 ("ethdev: set and query RSS hash algorithm")

Signed-off-by: Huisong Li 
Acked-by: Chengwen Feng 
---
   doc/guides/nics/features.rst | 26 ++
   1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 1a1dc16c1e..0d38c5c525 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -277,10 +277,12 @@ RSS hash
   Supports RSS hashing on RX.
     * **[uses] user config**: ``dev_conf.rxmode.mq_mode`` =
``RTE_ETH_MQ_RX_RSS_FLAG``.
-* **[uses] user config**: ``dev_conf.rx_adv_conf.rss_conf``.
+* **[uses] user config**: ``rss_conf.rss_hf``.


Feature title is "RSS hash", it can be two things,
1. "Receive Side Scaling" support
2. Provide RSS hash to application

When this document first prepared RSS hash value was always provided to
the application when RSS enabled.
So intention with this feature was "Receive Side Scaling" support, hence
'RTE_ETH_MQ_RX_RSS_FLAG' added.

Later providing RSS has to the application separated as optimization,
'RTE_ETH_RX_OFFLOAD_RSS_HASH' & 'RTE_MBUF_F_RX_RSS_HASH' added for this
support.

What should I do for above two comments？
To tell application how to use it?


Just tried to give some context.



As the intention of this feature is "Receive Side Scaling" support, we
shouldn't reduce configuration struct to 'rss_conf.rss_hf'.

Instead perhaps can expand to:
'rte_eth_conf.rx_adv_conf.rss_conf', 'rte_eth_rss_conf'

  I just pick their common part.😁

ok, will fix it.




   * **[uses] rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
   * **[provides] rte_eth_dev_info**: ``flow_type_rss_offloads``.
   * **[provides] mbuf**: ``mbuf.ol_flags:RTE_MBUF_F_RX_RSS_HASH``,
``mbuf.rss``.
+* **[related]  API**: ``rte_eth_dev_configure``,
``rte_eth_dev_rss_hash_update``
+  ``rte_eth_dev_rss_hash_conf_get()``.
   

ack


     .. _nic_features_inner_rss:
@@ -288,7 +290,7 @@ Supports RSS hashing on RX.
   Inner RSS
   -
   -Supports RX RSS hashing on Inner headers.
+Supports RX RSS hashing on Inner headers by rte_flow API.
   

This should be clarified with details below, not sure if it required to
limit description to rte_flow.

But this block like rte_flow_action_rss is from rte_flow.
And ethdev ops doesn't support inner RSS.
So I think it is ok.


Yes it is supported by rte_flow, and '[uses]' information should already
clarify it.




And I guess similar confusion exist with the providing hash to user.
Need to check if rte_flow implementation puts hash to mbuf along with
doing the RSS, or if it checks 'RTE_ETH_RX_OFFLOAD_RSS_HASH' offload,
and update below items accordingly.

Do we need to tell user how to use it here?
I feel this document is a little simple and main to list interface for
user.
In addition, it is better that the more detail about RSS should be
presented  in rte_flow features.


No, I am not suggesting to add more detail.

My concern is 'RTE_ETH_RX_OFFLOAD_RSS_HASH' information may not be
correct, ethdev APIs checks offload flags, but does rte_flow
implementation check it?

My suggestion is double check that piece of information and fix it if
required.


Thinking twice, ethdev API or rte_flow or different ways to configure
RSS, but datapath that puts hash value to mbuf is same.
So same 'RTE_ETH_RX_OFFLOAD_RSS_HASH' check is used for both method, and
it is OK to have it documented.
There was a check for  RTE_ETH_RX_OFFLOAD_RSS_HASH in 
rte_eth_dev_configure().

This offload flag depends on the RTE_ETH_MQ_RX_RSS_FLAG mode.
As far as I know, ethdev ops allows to enable RSS hash only when 
RTE_ETH_MQ_RX_RSS_FLAG mode is set.

But rte flow API enable RSS hash doesn't depend on this MQ mode.
So I guess that the mbuf.ol_flags:RTE_MBUF_F_RX_RSS_HASH and mbuf.rss 
also be set to report application when create RSS hash flow, even if 
application don't set RTE_ETH_MQ_RX_RSS_FLAG mode by ethdev ops.







   * **[uses]    rte_flow_action_rss**: ``level``.
   * **[uses]    rte_eth_rxconf,rte_eth_rxmode**:
``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
@@ -303,9 +305,25 @@ RSS key update
   Supports configuration of Receive Side Scaling (RSS) hash
computation. Updating
   Receive Side Scaling (RSS) hash key.
   -* **[implements] eth_dev_ops**: ``rss_hash_update``,
``rss_hash_conf_get``.
+* **[implements] eth_dev_ops**: ``dev_configure``,
``rss_hash_update``, ``rss_hash_conf_get``.
+* **[uses] user config**: ``rss_conf.rss_key``,
``rss_conf.rss_key_len``
   * **[provides]   rte_eth_dev_info**: ``hash_key_size``.
-* **[related]    API**: ``rte_eth_dev_rss_hash_update()``,
+* **[related]    API**: ``rte_eth_dev_configure

Re: [PATCH v4 0/5] doc/features: fix some features and add new features

[lihuisong (C)]

在 2023/11/28 0:44, Ferruh Yigit 写道:

On 11/27/2023 2:16 PM, Huisong Li wrote:

The support for setting RSS hash algorithm has been introduced to 23.11,
but doesn't add feature for it. So this series add this feature to RSS hash
and perfect RSS other features by the way.

In addition, serval features or interface, like "set link up/down", "TM",
"link speeds" and "dump device private information" had beed supported,
but they are absent from the freatures list.

---
  -v4:
- fix RSS releated feaures description based on Ferruh
- add new features to default.ini
- remove loopback patch.
- move "dump device private information" to "dev ops" block.

  -v3:
- fix description of the patchset cover
- remove '/features' in 'doc/features' tag for every patch.
- add Acked-by: Chengwen Feng 
- retrigger CI build because of wrong CI warning

  -v2:
- add loopback mode feature.

Huisong Li (5):
   doc: fix the description of RSS related feature
   doc: add link up/down feature
   doc: add features for link speeds
   doc: add Traffic Manager feature
   doc: add dump device private information ops


As mentioned before I don't know about adding link speed feature or not,
would like to get more comment.

ok, let us to get more comment.
it is better that we send a separated patch about link speed feature to 
discuss and get more comment.

In this way, other patch in this series also go ahead to upload.
what do you think?


But for the new features added, driver .ini files also needs to be
updated for that new feature, and drivers support it should mark the
support.

agree.
I will add "Traffic Manager" feature to driver.ini for the supported TM 
driver.
But I'm not sure if I am supposed to do this in patch 4/5 or send 
independent patch for every supported driver.

what do you think of that?

That is why it is best to start documenting a feature when it is first
introduced, otherwise it is more work to update it later.

agree with you.
we should remind someone to add it to this feature doc when a new 
feature is introduced.


.

[PATCH] dmadev: support telemetry m2d auto free capa

[Chengwen Feng]

The m2d auto free capability was introduced in [1], but it lack the
support in telemetry.

[1] 877cb3e3742 dmadev: add buffer auto free offload

Signed-off-by: Chengwen Feng 
---
 lib/dmadev/rte_dmadev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
index 4e5e420c82..7729519f32 100644
--- a/lib/dmadev/rte_dmadev.c
+++ b/lib/dmadev/rte_dmadev.c
@@ -749,6 +749,7 @@ dma_capability_name(uint64_t capability)
{ RTE_DMA_CAPA_SVA, "sva" },
{ RTE_DMA_CAPA_SILENT,  "silent"  },
{ RTE_DMA_CAPA_HANDLES_ERRORS, "handles_errors" },
+   { RTE_DMA_CAPA_M2D_AUTO_FREE,  "m2d_auto_free"  },
{ RTE_DMA_CAPA_OPS_COPY,"copy"},
{ RTE_DMA_CAPA_OPS_COPY_SG, "copy_sg" },
{ RTE_DMA_CAPA_OPS_FILL,"fill"},
@@ -953,6 +954,7 @@ dmadev_handle_dev_info(const char *cmd __rte_unused,
ADD_CAPA(dma_caps, dev_capa, RTE_DMA_CAPA_SVA);
ADD_CAPA(dma_caps, dev_capa, RTE_DMA_CAPA_SILENT);
ADD_CAPA(dma_caps, dev_capa, RTE_DMA_CAPA_HANDLES_ERRORS);
+   ADD_CAPA(dma_caps, dev_capa, RTE_DMA_CAPA_M2D_AUTO_FREE);
ADD_CAPA(dma_caps, dev_capa, RTE_DMA_CAPA_OPS_COPY);
ADD_CAPA(dma_caps, dev_capa, RTE_DMA_CAPA_OPS_COPY_SG);
ADD_CAPA(dma_caps, dev_capa, RTE_DMA_CAPA_OPS_FILL);
-- 
2.17.1

Re: [PATCH v4 0/5] doc/features: fix some features and add new features

[lihuisong (C)]

在 2023/11/28 0:56, Ferruh Yigit 写道:

On 11/27/2023 2:16 PM, Huisong Li wrote:

The support for setting RSS hash algorithm has been introduced to 23.11,
but doesn't add feature for it. So this series add this feature to RSS hash
and perfect RSS other features by the way.

In addition, serval features or interface, like "set link up/down", "TM",
"link speeds" and "dump device private information" had beed supported,
but they are absent from the freatures list.

---
  -v4:
- fix RSS releated feaures description based on Ferruh
- add new features to default.ini
- remove loopback patch.
- move "dump device private information" to "dev ops" block.

  -v3:
- fix description of the patchset cover
- remove '/features' in 'doc/features' tag for every patch.
- add Acked-by: Chengwen Feng 
- retrigger CI build because of wrong CI warning

  -v2:
- add loopback mode feature.

Huisong Li (5):
   doc: fix the description of RSS related feature
   doc: add link up/down feature
   doc: add features for link speeds
   doc: add Traffic Manager feature
   doc: add dump device private information ops


Please check the warning on document generation:
https://mails.dpdk.org/archives/test-report/2023-November/519586.html

/home/runner/work/dpdk/dpdk/doc/guides/nics/features.rst:307:Unexpected
indentation.

Here has a format issue. I will fix it next version.
Thanks.


.

Re: [PATCH 0/3] fix some bug for hns3

[Jie Hai]

On 2023/11/28 2:33, Ferruh Yigit wrote:

On 11/27/2023 1:55 PM, Jie Hai wrote:

On 2023/11/27 21:39, Dengdui Huang wrote:

Dengdui Huang (3):
    net/hns3: fix reset detect be ignored
    net/hns3: fix VF wrong clear reset status
    net/hns3: fix the VF reset interrupted possibly

Hi, Dengdui,

Good fix.
For the patchset,
Acked-by: Jie Hai 




Hi Jie, Dengdui, is this set for this release, which is a few days away?
My suggestion is to wait next version as issues doesn't look critical.


I applied set to next-net, but leaving decision to pull it for the
release or not to Thomas/David.

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


Hi, Ferruh, Thomas and David,

I'm sorry that this problem is a little serious.

a) Without [PATCH 2/3], when the VF executes the 
hns3_clear_reset_event(), unexpected memory is written.
As a result, unexpected errors occur in the program or even the app may 
crash.
b) Without [PATCH 3/3], there is a low probability that the app is 
unavailable after the FLR reset is done.

c) In addition, some LTS versions have the same problem.

Therefore, we hope that the problem can be solved in the current version.

Thanks,
Jie Hai

.

Re: [PATCH v4 0/5] doc/features: fix some features and add new features

[lihuisong (C)]

在 2023/11/28 10:09, lihuisong (C) 写道:


在 2023/11/28 0:44, Ferruh Yigit 写道:

On 11/27/2023 2:16 PM, Huisong Li wrote:
The support for setting RSS hash algorithm has been introduced to 
23.11,
but doesn't add feature for it. So this series add this feature to 
RSS hash

and perfect RSS other features by the way.

In addition, serval features or interface, like "set link up/down", 
"TM",

"link speeds" and "dump device private information" had beed supported,
but they are absent from the freatures list.

---
  -v4:
    - fix RSS releated feaures description based on Ferruh
    - add new features to default.ini
    - remove loopback patch.
    - move "dump device private information" to "dev ops" block.

  -v3:
    - fix description of the patchset cover
    - remove '/features' in 'doc/features' tag for every patch.
    - add Acked-by: Chengwen Feng 
    - retrigger CI build because of wrong CI warning

  -v2:
    - add loopback mode feature.

Huisong Li (5):
   doc: fix the description of RSS related feature
   doc: add link up/down feature
   doc: add features for link speeds
   doc: add Traffic Manager feature
   doc: add dump device private information ops


As mentioned before I don't know about adding link speed feature or not,
would like to get more comment.

ok, let us to get more comment.
it is better that we send a separated patch about link speed feature 
to discuss and get more comment.

In this way, other patch in this series also go ahead to upload.
what do you think?


But for the new features added, driver .ini files also needs to be
updated for that new feature, and drivers support it should mark the
support.

agree.
I will add "Traffic Manager" feature to driver.ini for the supported 
TM driver.
But I'm not sure if I am supposed to do this in patch 4/5 or send 
independent patch for every supported driver.
Thinking twice, I will separate this "TM" patch from this series and 
send a independent patchset to do this.

Then we can take a look at that series.

what do you think of that?

That is why it is best to start documenting a feature when it is first
introduced, otherwise it is more work to update it later.

agree with you.
we should remind someone to add it to this feature doc when a new 
feature is introduced.


.

.

Re: DPDK Release Status Meeting 2023-11-23

[Ruifeng Wang]

On 2023/11/28 1:16 AM, Stephen Hemminger wrote:

On Mon, 27 Nov 2023 11:13:16 +0100
Thomas Monjalon  wrote:


ish.


Due to a relative bigger RTE_MAX_LCORE value on ARM, the unit test case
would take a longer time to finish iterations.
In one of my run, the case took about 100s.


Right, but this test is part of the "fast suite", and more than a
minute is not exactly fast. So one of the following should ideally
happen:


Agree.
   

1) Test is moved out of the fast suite
2) Test has its individual timeout sized appropriately so that it
never fails regardless of the environment
3) Test is capped so that it doesn't grow with the number of cores
without limits


I'm for option 3. The case should be kept in fast suite. Time taken
should be capped.


More than 1 second is a bit slow.
Please make the test really faster.


What is the test trying to exercise? Can it be done in another way?


The time consuming part is non-EAL test. It creates non-EAL threads 
until filling up RTE_MAX_LCORE.


This part can be a separate case outside of fast suite.

[PATCH v5 0/3] doc/features: fix some features and add new features

[Huisong Li]

The support for setting RSS hash algorithm has been introduced to 23.11,
but doesn't add feature for it. So this series add this feature to RSS hash
and perfect RSS other features by the way.

In addition, "set link up/down" and "dump device private information" had
beed supported, but they are absent from the freatures list.

---
 -v5:
   - separate "link speed" and "Traffic Manager" feature from this series
   - fix CI warning 

 -v4:
   - fix RSS releated feaures description based on Ferruh
   - add new features to default.ini
   - remove loopback patch.
   - move "dump device private information" to "dev ops" block.

 -v3:
   - fix description of the patchset cover
   - remove '/features' in 'doc/features' tag for every patch.
   - add Acked-by: Chengwen Feng 
   - retrigger CI build because of wrong CI warning

 -v2:
   - add loopback mode feature.

Huisong Li (3):
  doc: fix the description of RSS related feature
  doc: add link up/down feature
  doc: add dump device private information ops

 doc/guides/nics/features.rst | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

-- 
2.33.0

[PATCH v5 2/3] doc: add link up/down feature

[Huisong Li]

Add link up/down feature for features.rst.

Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Acked-by: Chengwen Feng 
Acked-by: Ferruh Yigit 
---
 doc/guides/nics/features.rst | 4 
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 18b4c9637e..ced400beba 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -45,6 +45,10 @@ Supports getting the link speed, duplex mode and link state 
(up/down).
 * **[implements] rte_eth_dev_data**: ``dev_link``.
 * **[related]API**: ``rte_eth_link_get()``, ``rte_eth_link_get_nowait()``.
 
+Set link up/down an Ethernet device.
+
+* **[implements] eth_dev_ops**: ``dev_set_link_up``, ``dev_set_link_down``.
+* **[related]API**: ``rte_eth_dev_set_link_up()``, 
``rte_eth_dev_set_link_down()``.
 
 .. _nic_features_link_status_event:
 
-- 
2.33.0

[PATCH v5 3/3] doc: add dump device private information ops

[Huisong Li]

Add dump device private information to dev ops.

Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Acked-by: Chengwen Feng 
Acked-by: Ferruh Yigit 
---
 doc/guides/nics/features.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index ced400beba..96a6f11ee3 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -982,3 +982,4 @@ Other dev ops not represented by a Feature
 * ``udp_tunnel_port_add``
 * ``udp_tunnel_port_del``
 * ``tx_pkt_prepare``
+* ``eth_dev_priv_dump``
-- 
2.33.0

[PATCH v5 1/3] doc: fix the description of RSS related feature

[Huisong Li]

This patch fixes the description of RSS feature.
And the settinf ot hash algorithm is introduced by 23.11, so add it.

Fixes: 34ff088cc241 ("ethdev: set and query RSS hash algorithm")

Signed-off-by: Huisong Li 
Acked-by: Chengwen Feng 
Acked-by: Ferruh Yigit 
---
 doc/guides/nics/features.rst | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 1a1dc16c1e..18b4c9637e 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -277,10 +277,20 @@ RSS hash
 Supports RSS hashing on RX.
 
 * **[uses] user config**: ``dev_conf.rxmode.mq_mode`` = 
``RTE_ETH_MQ_RX_RSS_FLAG``.
-* **[uses] user config**: ``dev_conf.rx_adv_conf.rss_conf``.
+* **[uses] user config**: ``dev_conf.rx_adv_conf.rss_conf.rss_hf``. 
``rss_conf.rss_hf``
 * **[uses] rte_eth_rxconf,rte_eth_rxmode**: 
``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
 * **[provides] rte_eth_dev_info**: ``flow_type_rss_offloads``.
 * **[provides] mbuf**: ``mbuf.ol_flags:RTE_MBUF_F_RX_RSS_HASH``, ``mbuf.rss``.
+* **[related]  API**: ``rte_eth_dev_configure()``, 
``rte_eth_dev_rss_hash_update``
+  ``rte_eth_dev_rss_hash_conf_get()``.
+
+Support RSS hash algorithm on Rx.
+
+* **[implements] eth_dev_ops**: ``dev_configure``, ``rss_hash_update``, 
``rss_hash_conf_get``.
+* **[uses] user config**: ``rss_conf.algorithm``
+* **[provides]   rte_eth_dev_info**: ``rss_algo_capa``.
+* **[related]API**: ``rte_eth_dev_configure()``, 
``rte_eth_dev_rss_hash_update()``,
+  ``rte_eth_dev_rss_hash_conf_get()``.
 
 
 .. _nic_features_inner_rss:
@@ -288,7 +298,7 @@ Supports RSS hashing on RX.
 Inner RSS
 -
 
-Supports RX RSS hashing on Inner headers.
+Supports RX RSS hashing on Inner headers by rte_flow API.
 
 * **[uses]rte_flow_action_rss**: ``level``.
 * **[uses]rte_eth_rxconf,rte_eth_rxmode**: 
``offloads:RTE_ETH_RX_OFFLOAD_RSS_HASH``.
@@ -303,9 +313,10 @@ RSS key update
 Supports configuration of Receive Side Scaling (RSS) hash computation. Updating
 Receive Side Scaling (RSS) hash key.
 
-* **[implements] eth_dev_ops**: ``rss_hash_update``, ``rss_hash_conf_get``.
+* **[implements] eth_dev_ops**: ``dev_configure``, ``rss_hash_update``, 
``rss_hash_conf_get``.
+* **[uses] user config**: ``rss_conf.rss_key``, ``rss_conf.rss_key_len``
 * **[provides]   rte_eth_dev_info**: ``hash_key_size``.
-* **[related]API**: ``rte_eth_dev_rss_hash_update()``,
+* **[related]API**: ``rte_eth_dev_configure()``, 
``rte_eth_dev_rss_hash_update()``,
   ``rte_eth_dev_rss_hash_conf_get()``.
 
 
-- 
2.33.0

[PATCH 01/11] doc: add Traffic Manager feature

[Huisong Li]

Add Traffic Manager feature.

Fixes: 5d109deffa87 ("ethdev: add traffic management API")
Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
Acked-by: Chengwen Feng 
---
 doc/guides/nics/features.rst | 13 +
 doc/guides/nics/features/default.ini |  1 +
 2 files changed, 14 insertions(+)

diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst
index 96a6f11ee3..9e2105d3ea 100644
--- a/doc/guides/nics/features.rst
+++ b/doc/guides/nics/features.rst
@@ -755,6 +755,19 @@ Supports congestion management.
   ``rte_eth_cman_config_set()``, ``rte_eth_cman_config_get()``.
 
 
+.. _nic_features_traffic_manager:
+
+Traffic manager
+---
+
+Supports Traffic manager.
+
+* **[implements] rte_tm_ops**: ``capabilities_get``, ``shaper_profile_add``,
+  ``hierarchy_commit`` and so on.
+* **[related]API**: ``rte_tm_capabilities_get()``, 
``rte_tm_shaper_profile_add()``,
+  ``rte_tm_hierarchy_commit()`` and so on.
+
+
 .. _nic_features_fw_version:
 
 FW version
diff --git a/doc/guides/nics/features/default.ini 
b/doc/guides/nics/features/default.ini
index 806cb033ff..64ee0f8c2f 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -42,6 +42,7 @@ VLAN filter  =
 Flow control =
 Rate limitation  =
 Congestion management =
+Traffic manager  =
 Inline crypto=
 Inline protocol  =
 CRC offload  =
-- 
2.33.0

[PATCH 02/11] doc: add Traffic Manager feature for iavf

[Huisong Li]

Add Traffic Manager feature for iavf.

Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
---
 doc/guides/nics/features/iavf.ini | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/nics/features/iavf.ini 
b/doc/guides/nics/features/iavf.ini
index db4f92ce71..385799c650 100644
--- a/doc/guides/nics/features/iavf.ini
+++ b/doc/guides/nics/features/iavf.ini
@@ -35,6 +35,7 @@ Inner L4 checksum= Y
 Packet type parsing  = Y
 Rx descriptor status = Y
 Tx descriptor status = Y
+Traffic manager  = Y
 Inline crypto= Y
 Basic stats  = Y
 Multiprocess aware   = Y
-- 
2.33.0

[PATCH 03/11] doc: add Traffic Manager feature for i40e

[Huisong Li]

Add Traffic Manager feature for i40e.

Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
---
 doc/guides/nics/features/i40e.ini | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/nics/features/i40e.ini 
b/doc/guides/nics/features/i40e.ini
index e241dad047..2d168199f0 100644
--- a/doc/guides/nics/features/i40e.ini
+++ b/doc/guides/nics/features/i40e.ini
@@ -27,6 +27,7 @@ SR-IOV   = Y
 DCB  = Y
 VLAN filter  = Y
 Flow control = Y
+Traffic manager  = Y
 CRC offload  = Y
 VLAN offload = Y
 QinQ offload = P
-- 
2.33.0

[PATCH 04/11] doc: add Traffic Manager feature for ixgbe

[Huisong Li]

Add Traffic Manager feature for ixgbe.

Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
---
 doc/guides/nics/features/ixgbe.ini | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/nics/features/ixgbe.ini 
b/doc/guides/nics/features/ixgbe.ini
index 8590ac857f..f05fcec455 100644
--- a/doc/guides/nics/features/ixgbe.ini
+++ b/doc/guides/nics/features/ixgbe.ini
@@ -27,6 +27,7 @@ DCB  = Y
 VLAN filter  = Y
 Flow control = Y
 Rate limitation  = Y
+Traffic manager  = Y
 Inline crypto= Y
 CRC offload  = P
 VLAN offload = P
-- 
2.33.0

[PATCH 00/11] add Traffic Manager feature

[Huisong Li]

The traffic management API has been introduced for a long time, please see
commit 5d109deffa87 ("ethdev: add traffic management API").
And many PMD also support this feature. So this series add this feature to
features.rst, default.ini and driver.ini.

Huisong Li (11):
  doc: add Traffic Manager feature
  doc: add Traffic Manager feature for iavf
  doc: add Traffic Manager feature for i40e
  doc: add Traffic Manager feature for ixgbe
  doc: add Traffic Manager feature for cnxk
  doc: add Traffic Manager feature for hns3
  doc: add Traffic Manager feature for txgbe
  doc: add Traffic Manager feature for mvpp2
  doc: add Traffic Manager feature for dpaa2
  doc: add Traffic Manager feature for ipn3ke
  doc: add Traffic Manager feature for ice

 doc/guides/nics/features.rst | 13 +
 doc/guides/nics/features/cnxk.ini|  1 +
 doc/guides/nics/features/default.ini |  1 +
 doc/guides/nics/features/dpaa2.ini   |  1 +
 doc/guides/nics/features/hns3.ini|  1 +
 doc/guides/nics/features/i40e.ini|  1 +
 doc/guides/nics/features/iavf.ini|  1 +
 doc/guides/nics/features/ice.ini |  1 +
 doc/guides/nics/features/ice_dcf.ini |  1 +
 doc/guides/nics/features/ipn3ke.ini  |  1 +
 doc/guides/nics/features/ixgbe.ini   |  1 +
 doc/guides/nics/features/mvpp2.ini   |  1 +
 doc/guides/nics/features/txgbe.ini   |  1 +
 13 files changed, 25 insertions(+)

-- 
2.33.0

[PATCH 05/11] doc: add Traffic Manager feature for cnxk

[Huisong Li]

Add Traffic Manager feature for cnxk.

Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
---
 doc/guides/nics/features/cnxk.ini | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/nics/features/cnxk.ini 
b/doc/guides/nics/features/cnxk.ini
index ac7de9a0f0..f85813ab52 100644
--- a/doc/guides/nics/features/cnxk.ini
+++ b/doc/guides/nics/features/cnxk.ini
@@ -28,6 +28,7 @@ RSS key update   = Y
 RSS reta update  = Y
 Inner RSS= Y
 Congestion management = Y
+Traffic manager  = Y
 Inline protocol  = Y
 Flow control = Y
 Scattered Rx = Y
-- 
2.33.0

[PATCH 06/11] doc: add Traffic Manager feature for hns3

[Huisong Li]

Add Traffic Manager feature for hns3.

Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
---
 doc/guides/nics/features/hns3.ini | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/nics/features/hns3.ini 
b/doc/guides/nics/features/hns3.ini
index 338b4e6864..a20ece20e8 100644
--- a/doc/guides/nics/features/hns3.ini
+++ b/doc/guides/nics/features/hns3.ini
@@ -28,6 +28,7 @@ RSS reta update  = Y
 DCB  = Y
 VLAN filter  = Y
 Flow control = Y
+Traffic manager  = Y
 CRC offload  = Y
 VLAN offload = Y
 FEC  = Y
-- 
2.33.0

[PATCH 07/11] doc: add Traffic Manager feature for txgbe

[Huisong Li]

Add Traffic Manager feature for txgbe.

Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
---
 doc/guides/nics/features/txgbe.ini | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/nics/features/txgbe.ini 
b/doc/guides/nics/features/txgbe.ini
index e21083052c..3a11fb2037 100644
--- a/doc/guides/nics/features/txgbe.ini
+++ b/doc/guides/nics/features/txgbe.ini
@@ -26,6 +26,7 @@ DCB  = Y
 VLAN filter  = Y
 Flow control = Y
 Rate limitation  = Y
+Traffic manager  = Y
 Inline crypto= Y
 CRC offload  = P
 VLAN offload = P
-- 
2.33.0

[PATCH 08/11] doc: add Traffic Manager feature for mvpp2

[Huisong Li]

Add Traffic Manager feature for mvpp2.

Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
---
 doc/guides/nics/features/mvpp2.ini | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/nics/features/mvpp2.ini 
b/doc/guides/nics/features/mvpp2.ini
index 653c9d08cb..69767d6317 100644
--- a/doc/guides/nics/features/mvpp2.ini
+++ b/doc/guides/nics/features/mvpp2.ini
@@ -13,6 +13,7 @@ Unicast MAC filter   = Y
 Multicast MAC filter = Y
 RSS hash = Y
 Flow control = Y
+Traffic manager  = Y
 VLAN filter  = Y
 CRC offload  = Y
 L3 checksum offload  = Y
-- 
2.33.0

[PATCH 09/11] doc: add Traffic Manager feature for dpaa2

[Huisong Li]

Add Traffic Manager feature for dpaa2.

Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
---
 doc/guides/nics/features/dpaa2.ini | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/nics/features/dpaa2.ini 
b/doc/guides/nics/features/dpaa2.ini
index 26dc8c2178..f02da463d9 100644
--- a/doc/guides/nics/features/dpaa2.ini
+++ b/doc/guides/nics/features/dpaa2.ini
@@ -17,6 +17,7 @@ Unicast MAC filter   = Y
 RSS hash = Y
 VLAN filter  = Y
 Flow control = Y
+Traffic manager  = Y
 VLAN offload = Y
 L3 checksum offload  = Y
 L4 checksum offload  = Y
-- 
2.33.0

[PATCH 10/11] doc: add Traffic Manager feature for ipn3ke

[Huisong Li]

Add Traffic Manager feature for ipn3ke.

Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
---
 doc/guides/nics/features/ipn3ke.ini | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/guides/nics/features/ipn3ke.ini 
b/doc/guides/nics/features/ipn3ke.ini
index 1f6b780273..e412978820 100644
--- a/doc/guides/nics/features/ipn3ke.ini
+++ b/doc/guides/nics/features/ipn3ke.ini
@@ -25,6 +25,7 @@ SR-IOV   = Y
 DCB  = Y
 VLAN filter  = Y
 Flow control = Y
+Traffic manager  = Y
 CRC offload  = Y
 VLAN offload = Y
 QinQ offload = Y
-- 
2.33.0

[PATCH 11/11] doc: add Traffic Manager feature for ice

[Huisong Li]

Add Traffic Manager feature for ice.

Cc: sta...@dpdk.org

Signed-off-by: Huisong Li 
---
 doc/guides/nics/features/ice.ini | 1 +
 doc/guides/nics/features/ice_dcf.ini | 1 +
 2 files changed, 2 insertions(+)

diff --git a/doc/guides/nics/features/ice.ini b/doc/guides/nics/features/ice.ini
index 13f8871dcc..d26ab7e6a9 100644
--- a/doc/guides/nics/features/ice.ini
+++ b/doc/guides/nics/features/ice.ini
@@ -25,6 +25,7 @@ Unicast MAC filter   = Y
 RSS hash = Y
 RSS key update   = Y
 RSS reta update  = Y
+Traffic manager  = Y
 VLAN filter  = Y
 CRC offload  = Y
 VLAN offload = Y
diff --git a/doc/guides/nics/features/ice_dcf.ini 
b/doc/guides/nics/features/ice_dcf.ini
index 3b11622d4c..210c08fc9a 100644
--- a/doc/guides/nics/features/ice_dcf.ini
+++ b/doc/guides/nics/features/ice_dcf.ini
@@ -21,6 +21,7 @@ MTU update   = Y
 Promiscuous mode = Y
 Allmulticast mode= Y
 Unicast MAC filter   = Y
+Traffic manager  = Y
 VLAN filter  = Y
 VLAN offload = Y
 Extended stats   = Y
-- 
2.33.0

RE: [PATCH v4 10/10] common/dpaxx: remove zero length array

[Hemant Agrawal]

Acked-by: Hemant Agrawal 

> -Original Message-
> From: Stephen Hemminger 
> Sent: Friday, November 24, 2023 12:49 AM
> To: Hemant Agrawal 
> Cc: Tyler Retzlaff ; dev@dpdk.org; Sachin
> Saxena ; Gagandeep Singh 
> Subject: Re: [PATCH v4 10/10] common/dpaxx: remove zero length array
> Importance: High
> 
> This is a better alternative.
> 
> From 52c805b9526dbef62377276c4499c997fbc96268 Mon Sep 17 00:00:00
> 2001
> From: Stephen Hemminger 
> Date: Thu, 23 Nov 2023 11:12:02 -0800
> Subject: [PATCH] common/dpaxx: replace zero length array
> 
> The zero length ip_header is used as an overlay to the encap IP header. Since
> the code is already assuming the layout of the structure, replace the array
> with direct access.
> 
> Signed-off-by: Stephen Hemminger 
> ---
>  drivers/common/dpaax/caamflib/desc/ipsec.h | 20 ++--
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/common/dpaax/caamflib/desc/ipsec.h
> b/drivers/common/dpaax/caamflib/desc/ipsec.h
> index 95fc3ea5ba3b..d1411cc6aab4 100644
> --- a/drivers/common/dpaax/caamflib/desc/ipsec.h
> +++ b/drivers/common/dpaax/caamflib/desc/ipsec.h
> @@ -334,9 +334,7 @@ struct ipsec_encap_gcm {
>   * @seq_num: IPsec sequence number
>   * @spi: IPsec SPI (Security Parameters Index)
>   * @ip_hdr_len: optional IP Header length (in bytes)
> - *  reserved - 16b
> - *  Opt. IP Hdr Len - 16b
> - * @ip_hdr: optional IP Header content (only for IPsec legacy mode)
> + *  Ip header must follow directly after ipsec_encap_pdb
>   */
>  struct ipsec_encap_pdb {
>   uint32_t options;
> @@ -350,7 +348,6 @@ struct ipsec_encap_pdb {
>   };
>   uint32_t spi;
>   uint32_t ip_hdr_len;
> - uint8_t ip_hdr[0];
>  };
> 
>  static inline unsigned int
> @@ -776,7 +773,12 @@ cnstr_shdsc_ipsec_encap(uint32_t *descbuf, bool
> ps, bool swap,
>   PROGRAM_SET_36BIT_ADDR(p);
>   phdr = SHR_HDR(p, share, hdr, 0);
>   __rta_copy_ipsec_encap_pdb(p, pdb, cipherdata->algtype);
> - COPY_DATA(p, pdb->ip_hdr, pdb->ip_hdr_len);
> +
> + /* ip header if any follows the encap_pdb */
> + if (pdb->ip_hdr_len > 0) {
> + void *ip_hdr = pdb + 1;
> + COPY_DATA(p, ip_hdr, pdb->ip_hdr_len);
> + }
>   SET_LABEL(p, hdr);
>   pkeyjmp = JUMP(p, keyjmp, LOCAL_JUMP, ALL_TRUE, BOTH|SHRD);
>   if (authdata->keylen)
> @@ -913,7 +915,13 @@ cnstr_shdsc_ipsec_encap_des_aes_xcbc(uint32_t
> *descbuf,
>   PROGRAM_CNTXT_INIT(p, descbuf, 0);
>   phdr = SHR_HDR(p, share, hdr, 0);
>   __rta_copy_ipsec_encap_pdb(p, pdb, cipherdata->algtype);
> - COPY_DATA(p, pdb->ip_hdr, pdb->ip_hdr_len);
> +
> + /* ip header if any follows the encap_pdb */
> + if (pdb->ip_hdr_len > 0) {
> + void *ip_hdr = pdb + 1;
> + COPY_DATA(p, ip_hdr, pdb->ip_hdr_len);
> + }
> +
>   SET_LABEL(p, hdr);
>   pkeyjump = JUMP(p, keyjump, LOCAL_JUMP, ALL_TRUE, SHRD |
> SELF);
>   /*
> --
> 2.42.0

RE: [PATCH 10/11] doc: add Traffic Manager feature for ipn3ke

[Xu, Rosen]

Hi,

> -Original Message-
> From: Huisong Li 
> Sent: Tuesday, November 28, 2023 2:10 PM
> To: dev@dpdk.org; ferruh.yi...@amd.com; tho...@monjalon.net; Xu,
> Rosen 
> Cc: liuyongl...@huawei.com; lihuis...@huawei.com
> Subject: [PATCH 10/11] doc: add Traffic Manager feature for ipn3ke
> 
> Add Traffic Manager feature for ipn3ke.
> 
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Huisong Li 
> ---
>  doc/guides/nics/features/ipn3ke.ini | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/doc/guides/nics/features/ipn3ke.ini
> b/doc/guides/nics/features/ipn3ke.ini
> index 1f6b780273..e412978820 100644
> --- a/doc/guides/nics/features/ipn3ke.ini
> +++ b/doc/guides/nics/features/ipn3ke.ini
> @@ -25,6 +25,7 @@ SR-IOV   = Y
>  DCB  = Y
>  VLAN filter  = Y
>  Flow control = Y
> +Traffic manager  = Y
>  CRC offload  = Y
>  VLAN offload = Y
>  QinQ offload = Y
> --
> 2.33.0

Acked-by: Rosen Xu