[dpdk-dev] [PATCH v2] net/ice: fix queue config in DCF

[Jie Wang]

When DCF configures rx_queues, it may cause the pointer of
rx_queues to go out of bounds.

This patch expands the scope of the judgment condition to
fix this issue.

Fixes: 4b0d391f0eab ("net/ice: add queue config in DCF")
Cc: sta...@dpdk.org

Signed-off-by: Jie Wang 
---
v2: assign values to rxq.vsi_id and rxq.queue_id, ensure rxq.vsi_id
is equal to txq.vsi_id and rxq.queue_id is equal to txq.queue_id.
---
 drivers/net/ice/ice_dcf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ice/ice_dcf.c b/drivers/net/ice/ice_dcf.c
index 4c2e0c7216..a68b355cb8 100644
--- a/drivers/net/ice/ice_dcf.c
+++ b/drivers/net/ice/ice_dcf.c
@@ -882,11 +882,11 @@ ice_dcf_configure_queues(struct ice_dcf_hw *hw)
}
vc_qp->rxq.vsi_id = hw->vsi_res->vsi_id;
vc_qp->rxq.queue_id = i;
-   vc_qp->rxq.max_pkt_size = rxq[i]->max_pkt_len;
 
if (i >= hw->eth_dev->data->nb_rx_queues)
continue;
 
+   vc_qp->rxq.max_pkt_size = rxq[i]->max_pkt_len;
vc_qp->rxq.ring_len = rxq[i]->nb_rx_desc;
vc_qp->rxq.dma_ring_addr = rxq[i]->rx_ring_dma;
vc_qp->rxq.databuffer_size = rxq[i]->rx_buf_len;
-- 
2.25.1

[dpdk-dev] [PATCH RFC 1/2] net/ice/base: add VXLAN support for switch filter

[Yuying Zhang]

Add ipv4/ipv6 vxlan any support in switch filter. Add inner ipv6 and
outer ipv6 support of vxlan protocol in switch filter.

Signed-off-by: Yuying Zhang 
---
 drivers/net/ice/base/ice_protocol_type.h |   6 +
 drivers/net/ice/base/ice_switch.c| 212 ++-
 drivers/net/ice/base/ice_switch.h|  12 ++
 3 files changed, 229 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ice/base/ice_protocol_type.h 
b/drivers/net/ice/base/ice_protocol_type.h
index cef8354f77..599b4baba6 100644
--- a/drivers/net/ice/base/ice_protocol_type.h
+++ b/drivers/net/ice/base/ice_protocol_type.h
@@ -112,6 +112,12 @@ enum ice_sw_tunnel_type {
ICE_SW_TUN_IPV6_NAT_T,
ICE_SW_TUN_IPV4_L2TPV3,
ICE_SW_TUN_IPV6_L2TPV3,
+   ICE_SW_TUN_PROFID_IPV4_VXLAN_IPV4,
+   ICE_SW_TUN_PROFID_IPV4_VXLAN_IPV6,
+   ICE_SW_TUN_PROFID_IPV6_VXLAN_IPV4,
+   ICE_SW_TUN_PROFID_IPV6_VXLAN_IPV6,
+   ICE_SW_TUN_PROFID_IPV4_VXLAN,
+   ICE_SW_TUN_PROFID_IPV6_VXLAN,
ICE_SW_TUN_PROFID_IPV6_ESP,
ICE_SW_TUN_PROFID_IPV6_AH,
ICE_SW_TUN_PROFID_MAC_IPV6_L2TPV3,
diff --git a/drivers/net/ice/base/ice_switch.c 
b/drivers/net/ice/base/ice_switch.c
index 9179f66c20..6a278c1bbb 100644
--- a/drivers/net/ice/base/ice_switch.c
+++ b/drivers/net/ice/base/ice_switch.c
@@ -180,6 +180,62 @@ static const u8 dummy_udp_tun_tcp_packet[] = {
0x00, 0x00, 0x00, 0x00
 };
 
+static const struct ice_dummy_pkt_offsets 
dummy_udp_tun_ipv6_tcp_packet_offsets[] = {
+   { ICE_MAC_OFOS, 0 },
+   { ICE_ETYPE_OL, 12 },
+   { ICE_IPV4_OFOS,14 },
+   { ICE_UDP_OF,   34 },
+   { ICE_VXLAN,42 },
+   { ICE_GENEVE,   42 },
+   { ICE_VXLAN_GPE,42 },
+   { ICE_MAC_IL,   50 },
+   { ICE_IPV6_IL,  64 },
+   { ICE_TCP_IL,   104 },
+   { ICE_PROTOCOL_LAST,0 },
+};
+
+static const u8 dummy_udp_tun_ipv6_tcp_packet[] = {
+   0x00, 0x00, 0x00, 0x00,  /* ICE_MAC_OFOS 0 */
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+
+   0x08, 0x00, /* ICE_ETYPE_OL 12 */
+
+   0x45, 0x00, 0x00, 0x5a, /* ICE_IPV4_OFOS 14 */
+   0x00, 0x01, 0x00, 0x00,
+   0x40, 0x11, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+
+   0x00, 0x00, 0x12, 0xb5, /* ICE_UDP_OF 34 */
+   0x00, 0x46, 0x00, 0x00,
+
+   0x00, 0x00, 0x65, 0x58, /* ICE_VXLAN 42 */
+   0x00, 0x00, 0x00, 0x00,
+
+   0x00, 0x00, 0x00, 0x00, /* ICE_MAC_IL 50 */
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x86, 0xdd,
+
+   0x60, 0x00, 0x00, 0x00, /* ICE_IPV4_IL 64 */
+   0x00, 0x00, 0x06, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+
+   0x00, 0x00, 0x00, 0x00, /* ICE_TCP_IL 104 */
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x50, 0x02, 0x20, 0x00,
+   0x00, 0x00, 0x00, 0x00
+};
+
 static const struct ice_dummy_pkt_offsets dummy_udp_tun_udp_packet_offsets[] = 
{
{ ICE_MAC_OFOS, 0 },
{ ICE_ETYPE_OL, 12 },
@@ -228,6 +284,59 @@ static const u8 dummy_udp_tun_udp_packet[] = {
0x00, 0x08, 0x00, 0x00,
 };
 
+static const struct ice_dummy_pkt_offsets 
dummy_udp_tun_ipv6_udp_packet_offsets[] = {
+   { ICE_MAC_OFOS, 0 },
+   { ICE_ETYPE_OL, 12 },
+   { ICE_IPV4_OFOS,14 },
+   { ICE_UDP_OF,   34 },
+   { ICE_VXLAN,42 },
+   { ICE_GENEVE,   42 },
+   { ICE_VXLAN_GPE,42 },
+   { ICE_MAC_IL,   50 },
+   { ICE_IPV6_IL,  64 },
+   { ICE_UDP_ILOS, 104 },
+   { ICE_PROTOCOL_LAST,0 },
+};
+
+static const u8 dummy_udp_tun_ipv6_udp_packet[] = {
+   0x00, 0x00, 0x00, 0x00,  /* ICE_MAC_OFOS 0 */
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+
+   0x08, 0x00, /* ICE_ETYPE_OL 12 */
+
+   0x45, 0x00, 0x00, 0x4e, /* ICE_IPV4_OFOS 14 */
+   0x00, 0x01, 0x00, 0x00,
+   0x00, 0x11, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+
+   0x00, 0x00, 0x12, 0xb5, /* ICE_UDP_OF 34 */
+   0x00, 0x3a, 0x00, 0x00,
+
+   0x00, 0x00, 0x65, 0x58, /* ICE_VXLAN 42 */
+   0x00, 0x00, 0x00, 0x00,
+
+   0x00, 0x00, 0x00, 0x00, /* ICE_MAC_IL 50 */
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x86, 0xdd,
+
+   0x60, 0x00, 0x00, 0x00, /* ICE_IPV6_IL 64 */
+   0x00, 0x58, 0x11, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0x00, 0x00, 0x00, 0x00,
+   0

[dpdk-dev] [PATCH RFC 2/2] net/ice: add support of VXLAN in switch filter

[Yuying Zhang]

Add support of ipv4/ipv6 vxlan any pattern and outer/inner
ipv6 vxlan pattern in switch filter. All patterns support no
input set.

+-++
| Pattern | Input Set  |
+-++
| pattern_eth_ipv4_udp_vxlan_any  | dst mac|
| pattern_eth_ipv6_udp_vxlan_any  | dst mac|
| pattern_eth_ipv4_udp_vxlan_eth_ipv4 | dst mac, vni, inner dst/src ip |
| pattern_eth_ipv4_udp_vxlan_eth_ipv6 | dst mac, vni, inner dst/src ip |
| pattern_eth_ipv6_udp_vxlan_eth_ipv4 | dst mac, vni, inner dst/src ip |
| pattern_eth_ipv6_udp_vxlan_eth_ipv6 | dst mac, vni, inner dst/src ip |
+-++

Signed-off-by: Yuying Zhang 
---
 drivers/net/ice/ice_generic_flow.c  | 33 +---
 drivers/net/ice/ice_generic_flow.h  |  6 +
 drivers/net/ice/ice_switch_filter.c | 40 ++---
 3 files changed, 72 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ice/ice_generic_flow.c 
b/drivers/net/ice/ice_generic_flow.c
index 66b5743abf..29a5df69cb 100644
--- a/drivers/net/ice/ice_generic_flow.c
+++ b/drivers/net/ice/ice_generic_flow.c
@@ -364,6 +364,26 @@ enum rte_flow_item_type 
pattern_eth_ipv4_udp_vxlan_ipv4_icmp[] = {
RTE_FLOW_ITEM_TYPE_END,
 };
 
+/* IPv4 VXLAN ANY */
+enum rte_flow_item_type pattern_eth_ipv4_udp_vxlan_any[] = {
+   RTE_FLOW_ITEM_TYPE_ETH,
+   RTE_FLOW_ITEM_TYPE_IPV4,
+   RTE_FLOW_ITEM_TYPE_UDP,
+   RTE_FLOW_ITEM_TYPE_VXLAN,
+   RTE_FLOW_ITEM_TYPE_ANY,
+   RTE_FLOW_ITEM_TYPE_END,
+};
+
+/* IPv6 VXLAN ANY */
+enum rte_flow_item_type pattern_eth_ipv6_udp_vxlan_any[] = {
+   RTE_FLOW_ITEM_TYPE_ETH,
+   RTE_FLOW_ITEM_TYPE_IPV6,
+   RTE_FLOW_ITEM_TYPE_UDP,
+   RTE_FLOW_ITEM_TYPE_VXLAN,
+   RTE_FLOW_ITEM_TYPE_ANY,
+   RTE_FLOW_ITEM_TYPE_END,
+};
+
 /* IPv4 VXLAN MAC IPv4 */
 enum rte_flow_item_type pattern_eth_ipv4_udp_vxlan_eth_ipv4[] = {
RTE_FLOW_ITEM_TYPE_ETH,
@@ -2162,14 +2182,19 @@ static struct ice_ptype_match ice_ptype_map[] = {
{pattern_eth_qinq_pppoes_ipv6,  ICE_MAC_PPPOE_IPV6_PAY},
{pattern_eth_vlan_pppoes_ipv6_tcp,  ICE_MAC_PPPOE_IPV6_TCP},
{pattern_eth_vlan_pppoes_ipv6_udp,  
ICE_MAC_PPPOE_IPV6_UDP_PAY},
+   {pattern_eth_ipv4_udp_vxlan_any,
ICE_MAC_IPV4_TUN_IPV4_PAY},
+   {pattern_eth_ipv6_udp_vxlan_any,
ICE_MAC_IPV6_TUN_IPV4_PAY},
{pattern_eth_ipv4_udp_vxlan_ipv4,   
ICE_MAC_IPV4_TUN_IPV4_PAY},
{pattern_eth_ipv4_udp_vxlan_ipv4_udp,   
ICE_MAC_IPV4_TUN_IPV4_UDP_PAY},
{pattern_eth_ipv4_udp_vxlan_ipv4_tcp,   
ICE_MAC_IPV4_TUN_IPV4_TCP},
{pattern_eth_ipv4_udp_vxlan_ipv4_sctp,  
ICE_MAC_IPV4_TUN_IPV4_SCTP},
-   {pattern_eth_ipv4_udp_vxlan_eth_ipv4,   
ICE_MAC_IPV4_TUN_IPV4_PAY},
-   {pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,   
ICE_MAC_IPV4_TUN_IPV4_UDP_PAY},
-   {pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,   
ICE_MAC_IPV4_TUN_IPV4_TCP},
-   {pattern_eth_ipv4_udp_vxlan_eth_ipv4_sctp,  
ICE_MAC_IPV4_TUN_IPV4_SCTP},
+   {pattern_eth_ipv4_udp_vxlan_eth_ipv4,   
ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_PAY},
+   {pattern_eth_ipv4_udp_vxlan_eth_ipv4_udp,   
ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_UDP_PAY},
+   {pattern_eth_ipv4_udp_vxlan_eth_ipv4_tcp,   
ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_TCP},
+   {pattern_eth_ipv4_udp_vxlan_eth_ipv4_sctp,  
ICE_MAC_IPV4_TUN_ICE_MAC_IPV4_SCTP},
+   {pattern_eth_ipv4_udp_vxlan_eth_ipv6,   
ICE_MAC_IPV4_TUN_ICE_MAC_IPV6_PAY},
+   {pattern_eth_ipv6_udp_vxlan_eth_ipv4,   
ICE_MAC_IPV6_TUN_MAC_IPV4_PAY},
+   {pattern_eth_ipv6_udp_vxlan_eth_ipv6,   
ICE_MAC_IPV6_TUN_MAC_IPV6_PAY},
{pattern_eth_ipv4_nvgre_eth_ipv4,   
ICE_MAC_IPV4_TUN_IPV4_PAY},
{pattern_eth_ipv4_nvgre_eth_ipv4_udp,   
ICE_MAC_IPV4_TUN_IPV4_UDP_PAY},
{pattern_eth_ipv4_nvgre_eth_ipv4_tcp,   
ICE_MAC_IPV4_TUN_IPV4_TCP},
diff --git a/drivers/net/ice/ice_generic_flow.h 
b/drivers/net/ice/ice_generic_flow.h
index 8845a3e156..f998ee7d71 100644
--- a/drivers/net/ice/ice_generic_flow.h
+++ b/drivers/net/ice/ice_generic_flow.h
@@ -176,6 +176,12 @@ extern enum rte_flow_item_type 
pattern_eth_ipv4_udp_vxlan_ipv4_tcp[];
 extern enum rte_flow_item_type pattern_eth_ipv4_udp_vxlan_ipv4_sctp[];
 extern enum rte_flow_item_type pattern_eth_ipv4_udp_vxlan_ipv4_icmp[];
 
+/* IPv4 VXLAN ANY */
+extern enum rte_flow_item_type pattern_eth_ipv4_udp_vxlan_any[];
+
+/* IPv6 VXLAN ANY */
+extern enum rte_flow_item_type pattern_eth_ipv6_udp_vxlan_any[];
+
 /* IPv4 VXLAN MAC IPv4 */
 extern enum rte_flow_item_type pattern_eth_ipv4_udp_vxlan_eth_ipv4[];
 extern enum rte_flow_item_t

Re: [dpdk-dev] [PATCH v2] eal: remove the deprecated whitelist/blacklist and master/slave API's

[Ruifeng Wang]

> -Original Message-
> From: dev  On Behalf Of Stephen Hemminger
> Sent: Monday, August 23, 2021 11:07 PM
> To: dev@dpdk.org
> Cc: Stephen Hemminger 
> Subject: [dpdk-dev] [PATCH v2] eal: remove the deprecated
> whitelist/blacklist and master/slave API's
> 
> New API's for these were added in 20.11 and the old API was retained but
> marked deprecated. Since 21.11 is the next LTS, it is time to remove the
> deprecated ones.
> 
> Signed-off-by: Stephen Hemminger 
> ---
> v2
>   remove the short 'w' option as well
> 
>  doc/guides/rel_notes/release_21_11.rst |  7 +++
>  lib/eal/common/eal_common_options.c| 19 ---
>  lib/eal/common/eal_options.h   | 10 --
>  lib/eal/include/rte_bus.h  |  6 --
>  lib/eal/include/rte_dev.h  |  6 --
>  lib/eal/include/rte_devargs.h  |  6 --
>  lib/eal/include/rte_launch.h   |  4 
>  lib/eal/include/rte_lcore.h| 15 ---
>  8 files changed, 7 insertions(+), 66 deletions(-)
> 
> diff --git a/doc/guides/rel_notes/release_21_11.rst
> b/doc/guides/rel_notes/release_21_11.rst
> index d707a554efaf..e34c5aa74ad0 100644
> --- a/doc/guides/rel_notes/release_21_11.rst
> +++ b/doc/guides/rel_notes/release_21_11.rst
> @@ -68,6 +68,13 @@ Removed Items
> Also, make sure to start the actual text at the margin.
> ===
> 
> +* eal: Removed the deprecated function ``rte_get_master_lcore()``
> +  and the iterarator macro ``RTE_LCORE_FOREACH_SLAVE``.

Nit. Typo 'iterator'. With suggested change:
Reviewed-by: Ruifeng Wang 

> +
> +* eal: The old api arguments that were deprecated for
> +  blacklist/whitelist are removed. Users must use the new
> +  block/allow list arguments.
> +
> 

Re: [dpdk-dev] remove dpdk-pdump pcap file, disk space is not freed

[Yan, Xiaoping (NSB - CN/Hangzhou)]

Hi,

I'm using dpdk 20.11. (it's a bit difficult for me to upgrade my applications 
to latest dpdk)

I tested dpdk-pdump with dpdk-tespmd, result is same (disk space not freed.)
[root@up-0:/]
# ps aux
USER PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME 
COMMAND
root  78 99.1  0.0 67407568 102268 pts/0 SLl+ 07:15   2:32 
dpdk-testpmd --base-virtaddr 0
root 144  0.3  0.0 67332948 7708 pts/1   Sl+  07:17   0:00 
dpdk-pdump -l 14 -a :b3:02

# fuser /tmp/l2biprt.pcap
/tmp/l2biprt.pcap:  78   144

When stop pdump, indeed testpmd prints:
EAL: msg: eal_dev_mp_request
eth_dev_close(): Closing pcap ethdev on NUMA socket 0
Port 1 is closed
EAL: reply: eal_dev_mp_request
But testpmd does not close the file:
[root@up-0:/]
# fuser /tmp/l2biprt.pcap
/tmp/l2biprt.pcap:  78

And remove the pcap file, disk space is not freed:
# df -h /tmp/
Filesystem  Size  Used Avail Use% Mounted on
tmpfs94G  900K   94G   1% /tmp
[root@up-0:/]
# ls -lh /tmp/
total 900K
-rw-r--r--. 1 root root 897K Aug 24 07:18 l2biprt.pcap
drwxrwxrwx. 2 root root   18 Aug 24 07:14 nes
[root@up-0:/]
# rm /tmp/l2biprt.pcap
[root@up-0:/]
# ls -lh /tmp/
total 0
drwxrwxrwx. 2 root root 18 Aug 24 07:14 nes
[root@up-0:/]
# df -h /tmp/
Filesystem  Size  Used Avail Use% Mounted on
tmpfs94G  900K   94G   1% /tmp

Could you please kindly check the same for your test?
It seems the testpmd close pcap device via pmd_pcap_remove(), but 
pcap_dump_close is not called. 
Could you please kindly help to check how testpmd in your case close the pcap 
file (if possible with function call stack?)?

Thank you.


Best regards
Yan Xiaoping

-Original Message-
From: Ferruh Yigit  
Sent: 2021年8月23日 18:04
To: Yan, Xiaoping (NSB - CN/Hangzhou) ; 
dev@dpdk.org
Cc: Reshma Pattan 
Subject: Re: [dpdk-dev] remove dpdk-pdump pcap file, disk space is not freed

On 8/23/2021 5:14 AM, Yan, Xiaoping (NSB - CN/Hangzhou) wrote:
> Hi,
> 
> Before I run pdump, 21MB is used in /tmp
> tmpfs63G   21M   63G   1% /tmp
> Then I run pdump with such command:
> dpdk-pdump  -c 0x4001000400100 -a :03:00.6 -a :03:06.1 
> --legacy-mem --base-virtaddr 0x2aaa2aa000 --file-prefix l2rt --  
> --pdump 
> port=1,queue=*,rx-dev=/tmp/l2biprt.pcap,tx-dev=/tmp/l2biprt.pcap,mbuf-
> size=10240,total-num-mbufs=1
> After stop, it generates a 14MB file
>   -rw-rw-r--. 1    14M Aug 23 03:58 l2biprt.pcap 
> And 35M is used in /tmp
>   tmpfs63G   35M   63G   1% /tmp
> And fuser show there are still several users of this file. (all these pids 
> are of running dpdk primary and secondary processes )
>   # fuser /tmp/l2biprt.pcap
> /tmp/l2biprt.pcap: 139   342   347   434
> Then after I rm the file (l2biprt.pcap), disk space in tmp is not freed 
> (still 35MB used)
>   rm l2biprt.pcap
>   df -h
>   tmpfs63G   35M   63G   1% /tmp
> 
> 
> It seems it goes like this:
>  pdump start->pdump send vdev hotplug add request->primary and 
> secondary process calls pmd_pcap_probe() which opens the pcap file->
>   pdump stop-> pdump send vdev hotplug remove request-> 
> primary and secondary process does not close the pcap file
> 
> To properly close the pcap file and release disk space, it seems we should:
> 
>   *   somehow close the pcap file in "vdev hotplug remove", or
>   *   don't open the pcap file in "vdev hotplug add"( pmd_pcap_probe()), it 
> seems pcap eth_dev_start will open the pcap file in case it was not opened.
> 
> Any comment is appreciated, thank you.


Hi Yan,

I can't reproduce the behavior you mentioned, for my case the .pcap file is 
closed when pdump is terminated and there is no active user of the file after 
that point.

Removing the pcap device cause closing the .pcap files.

When you terminate pdump application it will remove the pcap devices, and since 
it is a secondary process a message sent to primary to remove it too, making 
both process closing the pcap files.

When I use testpmd as primary application, I am getting following log from 
testpmd when pdump terminated:
"Port 2 is closed"
Can you please test with testpmd? You can use '--log-level=*:debug' eal 
parameter to get more log for multi process communication.

Btw, what is your DPDK version? I tested with latest DPDK (21.11.0-rc0).

Re: [dpdk-dev] [RFC 01/15] eventdev: make driver interface as internal

[Mattias Rönnblom]

On 2021-08-23 21:40, pbhagavat...@marvell.com wrote:
> From: Pavan Nikhilesh 
>
> Mark all the driver specific functions as internal, remove
> `rte` prefix from `struct rte_eventdev_ops`.
> Remove experimental tag from internal functions.
> Remove `eventdev_pmd.h` from non-internal header files.
>
Is the enqueue/dequeue shortcut still worth the trouble? Considering the 
size of this patch set, it seems to be a lot of trouble to handle this 
special case.


Is the same kind of reorganization planned for the ethdev API?

Re: [dpdk-dev] [RFC 01/15] eventdev: make driver interface as internal

[Pavan Nikhilesh Bhagavatula]

>On 2021-08-23 21:40, pbhagavat...@marvell.com wrote:
>> From: Pavan Nikhilesh 
>>
>> Mark all the driver specific functions as internal, remove
>> `rte` prefix from `struct rte_eventdev_ops`.
>> Remove experimental tag from internal functions.
>> Remove `eventdev_pmd.h` from non-internal header files.
>>
>Is the enqueue/dequeue shortcut still worth the trouble? Considering
>the
>size of this patch set, it seems to be a lot of trouble to handle this
>special case.
>
>
>Is the same kind of reorganization planned for the ethdev API?

There is already a series by Konstantin 
http://patches.dpdk.org/project/dpdk/list/?series=18422

>
>
>
>

Re: [dpdk-dev] [dpdk-ci] [PATCH] version: 21.11-rc0

[David Marchand]

Hello Lincoln,

On Tue, Aug 17, 2021 at 2:04 PM Lincoln Lavoie  wrote:
>
> Hi David,
>
> ABI testing was disable / stopped on Friday in the Community CI lab.  Patches 
> from before that for 21.11 would have still had the test run and could have 
> failures listed. I'm not sure if there is a way to "remove" those failure 
> marks from patchworks.  But, for all new patches since then, ABI hasn't been 
> run.

I can see new reports for ABI, please can someone from UNH double check?
https://lab.dpdk.org/results/dashboard/patchsets/18301/
https://lab.dpdk.org/results/dashboard/patchsets/18303/
https://lab.dpdk.org/results/dashboard/patchsets/18325/


-- 
David Marchand

Re: [dpdk-dev] [RFC 01/15] eventdev: make driver interface as internal

[Pavan Nikhilesh Bhagavatula]

>>On 2021-08-23 21:40, pbhagavat...@marvell.com wrote:
>>> From: Pavan Nikhilesh 
>>>
>>> Mark all the driver specific functions as internal, remove
>>> `rte` prefix from `struct rte_eventdev_ops`.
>>> Remove experimental tag from internal functions.
>>> Remove `eventdev_pmd.h` from non-internal header files.
>>>
>>Is the enqueue/dequeue shortcut still worth the trouble? Considering
>>the
>>size of this patch set, it seems to be a lot of trouble to handle this
>>special case.
>>
>>
>>Is the same kind of reorganization planned for the ethdev API?
>
>There is already a series by Konstantin
>http://patches.dpdk.org/project/dpdk/list/?series=18422

http://patches.dpdk.org/project/dpdk/list/?series=18382

>>
>>
>>
>>

[dpdk-dev] [PATCH] net/i40e: solve the failure of vf vlan filtering

[Qiming Chen]

When vf driver port promiscuous is turned on, the vlan filtering function
is invalid.
Through communication with PAE expert, this is a limitation of the i40e
chip. Before adding or removing VLANs, you must first disable unicast
promiscuous or multicast promiscuous, then operate the vlan, and finally
restore unicast promiscuous or multicast promiscuous state.

Signed-off-by: Qiming Chen 
---
 drivers/net/i40e/i40e_ethdev_vf.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 12e69a3233..a6f87aa1e6 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1900,12 +1900,30 @@ static int
 i40evf_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
 {
int ret;
+   struct rte_eth_conf *dev_conf = &dev->data->dev_conf;
+   struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
+   bool promisc_unicast_enabled = vf->promisc_unicast_enabled;
+   bool promisc_multicast_enabled = vf->promisc_multicast_enabled;
 
-   if (on)
+   if (promisc_unicast_enabled)
+   i40evf_dev_promiscuous_disable(dev);
+
+   if (promisc_multicast_enabled)
+   i40evf_dev_allmulticast_disable(dev);
+
+   if (on) {
ret = i40evf_add_vlan(dev, vlan_id);
-   else
+   if ((dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_VLAN_STRIP) == 
0)
+   i40evf_disable_vlan_strip(dev);
+   } else
ret = i40evf_del_vlan(dev,vlan_id);
 
+   if (promisc_unicast_enabled)
+   i40evf_dev_promiscuous_enable(dev);
+
+   if (promisc_multicast_enabled)
+   i40evf_dev_allmulticast_enable(dev);
+
return ret;
 }
 
-- 
2.30.1.windows.1

Re: [dpdk-dev] [v3, 0/3] common/cnxk: enable npa telemetry

[Gowrishankar Muthukrishnan]

Hi,
Please let me know if any other info is required.

Thanks,
Gowrishankar

> -Original Message-
> From: dev  On Behalf Of Gowrishankar Muthukrishnan
> Sent: Wednesday, August 11, 2021 9:49 PM
> To: Power, Ciara ; dev@dpdk.org
> Cc: Richardson, Bruce ; Jerin Jacob Kollanukkaran
> ; Kiran Kumar Kokkilagadda ;
> Nithin Kumar Dabilpuram ; Sunil Kumar Kori
> ; Satha Koteswara Rao Kottidi
> 
> Subject: [EXT] Re: [dpdk-dev] [v3, 0/3] common/cnxk: enable npa telemetry
> 
> External Email
> 
> --
> Hi Ciara,
> 
> > -Original Message-
> > From: Power, Ciara 
> > Sent: Wednesday, August 11, 2021 9:30 PM
> > To: Gowrishankar Muthukrishnan ;
> > dev@dpdk.org
> > Cc: Richardson, Bruce ; Jerin Jacob
> > Kollanukkaran ; Kiran Kumar Kokkilagadda
> > ; Nithin Kumar Dabilpuram
> > ; Sunil Kumar Kori ; Satha
> > Koteswara Rao Kottidi 
> > Subject: [EXT] RE: [v3, 0/3] common/cnxk: enable npa telemetry
> >
> > External Email
> >
> > --
> > Hi Gowrishankar,
> >
> > >-Original Message-
> > >From: Gowrishankar Muthukrishnan 
> > >Sent: Tuesday 3 August 2021 09:06
> > >To: dev@dpdk.org
> > >Cc: Richardson, Bruce ; Power, Ciara
> > >; jer...@marvell.com; kirankum...@marvell.com;
> > >ndabilpu...@marvell.com; sk...@marvell.com; skotesh...@marvell.com;
> > >Gowrishankar Muthukrishnan 
> > >Subject: [v3, 0/3] common/cnxk: enable npa telemetry
> > >
> > >This patch series enables telemetry in NPA LF of cnxk.
> > >
> > >v3:
> > > - fixed format specifier for uintptr_t
> > >
> > >Gowrishankar Muthukrishnan (3):
> > >  telemetry: enable storing pointer value
> > >  test/telemetry: add unit tests for pointer value
> > >  common/cnxk: add telemetry endpoints to npa
> > >
> > > app/test/test_telemetry_data.c   | 125 +
> > > app/test/test_telemetry_json.c   |  29 ++-
> > > drivers/common/cnxk/cnxk_telemetry.h |  26 +++
> > > drivers/common/cnxk/cnxk_telemetry_npa.c | 227
> > >+++
> > > drivers/common/cnxk/meson.build  |   4 +
> > > drivers/common/cnxk/roc_platform.h   |   8 +
> > > lib/telemetry/rte_telemetry.h|  37 +++-
> > > lib/telemetry/telemetry.c|  21 ++-
> > > lib/telemetry/telemetry_data.c   |  40 +++-
> > > lib/telemetry/telemetry_data.h   |   2 +
> > > lib/telemetry/telemetry_json.h   |  32 
> > > lib/telemetry/version.map|   2 +
> > > 12 files changed, 539 insertions(+), 14 deletions(-)  create mode
> > >100644 drivers/common/cnxk/cnxk_telemetry.h
> > > create mode 100644 drivers/common/cnxk/cnxk_telemetry_npa.c
> > >
> > >--
> > >2.25.1
> >
> > I am still unsure exactly what the use case is here - why are we
> > choosing to publish the pointer values through telemetry rather than
> > using a debug log for example?
> 
> Pointer values are useful sometimes for more debugging through telemetry,
> hence this proposal.
> As I mentioned in v1 thread, this is architecture compliant approach rather 
> than
> assuming pointer value is always 64 bit, when there is need to use pointer 
> value
> in current telemetry path.
> 
> Thanks,
> Gowrishankar
> 
> > Maybe I am missing something here.
> >
> > Thanks,
> > Ciara

[dpdk-dev] [Bug 794] [dpdk-19.11.10] loopback_multi_queues: core dumped when quit vhost testpmd

[bugzilla]

https://bugs.dpdk.org/show_bug.cgi?id=794

Bug ID: 794
   Summary: [dpdk-19.11.10] loopback_multi_queues: core dumped
when quit vhost testpmd
   Product: DPDK
   Version: 19.11
  Hardware: x86
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: Normal
 Component: vhost/virtio
  Assignee: dev@dpdk.org
  Reporter: linglix.c...@intel.com
  Target Milestone: ---

Environment
DPDK version: 
19.11.10-rc1:179f2a3a8a56600a66e4e0830bbe993be67f9d7e
Other software versions: N/A
OS: Ubuntu 20.04.2 LTS/Linux 5.11.16-051116-generic
Compiler: gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
Hardware platform: Intel(R) Xeon(R) Platinum 8280M CPU @ 2.70GHz
NIC hardware: FVL-40g
NIC firmware & driver: 
driver: i40e
version: 5.11.16-051116-generic
firmware-version: 8.30 0x8000a4ae 1.2926.0

Steps to reproduce
1. Launch vhost testpmd
x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 31,32 -n 4  --file-prefix=vhost
--no-pci  --vdev 'net_vhost0,iface=vhost-net,queues=1' -- -i --nb-cores=1
--rxq=1 --txq=1 --txd=1024 --rxd=1024

2. Launch virtio-user 
x86_64-native-linuxapp-gcc/app/dpdk-testpmd -l 29,30 -n 4  --file-prefix=virtio
--no-pci  --vdev
'net_virtio_user0,mac=00:01:02:03:04:05,path=./vhost-net,queues=1,packed_vq=0,in_order=1,mrg_rxbuf=0'
--single-file-segments -- -i --nb-cores=1 --rxq=1 --txq=1 --txd=1024 --rxd=1024

3.quit vhost testpmd
testpmd> quit

Show the output from the previous commands.
Stopping port 0...
Stopping ports...
Done

Shutting down port 0...
Closing ports...
VHOST_CONFIG: free connfd = 24 for device 'vhost-net'

Port 0: link state change event
free(): invalid pointer
Aborted (core dumped)

Expected Result:
quit normal

Regression
Is this issue a regression: (Y/N) Y
First bad commit id: commit eb35473b23045d32d4abd4d31ca36483e37953df
Author: Maxime Coquelin 
Date:   Tue Jun 29 18:11:28 2021 +0200

vhost: fix missing guest pages table NUMA realloc

[ upstream commit 57589cdfd784e6704ded490d80038584d6ade9df ]

When the guest allocates virtqueues on a different NUMA node
than the one the Vhost metadata are allocated, both the Vhost
device struct and the virtqueues struct are reallocated.

However, reallocating the guest pages table was missing, which
likely causes at least one cross-NUMA accesses for every burst
of packets.

This patch reallocates this table on the same NUMA node as the
other metadata.

Fixes: e246896178e6 ("vhost: get guest/host physical address mappings")

Signed-off-by: Maxime Coquelin 
Reviewed-by: Chenbo Xia 

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: [dpdk-dev] remove dpdk-pdump pcap file, disk space is not freed

[Ferruh Yigit]

(Please avoid top-post, I have updated the order of the messages. Please find
the reply at the bottom of the email.)

>> -Original Message-
>> From: Ferruh Yigit  
>> Sent: 2021年8月23日 18:04
>> To: Yan, Xiaoping (NSB - CN/Hangzhou) ; 
>> dev@dpdk.org
>> Cc: Reshma Pattan 
>> Subject: Re: [dpdk-dev] remove dpdk-pdump pcap file, disk space is not freed
>> 
>> On 8/23/2021 5:14 AM, Yan, Xiaoping (NSB - CN/Hangzhou) wrote:
>>> Hi,
>>>
>>> Before I run pdump, 21MB is used in /tmp
>>> tmpfs63G   21M   63G   1% /tmp
>>> Then I run pdump with such command:
>>> dpdk-pdump  -c 0x4001000400100 -a :03:00.6 -a :03:06.1 
>>> --legacy-mem --base-virtaddr 0x2aaa2aa000 --file-prefix l2rt --  
>>> --pdump 
>>> port=1,queue=*,rx-dev=/tmp/l2biprt.pcap,tx-dev=/tmp/l2biprt.pcap,mbuf-
>>> size=10240,total-num-mbufs=1
>>> After stop, it generates a 14MB file
>>>   -rw-rw-r--. 1    14M Aug 23 03:58 l2biprt.pcap 
>>> And 35M is used in /tmp
>>>   tmpfs63G   35M   63G   1% /tmp
>>> And fuser show there are still several users of this file. (all these pids 
>>> are of running dpdk primary and secondary processes )
>>>   # fuser /tmp/l2biprt.pcap
>>> /tmp/l2biprt.pcap: 139   342   347   434
>>> Then after I rm the file (l2biprt.pcap), disk space in tmp is not freed 
>>> (still 35MB used)
>>>   rm l2biprt.pcap
>>>   df -h
>>>   tmpfs63G   35M   63G   1% /tmp
>>>
>>>
>>> It seems it goes like this:
>>>  pdump start->pdump send vdev hotplug add request->primary and 
>>> secondary process calls pmd_pcap_probe() which opens the pcap file->
>>>   pdump stop-> pdump send vdev hotplug remove request-> 
>>> primary and secondary process does not close the pcap file
>>>
>>> To properly close the pcap file and release disk space, it seems we should:
>>>
>>>   *   somehow close the pcap file in "vdev hotplug remove", or
>>>   *   don't open the pcap file in "vdev hotplug add"( pmd_pcap_probe()), it 
>>> seems pcap eth_dev_start will open the pcap file in case it was not opened.
>>>
>>> Any comment is appreciated, thank you.
>> 
>> 
>> Hi Yan,
>> 
>> I can't reproduce the behavior you mentioned, for my case the .pcap file is 
>> closed when pdump is terminated and there is no active user of the file 
>> after that point.
>> 
>> Removing the pcap device cause closing the .pcap files.
>> 
>> When you terminate pdump application it will remove the pcap devices, and 
>> since it is a secondary process a message sent to primary to remove it too, 
>> making both process closing the pcap files.
>> 
>> When I use testpmd as primary application, I am getting following log from 
>> testpmd when pdump terminated:
>> "Port 2 is closed"
>> Can you please test with testpmd? You can use '--log-level=*:debug' eal 
>> parameter to get more log for multi process communication.
>> 
>> Btw, what is your DPDK version? I tested with latest DPDK (21.11.0-rc0).
>> 
>> 
> On 8/24/2021 8:36 AM, Yan, Xiaoping (NSB - CN/Hangzhou) wrote:
> Hi,
> 
> I'm using dpdk 20.11. (it's a bit difficult for me to upgrade my applications 
> to latest dpdk)
> 
> I tested dpdk-pdump with dpdk-tespmd, result is same (disk space not freed.)
>   [root@up-0:/]
>   # ps aux
>   USER PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME 
> COMMAND
>   root  78 99.1  0.0 67407568 102268 pts/0 SLl+ 07:15   2:32 
> dpdk-testpmd --base-virtaddr 0
>   root 144  0.3  0.0 67332948 7708 pts/1   Sl+  07:17   0:00 
> dpdk-pdump -l 14 -a :b3:02
> 
>   # fuser /tmp/l2biprt.pcap
>   /tmp/l2biprt.pcap:  78   144
> 
> When stop pdump, indeed testpmd prints:
>   EAL: msg: eal_dev_mp_request
>   eth_dev_close(): Closing pcap ethdev on NUMA socket 0
>   Port 1 is closed
>   EAL: reply: eal_dev_mp_request
> But testpmd does not close the file:
>   [root@up-0:/]
>   # fuser /tmp/l2biprt.pcap
>   /tmp/l2biprt.pcap:  78
> 
> And remove the pcap file, disk space is not freed:
>   # df -h /tmp/
>   Filesystem  Size  Used Avail Use% Mounted on
>   tmpfs94G  900K   94G   1% /tmp
>   [root@up-0:/]
>   # ls -lh /tmp/
>   total 900K
>   -rw-r--r--. 1 root root 897K Aug 24 07:18 l2biprt.pcap
>   drwxrwxrwx. 2 root root   18 Aug 24 07:14 nes
>   [root@up-0:/]
>   # rm /tmp/l2biprt.pcap
>   [root@up-0:/]
>   # ls -lh /tmp/
>   total 0
>   drwxrwxrwx. 2 root root 18 Aug 24 07:14 nes
>   [root@up-0:/]
>   # df -h /tmp/
>   Filesystem  Size  Used Avail Use% Mounted on
>   tmpfs94G  900K   94G   1% /tmp
> 
> Could you please kindly check the same for your test?
> It seems the testpmd close pcap device via pmd_pcap_remove(), but 
> pcap_dump_close is not called. 
> Could you please kindly help to check how testpmd in your case close the pcap 
> 

[dpdk-dev] [PATCH v6 0/2] testpmd shows incorrect rx_offload configuration

[Jie Wang]

Launch testpmd with multiple queues, and check rx_offload info.

When testpmd shows the port configuration, it doesn't show RSS_HASH.

---
v6: split this patch into two patches.
v5: add an API to get device configuration info.
v4: delete the whitespace at the end of the line.
v3: 
 - check and update the "offloads" of "port->dev_conf.rx/txmode".
 - update the commit log.
v2: copy "rx/txmode.offloads", instead of copying the entire struct 
"dev->data->dev_conf.rx/txmode".

Jie Wang (2):
  ethdev: add an API to get device configuration info
  app/testpmd: fix testpmd doesn't show RSS hash offload

 app/test-pmd/testpmd.c  | 33 +
 app/test-pmd/testpmd.h  |  2 ++
 app/test-pmd/util.c | 15 +++
 lib/ethdev/rte_ethdev.c | 27 +++
 lib/ethdev/rte_ethdev.h | 26 ++
 5 files changed, 103 insertions(+)

-- 
2.25.1

[dpdk-dev] [PATCH v6 1/2] ethdev: add an API to get device configuration info

[Jie Wang]

This patch adds a new API "rte_eth_dev_conf_info_get()" to help testpmd get
device configuration info.

Signed-off-by: Jie Wang 
---
 lib/ethdev/rte_ethdev.c | 27 +++
 lib/ethdev/rte_ethdev.h | 26 ++
 2 files changed, 53 insertions(+)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..74184099a1 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -3458,6 +3458,33 @@ rte_eth_dev_info_get(uint16_t port_id, struct 
rte_eth_dev_info *dev_info)
return 0;
 }
 
+int
+rte_eth_dev_conf_info_get(uint16_t port_id,
+   struct rte_eth_dev_conf_info *dev_conf_info)
+{
+   struct rte_eth_dev *dev;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+   dev = &rte_eth_devices[port_id];
+
+   if (dev_conf_info == NULL) {
+   RTE_ETHDEV_LOG(ERR, "Cannot get ethdev port %u config info to 
NULL\n",
+   port_id);
+   return -EINVAL;
+   }
+
+   /*
+* Init dev_conf_info before port_id check since caller does not have
+* return status and does not know if get is successful or not.
+*/
+   memset(dev_conf_info, 0, sizeof(struct rte_eth_dev_conf_info));
+
+   dev_conf_info->rx_offloads = dev->data->dev_conf.rxmode.offloads;
+   dev_conf_info->tx_offloads = dev->data->dev_conf.txmode.offloads;
+
+   return 0;
+}
+
 int
 rte_eth_dev_get_supported_ptypes(uint16_t port_id, uint32_t ptype_mask,
 uint32_t *ptypes, int num)
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index d2b27c351f..70a2db550f 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1587,6 +1587,15 @@ struct rte_eth_dev_info {
void *reserved_ptrs[2];   /**< Reserved for future fields */
 };
 
+/**
+ * Ethernet device configuration information structure.
+ * Used to retrieve information about configured device.
+ */
+struct rte_eth_dev_conf_info {
+   uint64_t rx_offloads; /**rxmode offloads */
+   uint64_t tx_offloads; /**txmode offloads */
+};
+
 /**
  * RX/TX queue states
  */
@@ -3058,6 +3067,23 @@ int rte_eth_macaddr_get(uint16_t port_id, struct 
rte_ether_addr *mac_addr);
  */
 int rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info);
 
+/**
+ * Retrieve the contextual information of an Ethernet device.
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @param dev_conf_info
+ *   A pointer to a structure of type *rte_eth_dev_conf_info* to be filled with
+ *   the contextual information of the Ethernet device.
+ * @return
+ *   - (0) if successful.
+ *   - (-ENOTSUP) if support for dev_infos_get() does not exist for the device.
+ *   - (-ENODEV) if *port_id* invalid.
+ *   - (-EINVAL) if bad parameter.
+ */
+int rte_eth_dev_conf_info_get(uint16_t port_id,
+   struct rte_eth_dev_conf_info *dev_conf_info);
+
 /**
  * Retrieve the firmware version of a device.
  *
-- 
2.25.1

[dpdk-dev] [PATCH v6 2/2] app/testpmd: fix testpmd doesn't show RSS hash offload

[Jie Wang]

The driver may change offloads info into dev->data->dev_conf
in dev_configure which may cause port->dev_conf and port->rx_conf
contain outdated values.

This patch updates the offloads info if it changes to fix this issue.

Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Cc: sta...@dpdk.org

Signed-off-by: Jie Wang 
---
 app/test-pmd/testpmd.c | 33 +
 app/test-pmd/testpmd.h |  2 ++
 app/test-pmd/util.c| 15 +++
 3 files changed, 50 insertions(+)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 6cbe9ba3c8..9a78805673 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2461,6 +2461,9 @@ start_port(portid_t pid)
}
 
if (port->need_reconfig > 0) {
+   struct rte_eth_dev_conf_info dev_conf_info;
+   int k;
+
port->need_reconfig = 0;
 
if (flow_isolate_all) {
@@ -2498,6 +2501,36 @@ start_port(portid_t pid)
port->need_reconfig = 1;
return -1;
}
+   /* get offloads */
+   if (0 !=
+   eth_dev_conf_info_get_print_err(pi,
+   &dev_conf_info)) {
+   rte_exit(EXIT_FAILURE,
+   "rte_eth_dev_conf_info_get() failed\n");
+   return -1;
+   }
+   /* Apply Rx offloads configuration */
+   if (dev_conf_info.rx_offloads !=
+   port->dev_conf.rxmode.offloads) {
+   port->dev_conf.rxmode.offloads =
+   dev_conf_info.rx_offloads;
+   for (k = 0;
+k < port->dev_info.max_rx_queues;
+k++)
+   port->rx_conf[k].offloads =
+   dev_conf_info.rx_offloads;
+   }
+   /* Apply Tx offloads configuration */
+   if (dev_conf_info.tx_offloads !=
+   port->dev_conf.txmode.offloads) {
+   port->dev_conf.txmode.offloads =
+   dev_conf_info.tx_offloads;
+   for (k = 0;
+k < port->dev_info.max_tx_queues;
+k++)
+   port->tx_conf[k].offloads =
+   dev_conf_info.tx_offloads;
+   }
}
if (port->need_reconfig_queues > 0) {
port->need_reconfig_queues = 0;
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 16a3598e48..4cf69a17a3 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -950,6 +950,8 @@ void show_gro(portid_t port_id);
 void setup_gso(const char *mode, portid_t port_id);
 int eth_dev_info_get_print_err(uint16_t port_id,
struct rte_eth_dev_info *dev_info);
+int eth_dev_conf_info_get_print_err(uint16_t port_id,
+   struct rte_eth_dev_conf_info *dev_info);
 void eth_set_promisc_mode(uint16_t port_id, int enable);
 void eth_set_allmulticast_mode(uint16_t port, int enable);
 int eth_link_get_nowait_print_err(uint16_t port_id, struct rte_eth_link *link);
diff --git a/app/test-pmd/util.c b/app/test-pmd/util.c
index 5dd7157947..c6992fba7a 100644
--- a/app/test-pmd/util.c
+++ b/app/test-pmd/util.c
@@ -440,6 +440,21 @@ eth_dev_info_get_print_err(uint16_t port_id,
return ret;
 }
 
+int
+eth_dev_conf_info_get_print_err(uint16_t port_id,
+   struct rte_eth_dev_conf_info *dev_conf_info)
+{
+   int ret;
+
+   ret = rte_eth_dev_conf_info_get(port_id, dev_conf_info);
+   if (ret != 0)
+   fprintf(stderr,
+   "Error during getting device config (port %u) info: 
%s\n",
+   port_id, strerror(-ret));
+
+   return ret;
+}
+
 void
 eth_set_promisc_mode(uint16_t port, int enable)
 {
-- 
2.25.1

[dpdk-dev] [PATCH v2] net/i40e: solve the failure of vf vlan filtering

[Qiming Chen]

When vf driver port promiscuous is turned on, the vlan filtering function
is invalid.
Through communication with PAE expert, this is a limitation of the i40e
chip. Before adding or removing VLANs, you must first disable unicast
promiscuous or multicast promiscuous, then operate the vlan, and finally
restore unicast promiscuous or multicast promiscuous state.

Signed-off-by: Qiming Chen 
---
 drivers/net/i40e/i40e_ethdev_vf.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/net/i40e/i40e_ethdev_vf.c 
b/drivers/net/i40e/i40e_ethdev_vf.c
index 12e69a3233..a099daae6b 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1900,11 +1900,30 @@ static int
 i40evf_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
 {
int ret;
+   struct rte_eth_conf *dev_conf = &dev->data->dev_conf;
+   struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
+   bool promisc_unicast_enabled = vf->promisc_unicast_enabled;
+   bool promisc_multicast_enabled = vf->promisc_multicast_enabled;
 
-   if (on)
+   if (promisc_unicast_enabled)
+   i40evf_dev_promiscuous_disable(dev);
+
+   if (promisc_multicast_enabled)
+   i40evf_dev_allmulticast_disable(dev);
+
+   if (on) {
ret = i40evf_add_vlan(dev, vlan_id);
-   else
+   if ((dev_conf->rxmode.offloads & DEV_RX_OFFLOAD_VLAN_STRIP) == 
0)
+   i40evf_disable_vlan_strip(dev);
+   } else {
ret = i40evf_del_vlan(dev,vlan_id);
+   }
+
+   if (promisc_unicast_enabled)
+   i40evf_dev_promiscuous_enable(dev);
+
+   if (promisc_multicast_enabled)
+   i40evf_dev_allmulticast_enable(dev);
 
return ret;
 }
-- 
2.30.1.windows.1

Re: [dpdk-dev] [PATCH] crypto/openssl: fix CCM processing 0 length source

[Zhang, Roy Fan]

> -Original Message-
> From: Power, Ciara 
> Sent: Monday, August 23, 2021 1:47 PM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Zhang, Roy Fan ; Power,
> Ciara ; De Lara Guarch, Pablo
> ; Doherty, Declan
> 
> Subject: [PATCH] crypto/openssl: fix CCM processing 0 length source
> 
> When given a source length 0 for CCM, the encryption and decryption
> functions did not call the EVP_ENCRYPTUPDATE/EVP_DECRYPTUPDATE
> functions
> with a src and dst, causing some FIPS validation failures for testcases
> with PLen=0:
> 
> process_openssl_auth_encryption_ccm() line 1131:
> Process openssl auth encryption ccm failed
> 
> Fixes: 1a4998dc4d94 ("crypto/openssl: support AES-CCM")
> Cc: pablo.de.lara.gua...@intel.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Ciara Power 
> ---
>  drivers/crypto/openssl/rte_openssl_pmd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/crypto/openssl/rte_openssl_pmd.c
> b/drivers/crypto/openssl/rte_openssl_pmd.c
> index 47004337d5..37b969b916 100644
> --- a/drivers/crypto/openssl/rte_openssl_pmd.c
> +++ b/drivers/crypto/openssl/rte_openssl_pmd.c
> @@ -1114,7 +1114,7 @@ process_openssl_auth_encryption_ccm(struct
> rte_mbuf *mbuf_src, int offset,
>   if (EVP_EncryptUpdate(ctx, NULL, &len, aad + 18, aadlen) <=
> 0)
>   goto process_auth_encryption_ccm_err;
> 
> - if (srclen > 0)
> + if (srclen >= 0)
>   if (process_openssl_encryption_update(mbuf_src, offset,
> &dst,
>   srclen, ctx, 0))
>   goto process_auth_encryption_ccm_err;
> @@ -1197,7 +1197,7 @@ process_openssl_auth_decryption_ccm(struct
> rte_mbuf *mbuf_src, int offset,
>   if (EVP_DecryptUpdate(ctx, NULL, &len, aad + 18, aadlen) <=
> 0)
>   goto process_auth_decryption_ccm_err;
> 
> - if (srclen > 0)
> + if (srclen >= 0)
>   if (process_openssl_decryption_update(mbuf_src, offset,
> &dst,
>   srclen, ctx, 0))
>   return -EFAULT;
> --
> 2.25.1

Acked-by: Fan Zhang 

[dpdk-dev] [PATCH v3] eal: read data buffer on RTE_INTR_HANDLE_VFIO_REQ

[Maciej Szwed]

We should call read() on RTE_INTR_HANDLE_VFIO_REQ event
to confirm that event.

Signed-off-by: "Szwed, Maciej" 
---
 lib/eal/linux/eal_interrupts.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/lib/eal/linux/eal_interrupts.c b/lib/eal/linux/eal_interrupts.c
index 22b3b7bcd9..dc42527344 100644
--- a/lib/eal/linux/eal_interrupts.c
+++ b/lib/eal/linux/eal_interrupts.c
@@ -918,17 +918,16 @@ eal_intr_process_interrupts(struct epoll_event *events, 
int nfds)
bytes_read = sizeof(buf.timerfd_num);
break;
 #ifdef VFIO_PRESENT
+#ifdef HAVE_VFIO_DEV_REQ_INTERFACE
+   case RTE_INTR_HANDLE_VFIO_REQ:
+   call = true;
+#endif
+   /* fall through */
case RTE_INTR_HANDLE_VFIO_MSIX:
case RTE_INTR_HANDLE_VFIO_MSI:
case RTE_INTR_HANDLE_VFIO_LEGACY:
bytes_read = sizeof(buf.vfio_intr_count);
break;
-#ifdef HAVE_VFIO_DEV_REQ_INTERFACE
-   case RTE_INTR_HANDLE_VFIO_REQ:
-   bytes_read = 0;
-   call = true;
-   break;
-#endif
 #endif
case RTE_INTR_HANDLE_VDEV:
case RTE_INTR_HANDLE_EXT:
-- 
2.27.0

[dpdk-dev] [PATCH v6 0/2] testpmd shows incorrect rx_offload configuration

[Jie Wang]

Launch testpmd with multiple queues, and check rx_offload info.

When testpmd shows the port configuration, it doesn't show RSS_HASH.

---
v6: split this patch into two patches.
v5: add an API to get device configuration info.
v4: delete the whitespace at the end of the line.
v3:
 - check and update the "offloads" of "port->dev_conf.rx/txmode".
 - update the commit log.
v2: copy "rx/txmode.offloads", instead of copying the entire struct
"dev->data->dev_conf.rx/txmode".

Jie Wang (2):
  ethdev: add an API to get device configuration info
  app/testpmd: fix testpmd doesn't show RSS hash offload

 app/test-pmd/testpmd.c  | 33 +
 app/test-pmd/testpmd.h  |  2 ++
 app/test-pmd/util.c | 15 +++
 lib/ethdev/rte_ethdev.c | 27 +++
 lib/ethdev/rte_ethdev.h | 26 ++
 lib/ethdev/version.map  |  3 +++
 6 files changed, 106 insertions(+)

-- 
2.25.1

[dpdk-dev] [PATCH v6 1/2] ethdev: add an API to get device configuration info

[Jie Wang]

This patch adds a new API "rte_eth_dev_conf_info_get()" to help testpmd get
device configuration info.

Signed-off-by: Jie Wang 
---
 lib/ethdev/rte_ethdev.c | 27 +++
 lib/ethdev/rte_ethdev.h | 26 ++
 lib/ethdev/version.map  |  3 +++
 3 files changed, 56 insertions(+)

diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 9d95cd11e1..74184099a1 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -3458,6 +3458,33 @@ rte_eth_dev_info_get(uint16_t port_id, struct 
rte_eth_dev_info *dev_info)
return 0;
 }
 
+int
+rte_eth_dev_conf_info_get(uint16_t port_id,
+   struct rte_eth_dev_conf_info *dev_conf_info)
+{
+   struct rte_eth_dev *dev;
+
+   RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+   dev = &rte_eth_devices[port_id];
+
+   if (dev_conf_info == NULL) {
+   RTE_ETHDEV_LOG(ERR, "Cannot get ethdev port %u config info to 
NULL\n",
+   port_id);
+   return -EINVAL;
+   }
+
+   /*
+* Init dev_conf_info before port_id check since caller does not have
+* return status and does not know if get is successful or not.
+*/
+   memset(dev_conf_info, 0, sizeof(struct rte_eth_dev_conf_info));
+
+   dev_conf_info->rx_offloads = dev->data->dev_conf.rxmode.offloads;
+   dev_conf_info->tx_offloads = dev->data->dev_conf.txmode.offloads;
+
+   return 0;
+}
+
 int
 rte_eth_dev_get_supported_ptypes(uint16_t port_id, uint32_t ptype_mask,
 uint32_t *ptypes, int num)
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index d2b27c351f..70a2db550f 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1587,6 +1587,15 @@ struct rte_eth_dev_info {
void *reserved_ptrs[2];   /**< Reserved for future fields */
 };
 
+/**
+ * Ethernet device configuration information structure.
+ * Used to retrieve information about configured device.
+ */
+struct rte_eth_dev_conf_info {
+   uint64_t rx_offloads; /**rxmode offloads */
+   uint64_t tx_offloads; /**txmode offloads */
+};
+
 /**
  * RX/TX queue states
  */
@@ -3058,6 +3067,23 @@ int rte_eth_macaddr_get(uint16_t port_id, struct 
rte_ether_addr *mac_addr);
  */
 int rte_eth_dev_info_get(uint16_t port_id, struct rte_eth_dev_info *dev_info);
 
+/**
+ * Retrieve the contextual information of an Ethernet device.
+ *
+ * @param port_id
+ *   The port identifier of the Ethernet device.
+ * @param dev_conf_info
+ *   A pointer to a structure of type *rte_eth_dev_conf_info* to be filled with
+ *   the contextual information of the Ethernet device.
+ * @return
+ *   - (0) if successful.
+ *   - (-ENOTSUP) if support for dev_infos_get() does not exist for the device.
+ *   - (-ENODEV) if *port_id* invalid.
+ *   - (-EINVAL) if bad parameter.
+ */
+int rte_eth_dev_conf_info_get(uint16_t port_id,
+   struct rte_eth_dev_conf_info *dev_conf_info);
+
 /**
  * Retrieve the firmware version of a device.
  *
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
index 44d30b05ae..40539f99f9 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -249,6 +249,9 @@ EXPERIMENTAL {
rte_mtr_meter_policy_delete;
rte_mtr_meter_policy_update;
rte_mtr_meter_policy_validate;
+
+   # added in 21.11
+   rte_eth_dev_conf_info_get;
 };
 
 INTERNAL {
-- 
2.25.1

[dpdk-dev] [PATCH v6 2/2] app/testpmd: fix testpmd doesn't show RSS hash offload

[Jie Wang]

The driver may change offloads info into dev->data->dev_conf
in dev_configure which may cause port->dev_conf and port->rx_conf
contain outdated values.

This patch updates the offloads info if it changes to fix this issue.

Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
Cc: sta...@dpdk.org

Signed-off-by: Jie Wang 
---
 app/test-pmd/testpmd.c | 33 +
 app/test-pmd/testpmd.h |  2 ++
 app/test-pmd/util.c| 15 +++
 3 files changed, 50 insertions(+)

diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 6cbe9ba3c8..9a78805673 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2461,6 +2461,9 @@ start_port(portid_t pid)
}
 
if (port->need_reconfig > 0) {
+   struct rte_eth_dev_conf_info dev_conf_info;
+   int k;
+
port->need_reconfig = 0;
 
if (flow_isolate_all) {
@@ -2498,6 +2501,36 @@ start_port(portid_t pid)
port->need_reconfig = 1;
return -1;
}
+   /* get offloads */
+   if (0 !=
+   eth_dev_conf_info_get_print_err(pi,
+   &dev_conf_info)) {
+   rte_exit(EXIT_FAILURE,
+   "rte_eth_dev_conf_info_get() failed\n");
+   return -1;
+   }
+   /* Apply Rx offloads configuration */
+   if (dev_conf_info.rx_offloads !=
+   port->dev_conf.rxmode.offloads) {
+   port->dev_conf.rxmode.offloads =
+   dev_conf_info.rx_offloads;
+   for (k = 0;
+k < port->dev_info.max_rx_queues;
+k++)
+   port->rx_conf[k].offloads =
+   dev_conf_info.rx_offloads;
+   }
+   /* Apply Tx offloads configuration */
+   if (dev_conf_info.tx_offloads !=
+   port->dev_conf.txmode.offloads) {
+   port->dev_conf.txmode.offloads =
+   dev_conf_info.tx_offloads;
+   for (k = 0;
+k < port->dev_info.max_tx_queues;
+k++)
+   port->tx_conf[k].offloads =
+   dev_conf_info.tx_offloads;
+   }
}
if (port->need_reconfig_queues > 0) {
port->need_reconfig_queues = 0;
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index 16a3598e48..4cf69a17a3 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -950,6 +950,8 @@ void show_gro(portid_t port_id);
 void setup_gso(const char *mode, portid_t port_id);
 int eth_dev_info_get_print_err(uint16_t port_id,
struct rte_eth_dev_info *dev_info);
+int eth_dev_conf_info_get_print_err(uint16_t port_id,
+   struct rte_eth_dev_conf_info *dev_info);
 void eth_set_promisc_mode(uint16_t port_id, int enable);
 void eth_set_allmulticast_mode(uint16_t port, int enable);
 int eth_link_get_nowait_print_err(uint16_t port_id, struct rte_eth_link *link);
diff --git a/app/test-pmd/util.c b/app/test-pmd/util.c
index 5dd7157947..c6992fba7a 100644
--- a/app/test-pmd/util.c
+++ b/app/test-pmd/util.c
@@ -440,6 +440,21 @@ eth_dev_info_get_print_err(uint16_t port_id,
return ret;
 }
 
+int
+eth_dev_conf_info_get_print_err(uint16_t port_id,
+   struct rte_eth_dev_conf_info *dev_conf_info)
+{
+   int ret;
+
+   ret = rte_eth_dev_conf_info_get(port_id, dev_conf_info);
+   if (ret != 0)
+   fprintf(stderr,
+   "Error during getting device config (port %u) info: 
%s\n",
+   port_id, strerror(-ret));
+
+   return ret;
+}
+
 void
 eth_set_promisc_mode(uint16_t port, int enable)
 {
-- 
2.25.1

[dpdk-dev] [PATCH v4] eal: read data buffer on RTE_INTR_HANDLE_VFIO_REQ

[Maciej Szwed]

We should call read() on RTE_INTR_HANDLE_VFIO_REQ event
to confirm that event.

Signed-off-by: Maciej Szwed 
---
 lib/eal/linux/eal_interrupts.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/lib/eal/linux/eal_interrupts.c b/lib/eal/linux/eal_interrupts.c
index 22b3b7bcd9..dc42527344 100644
--- a/lib/eal/linux/eal_interrupts.c
+++ b/lib/eal/linux/eal_interrupts.c
@@ -918,17 +918,16 @@ eal_intr_process_interrupts(struct epoll_event *events, 
int nfds)
bytes_read = sizeof(buf.timerfd_num);
break;
 #ifdef VFIO_PRESENT
+#ifdef HAVE_VFIO_DEV_REQ_INTERFACE
+   case RTE_INTR_HANDLE_VFIO_REQ:
+   call = true;
+#endif
+   /* fall through */
case RTE_INTR_HANDLE_VFIO_MSIX:
case RTE_INTR_HANDLE_VFIO_MSI:
case RTE_INTR_HANDLE_VFIO_LEGACY:
bytes_read = sizeof(buf.vfio_intr_count);
break;
-#ifdef HAVE_VFIO_DEV_REQ_INTERFACE
-   case RTE_INTR_HANDLE_VFIO_REQ:
-   bytes_read = 0;
-   call = true;
-   break;
-#endif
 #endif
case RTE_INTR_HANDLE_VDEV:
case RTE_INTR_HANDLE_EXT:
-- 
2.27.0

[dpdk-dev] [PATCH v6 0/2] Use macro to print MAC address

[Aman Singh]

Added macros to simplyfy print of MAC address.
The six bytes of mac address is extracted using
a macro to improve code readability.

V2: Fix build issue in examples code
V3: Fix Windows compilation issue
V5: Print format aligned with rte_ether_format_addr API
Both using upper case hexadecimal format.
V6: Added macro RTE_ETHER_ADDR_BYTES in the rte_ether_format_addr
API and rebased.

Aman Singh (2):
  net: added macro for MAC address print
  net: added macro to extract MAC address bytes

 app/pdump/main.c  |  5 +---
 app/test-pmd/cmdline.c|  6 ++--
 app/test-pmd/config.c |  6 ++--
 app/test-pmd/testpmd.c|  9 ++
 app/test/test_event_eth_rx_adapter.c  |  5 +---
 app/test/test_event_eth_tx_adapter.c  |  5 +---
 drivers/bus/dpaa/base/fman/netcfg_layer.c |  9 ++
 drivers/common/mlx5/linux/mlx5_nl.c   |  6 ++--
 drivers/net/bnx2x/bnx2x.c |  4 +--
 drivers/net/bnx2x/bnx2x_vfpf.c| 10 ++-
 drivers/net/bnx2x/ecore_sp.c  | 14 -
 drivers/net/bnxt/bnxt_ethdev.c|  2 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c |  4 +--
 drivers/net/bonding/rte_eth_bond_pmd.c| 12 +++-
 drivers/net/dpaa/dpaa_ethdev.c| 10 ++-
 drivers/net/e1000/igb_ethdev.c|  9 ++
 drivers/net/enic/base/vnic_dev.c  |  4 +--
 drivers/net/enic/enic_res.c   |  2 +-
 drivers/net/failsafe/failsafe.c   |  6 ++--
 drivers/net/hinic/hinic_pmd_ethdev.c  |  6 ++--
 drivers/net/i40e/i40e_ethdev_vf.c | 21 --
 drivers/net/iavf/iavf_ethdev.c| 18 +++-
 drivers/net/iavf/iavf_vchnl.c | 15 +++---
 drivers/net/ice/ice_dcf.c |  6 ++--
 drivers/net/ixgbe/ixgbe_ethdev.c  | 29 ---
 drivers/net/mlx4/mlx4.c   |  7 ++---
 drivers/net/mlx5/linux/mlx5_os.c  |  7 ++---
 drivers/net/mlx5/windows/mlx5_os.c|  7 ++---
 drivers/net/mvpp2/mrvl_flow.c |  4 +--
 drivers/net/netvsc/hn_rndis.c |  2 +-
 drivers/net/qede/base/ecore_mcp.c |  2 +-
 drivers/net/qede/base/ecore_sriov.c   |  2 +-
 drivers/net/qede/qede_ethdev.c|  9 ++
 drivers/net/thunderx/nicvf_ethdev.c   |  2 +-
 drivers/net/txgbe/txgbe_ethdev_vf.c   | 29 ---
 drivers/net/virtio/virtio_ethdev.c|  4 +--
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |  4 +--
 examples/bbdev_app/main.c |  9 ++
 examples/bond/main.c  |  3 +-
 examples/distributor/main.c   |  5 +---
 examples/ethtool/ethtool-app/ethapp.c | 10 ++-
 .../pipeline_worker_generic.c |  5 +---
 .../eventdev_pipeline/pipeline_worker_tx.c|  5 +---
 examples/flow_classify/flow_classify.c|  5 +---
 examples/ioat/ioatfwd.c   |  9 ++
 examples/ip_pipeline/cli.c| 11 ++-
 examples/l2fwd-cat/l2fwd-cat.c|  5 +---
 examples/l2fwd-crypto/main.c  | 11 ++-
 examples/l2fwd-event/l2fwd_common.c   |  9 ++
 examples/l2fwd-jobstats/main.c| 11 ++-
 examples/l2fwd-keepalive/main.c   |  9 ++
 examples/l2fwd/main.c | 11 ++-
 examples/link_status_interrupt/main.c |  9 ++
 examples/packet_ordering/main.c   |  5 +---
 examples/pipeline/cli.c   |  6 ++--
 examples/rxtx_callbacks/main.c|  4 +--
 examples/server_node_efd/server/main.c|  6 ++--
 examples/skeleton/basicfwd.c  |  5 +---
 examples/vhost/main.c | 17 +++
 examples/vm_power_manager/channel_monitor.c   |  4 +--
 .../guest_cli/vm_power_cli_guest.c|  5 +---
 examples/vm_power_manager/main.c  |  5 +---
 examples/vmdq/main.c  | 14 ++---
 examples/vmdq_dcb/main.c  | 14 ++---
 lib/net/rte_ether.c   |  9 ++
 lib/net/rte_ether.h   | 14 +
 lib/vhost/vhost_user.c|  2 +-
 67 files changed, 156 insertions(+), 383 deletions(-)

-- 
2.17.1

[dpdk-dev] [PATCH v6 1/2] net: added macro for MAC address print

[Aman Singh]

Added macro to print six bytes of MAC address.
The MAC addresses will be printed in upper case
hexadecimal format.
In case there is a specific check for lower case
MAC address, the user may need to make a change in
such test case after this patch.

Signed-off-by: Aman Singh 
Reviewed-by: Ferruh Yigit 
---

V5: Print format aligned with rte_ether_format_addr API
Both using upper case hexadecimal format.
---
 app/test-pmd/cmdline.c|  2 +-
 app/test-pmd/config.c |  2 +-
 app/test-pmd/testpmd.c|  2 +-
 drivers/bus/dpaa/base/fman/netcfg_layer.c |  2 +-
 drivers/common/mlx5/linux/mlx5_nl.c   |  2 +-
 drivers/net/bnx2x/bnx2x.c |  4 ++--
 drivers/net/bnx2x/bnx2x_vfpf.c|  3 ++-
 drivers/net/bnx2x/ecore_sp.c  | 14 +++---
 drivers/net/bnxt/bnxt_ethdev.c|  2 +-
 drivers/net/bonding/rte_eth_bond_8023ad.c |  4 ++--
 drivers/net/bonding/rte_eth_bond_pmd.c|  4 ++--
 drivers/net/dpaa/dpaa_ethdev.c|  2 +-
 drivers/net/e1000/igb_ethdev.c|  2 +-
 drivers/net/enic/base/vnic_dev.c  |  4 ++--
 drivers/net/enic/enic_res.c   |  2 +-
 drivers/net/failsafe/failsafe.c   |  2 +-
 drivers/net/hinic/hinic_pmd_ethdev.c  |  2 +-
 drivers/net/i40e/i40e_ethdev_vf.c |  6 +++---
 drivers/net/iavf/iavf_ethdev.c|  4 ++--
 drivers/net/iavf/iavf_vchnl.c |  4 ++--
 drivers/net/ice/ice_dcf.c |  2 +-
 drivers/net/ixgbe/ixgbe_ethdev.c  |  6 +++---
 drivers/net/mlx4/mlx4.c   |  2 +-
 drivers/net/mlx5/linux/mlx5_os.c  |  2 +-
 drivers/net/mlx5/windows/mlx5_os.c|  2 +-
 drivers/net/mvpp2/mrvl_flow.c |  4 ++--
 drivers/net/netvsc/hn_rndis.c |  2 +-
 drivers/net/qede/base/ecore_mcp.c |  2 +-
 drivers/net/qede/base/ecore_sriov.c   |  2 +-
 drivers/net/qede/qede_ethdev.c|  2 +-
 drivers/net/thunderx/nicvf_ethdev.c   |  2 +-
 drivers/net/txgbe/txgbe_ethdev_vf.c   |  6 +++---
 drivers/net/virtio/virtio_ethdev.c|  4 ++--
 drivers/net/vmxnet3/vmxnet3_ethdev.c  |  4 ++--
 examples/bbdev_app/main.c |  2 +-
 examples/ethtool/ethtool-app/ethapp.c |  2 +-
 examples/ioat/ioatfwd.c   |  2 +-
 examples/ip_pipeline/cli.c|  4 ++--
 examples/l2fwd-crypto/main.c  |  2 +-
 examples/l2fwd-event/l2fwd_common.c   |  2 +-
 examples/l2fwd-jobstats/main.c|  2 +-
 examples/l2fwd-keepalive/main.c   |  2 +-
 examples/l2fwd/main.c |  2 +-
 examples/link_status_interrupt/main.c |  2 +-
 examples/pipeline/cli.c   |  2 +-
 examples/server_node_efd/server/main.c|  2 +-
 examples/vhost/main.c |  2 +-
 examples/vmdq/main.c  |  2 +-
 examples/vmdq_dcb/main.c  |  2 +-
 lib/net/rte_ether.c   |  2 +-
 lib/net/rte_ether.h   |  5 +
 lib/vhost/vhost_user.c|  2 +-
 52 files changed, 79 insertions(+), 73 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 82253bc751..d4186eb9b2 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -10899,7 +10899,7 @@ static void cmd_mcast_addr_parsed(void *parsed_result,
 
if (!rte_is_multicast_ether_addr(&res->mc_addr)) {
fprintf(stderr,
-   "Invalid multicast addr 
%02X:%02X:%02X:%02X:%02X:%02X\n",
+   "Invalid multicast addr " RTE_ETHER_ADDR_PRT_FMT "\n",
res->mc_addr.addr_bytes[0], res->mc_addr.addr_bytes[1],
res->mc_addr.addr_bytes[2], res->mc_addr.addr_bytes[3],
res->mc_addr.addr_bytes[4], res->mc_addr.addr_bytes[5]);
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 31d8ba1b91..21d5db5297 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -782,7 +782,7 @@ port_summary_display(portid_t port_id)
if (ret != 0)
return;
 
-   printf("%-4d %02X:%02X:%02X:%02X:%02X:%02X %-12s %-14s %-8s %s\n",
+   printf("%-4d " RTE_ETHER_ADDR_PRT_FMT " %-12s %-14s %-8s %s\n",
port_id, mac_addr.addr_bytes[0], mac_addr.addr_bytes[1],
mac_addr.addr_bytes[2], mac_addr.addr_bytes[3],
mac_addr.addr_bytes[4], mac_addr.addr_bytes[5], name,
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 6cbe9ba3c8..d0ede963ea 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2622,7 +2622,7 @@ start_port(portid_t pid)
pi);
 
if (eth_macaddr_get_print_err(pi, &port->eth_addr) == 0)
-   printf("Port %d: %02X:%02X:%02X:%02X:%02X:%02X\n", pi,
+   printf("Port %d: " RTE_ETHER_ADDR_PRT_FMT "\n", pi,

[dpdk-dev] [PATCH v6 2/2] net: added macro to extract MAC address bytes

[Aman Singh]

Added macros to simplify print of MAC address.
The six bytes of a MAC address are extracted in
a macro here, to improve code readablity.

Signed-off-by: Aman Singh 
Reviewed-by: Ferruh Yigit 
---
The change in the document will be done in seperate patch.
To ensure document has direct reference of the code as shown in
commit 413c75c33c40 ("doc: show how to include code in guides").

V5: Print format aligned with rte_ether_format_addr API
Both using upper case hexadecimal format.
---
 app/pdump/main.c  |  5 +---
 app/test-pmd/cmdline.c|  4 +---
 app/test-pmd/config.c |  4 +---
 app/test-pmd/testpmd.c|  7 +-
 app/test/test_event_eth_rx_adapter.c  |  5 +---
 app/test/test_event_eth_tx_adapter.c  |  5 +---
 drivers/bus/dpaa/base/fman/netcfg_layer.c |  7 +-
 drivers/common/mlx5/linux/mlx5_nl.c   |  4 +---
 drivers/net/bnx2x/bnx2x_vfpf.c|  7 +-
 drivers/net/bonding/rte_eth_bond_pmd.c|  8 ++-
 drivers/net/dpaa/dpaa_ethdev.c|  8 +--
 drivers/net/e1000/igb_ethdev.c|  7 +-
 drivers/net/failsafe/failsafe.c   |  4 +---
 drivers/net/hinic/hinic_pmd_ethdev.c  |  4 +---
 drivers/net/i40e/i40e_ethdev_vf.c | 15 +++-
 drivers/net/iavf/iavf_ethdev.c| 14 ++-
 drivers/net/iavf/iavf_vchnl.c | 11 ++---
 drivers/net/ice/ice_dcf.c |  4 +---
 drivers/net/ixgbe/ixgbe_ethdev.c  | 23 +++
 drivers/net/mlx4/mlx4.c   |  5 +---
 drivers/net/mlx5/linux/mlx5_os.c  |  5 +---
 drivers/net/mlx5/windows/mlx5_os.c|  5 +---
 drivers/net/qede/qede_ethdev.c|  7 +-
 drivers/net/txgbe/txgbe_ethdev_vf.c   | 23 +++
 examples/bbdev_app/main.c |  7 +-
 examples/bond/main.c  |  3 +--
 examples/distributor/main.c   |  5 +---
 examples/ethtool/ethtool-app/ethapp.c |  8 +--
 .../pipeline_worker_generic.c |  5 +---
 .../eventdev_pipeline/pipeline_worker_tx.c|  5 +---
 examples/flow_classify/flow_classify.c|  5 +---
 examples/ioat/ioatfwd.c   |  7 +-
 examples/ip_pipeline/cli.c|  9 ++--
 examples/l2fwd-cat/l2fwd-cat.c|  5 +---
 examples/l2fwd-crypto/main.c  |  9 ++--
 examples/l2fwd-event/l2fwd_common.c   |  7 +-
 examples/l2fwd-jobstats/main.c|  9 ++--
 examples/l2fwd-keepalive/main.c   |  7 +-
 examples/l2fwd/main.c |  9 ++--
 examples/link_status_interrupt/main.c |  7 +-
 examples/packet_ordering/main.c   |  5 +---
 examples/pipeline/cli.c   |  4 +---
 examples/rxtx_callbacks/main.c|  4 +---
 examples/server_node_efd/server/main.c|  4 +---
 examples/skeleton/basicfwd.c  |  5 +---
 examples/vhost/main.c | 15 +++-
 examples/vm_power_manager/channel_monitor.c   |  4 +---
 .../guest_cli/vm_power_cli_guest.c|  5 +---
 examples/vm_power_manager/main.c  |  5 +---
 examples/vmdq/main.c  | 12 ++
 examples/vmdq_dcb/main.c  | 12 ++
 lib/net/rte_ether.c   |  7 +-
 lib/net/rte_ether.h   |  9 
 53 files changed, 78 insertions(+), 311 deletions(-)

diff --git a/app/pdump/main.c b/app/pdump/main.c
index 63bbe65cd8..46f9d25db0 100644
--- a/app/pdump/main.c
+++ b/app/pdump/main.c
@@ -612,10 +612,7 @@ configure_vdev(uint16_t port_id)
 
printf("Port %u MAC: %02"PRIx8" %02"PRIx8" %02"PRIx8
" %02"PRIx8" %02"PRIx8" %02"PRIx8"\n",
-   port_id,
-   addr.addr_bytes[0], addr.addr_bytes[1],
-   addr.addr_bytes[2], addr.addr_bytes[3],
-   addr.addr_bytes[4], addr.addr_bytes[5]);
+   port_id, RTE_ETHER_ADDR_BYTES(&addr));
 
ret = rte_eth_promiscuous_enable(port_id);
if (ret != 0) {
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index d4186eb9b2..a5d6c20be1 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -10900,9 +10900,7 @@ static void cmd_mcast_addr_parsed(void *parsed_result,
if (!rte_is_multicast_ether_addr(&res->mc_addr)) {
fprintf(stderr,
"Invalid multicast addr " RTE_ETHER_ADDR_PRT_FMT "\n",
-   res->mc_addr.addr_bytes[0], res->mc_addr.addr_bytes[1],
-   res->mc_addr.addr_bytes[2], res->mc_addr.addr_bytes[3],
-   res->mc_addr.addr_bytes[4], res->mc_addr.addr_b

[dpdk-dev] i40e: cannot strip VLAN header in VF

[David Vodák]

Hi,

I am using DPDK i40e driver for Network Adapter XL710 of the Intel PAC 
N3000 card. I am trying to use API in drivers/net/i40e/rte_pmd_i40e.h to 
insert, filter and strip VLAN headers in virtual functions. Filtering 
and inserting VLAN works fine but striping VLAN headers does not 
(function rte_pmd_i40e_set_vf_vlan_stripq), since I can see packets 
captured in virtual machine (which uses given VF) with VLAN header.


I use DPDK 20.11.0, linux kernel 5.13. The card is bound to vfio driver, 
vfio virtual functions are used by VM's and vfio physical function is 
used by DPDK.


Do you have any idea what could be causing this problem?

Best regards,

David

[dpdk-dev] [PATCH] net/af_xdp: fix zero copy Tx queue drain

[Baruch Siach]

Call xsk_ring_prod__submit() before kick_tx() so that the kernel
consumer sees the updated state of Tx ring. Otherwise, Tx packets are
stuck in the ring until the next call to af_xdp_tx_zc().

Fixes: d8a210774e1d ("net/af_xdp: support unaligned umem chunks")
Cc: sta...@dpdk.org

Signed-off-by: Baruch Siach 
---
 drivers/net/af_xdp/rte_eth_af_xdp.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c 
b/drivers/net/af_xdp/rte_eth_af_xdp.c
index 74ffa4511284..81998d86b4aa 100644
--- a/drivers/net/af_xdp/rte_eth_af_xdp.c
+++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
@@ -502,10 +502,11 @@ af_xdp_tx_zc(void *queue, struct rte_mbuf **bufs, 
uint16_t nb_pkts)
 
if (mbuf->pool == umem->mb_pool) {
if (!xsk_ring_prod__reserve(&txq->tx, 1, &idx_tx)) {
+   xsk_ring_prod__submit(&txq->tx, count);
kick_tx(txq, cq);
if (!xsk_ring_prod__reserve(&txq->tx, 1,
&idx_tx))
-   goto out;
+   goto out_skip_tx;
}
desc = xsk_ring_prod__tx_desc(&txq->tx, idx_tx);
desc->len = mbuf->pkt_len;
@@ -527,7 +528,6 @@ af_xdp_tx_zc(void *queue, struct rte_mbuf **bufs, uint16_t 
nb_pkts)
 
if (!xsk_ring_prod__reserve(&txq->tx, 1, &idx_tx)) {
rte_pktmbuf_free(local_mbuf);
-   kick_tx(txq, cq);
goto out;
}
 
@@ -551,11 +551,11 @@ af_xdp_tx_zc(void *queue, struct rte_mbuf **bufs, 
uint16_t nb_pkts)
tx_bytes += mbuf->pkt_len;
}
 
-   kick_tx(txq, cq);
-
 out:
xsk_ring_prod__submit(&txq->tx, count);
+   kick_tx(txq, cq);
 
+out_skip_tx:
txq->stats.tx_pkts += count;
txq->stats.tx_bytes += tx_bytes;
txq->stats.tx_dropped += nb_pkts - count;
-- 
2.32.0

Re: [dpdk-dev] [PATCH v16] app/testpmd: support multi-process

[Ferruh Yigit]

On 8/16/2021 7:12 PM, Singh, Aman Deep wrote:
> 
> On 8/2/2021 1:33 PM, Thomas Monjalon wrote:
>> 02/08/2021 03:51, Min Hu (Connor):
>>> 在 2021/7/26 15:28, Min Hu (Connor) 写道:
 在 2021/7/26 14:30, Thomas Monjalon 写道:
> 26/07/2021 02:26, Min Hu (Connor):
>> 在 2021/7/24 19:45, Thomas Monjalon 写道:
>>> 10/07/2021 05:50, Min Hu (Connor):
 This patch adds multi-process support for testpmd.
 For example the following commands run two testpmd
 processes:

* the primary process:

 ./dpdk-testpmd --proc-type=auto -l 0-1 -- -i \
  --rxq=4 --txq=4 --num-procs=2 --proc-id=0

* the secondary process:

 ./dpdk-testpmd --proc-type=auto -l 2-3 -- -i \
  --rxq=4 --txq=4 --num-procs=2 --proc-id=1

 Signed-off-by: Min Hu (Connor) 
 Signed-off-by: Lijun Ou 
 Signed-off-by: Andrew Rybchenko 
 Acked-by: Xiaoyun Li 
 Acked-by: Ajit Khaparde 
 Reviewed-by: Ferruh Yigit 
 ---
 V16:
 * revert unrelated changes.
 * add some restrictions in doc.
>>> I didn't see clear agreement to integrate this feature in DPDK 21.08.
>>>
>>> BTW, the testpmd maintainer was not Cc'ed.
>>>
>> Hi, Thomas,
>> This patch has two "acked" and one "reviewed-by".
>> And Xiaoyun Li is the maintainer, I has already Cc'ed to him/her,
>> please check it out, thanks.
> Andrew's comment from v15:
> "
> IMHO, as I state above, current state is insufficient to
> consider is a start point to be applied.
> "
 Hi, Andrew, Thomos,
  What is the least thing should be done for this patch to
 meet the state sufficient to be applied?
>>> Hi, all,
>>> How about this patch, could it be applied?
>> I was not confident enough to apply it in 21.08.
>> When others will be back, we'll discuss it again for 21.11.
>>
> For 21.11 release.
> 
> Acked-by: Aman Deep Singh 
> 

Hi Connor,

Can you please rebase it to latest dpdk (v21.11-rc0) so we can proceed with it?

I am for getting the patch as early as possible in the release cycle, specially
before it is getting busy for -rc1.

Thanks,
ferruh

Re: [dpdk-dev] [dpdk-ci] [PATCH] version: 21.11-rc0

[Lincoln Lavoie]

Hi David,

We'll check.  Owen was working on a change to allow ABI to still run for
merges onto the 20.11 branch, so the LTS branches can remain stable, while
per-patch testing is off for the 21.11 release.  Looks like that has a side
effect for how these patches were flagged in the system.

Cheers,
Lincoln

On Tue, Aug 24, 2021 at 3:58 AM David Marchand 
wrote:

> Hello Lincoln,
>
> On Tue, Aug 17, 2021 at 2:04 PM Lincoln Lavoie 
> wrote:
> >
> > Hi David,
> >
> > ABI testing was disable / stopped on Friday in the Community CI lab.
> Patches from before that for 21.11 would have still had the test run and
> could have failures listed. I'm not sure if there is a way to "remove"
> those failure marks from patchworks.  But, for all new patches since then,
> ABI hasn't been run.
>
> I can see new reports for ABI, please can someone from UNH double check?
> https://lab.dpdk.org/results/dashboard/patchsets/18301/
> https://lab.dpdk.org/results/dashboard/patchsets/18303/
> https://lab.dpdk.org/results/dashboard/patchsets/18325/
>
>
> --
> David Marchand
>
>

-- 
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
lylav...@iol.unh.edu
https://www.iol.unh.edu
+1-603-674-2755 (m)

Re: [dpdk-dev] [RFC 0/1] app/testpmd: add l3fwd mode to testpmd

[Ferruh Yigit]

On 7/2/2021 11:15 AM, Andrew Rybchenko wrote:
> @Xiaoyun could you share your thoughts on it?
> 
> As far as I remember there is no agreement on the topic. Adding
> more people in Cc.
> 

I was OK for adding simple l3fwd forwarding engine to testpmd, to benefit from
configuration/debugging/measurement benefits testpmd brings as patch mentions.

But adding neon will likely bring other architecture specific implementations,
and there will be more code duplicates, which is not good.
Also it is possible that people may want to add more lookup methods (em, fib..)
making things worse.

If we get the feature, what about limiting it to scalar implementation and LPM?
Still it is questionable to have the feature in the testpmd, but at least we
limit the scope.
For performance measurements can use the l3fwd sample application.

Another point is testing, this feature should come with dts updates to test
testpmd l3fwd, otherwise it may not be tested and turn into dead code easily.


> On 5/1/21 12:37 AM, Kathleen Capella wrote:
>> Performance of the LPM mode in L3fwd example application is used as an 
>> industry
>> standard to compare between various platforms.
>>
>> Unfortunately, L3fwd example application lacks debugging capabilities to
>> understand the performance bottlenecks and fix them.
>>
>> While debugging performance issues we need all the flexibility possible.
>> Some of the capabilities we have used are:
>> 1) ability to print hardware and software statistics - xstats, stats at
>>port/queue level, burst stats to identify any headroom available,
>>CPU cycles/packet etc
>> 2) ability to modify all possible configurable parameters for the PMD
>>as well as the application at run time without recompiling the code.
>>Some of the parameters we have used are RX/TX queue depths, burst size,
>>number of receive queues, PMD specific parameters etc. This
>>configurability at runtime helps to understand and debug L3fwd
>>performance issues quickly and effectively.
>>
>> It is possible to add all these capabilities to L3fwd example application.
>> However, doing that we will result in L3fwd example application losing
>> its purpose (of being a sample application). At the same time, testpmd
>> application has all these capabilities to debug an application. In my opinion
>> it makes sense to add L3fwd mode to testpmd.
>>
>> This patch adds l3fwd mode into testpmd to take advantage of the
>> existing infrastructure in testpmd.
>>
>> I'd like to hear from the community if the structure of this change makes 
>> sense,
>> namely, adding l3fwd as a separate fwd_engine into testpmd.
>>
>> This feature is not yet implemeted for SSE or AltiVec.
>>
>> Kathleen Capella (1):
>>   app/testpmd: add l3fwd mode to testpmd
>>
>>  app/test-pmd/config.c |  66 +++
>>  app/test-pmd/l3fwd.c  | 356 ++
>>  app/test-pmd/l3fwd.h  | 143 ++
>>  app/test-pmd/l3fwd_common.h   | 268 +
>>  app/test-pmd/l3fwd_lpm.h  | 107 ++
>>  app/test-pmd/l3fwd_lpm_neon.h | 169 
>>  app/test-pmd/l3fwd_neon.h | 234 ++
>>  app/test-pmd/meson.build  |   3 +-
>>  app/test-pmd/testpmd.c|   4 +-
>>  app/test-pmd/testpmd.h|  20 ++
>>  10 files changed, 1368 insertions(+), 2 deletions(-)
>>  create mode 100644 app/test-pmd/l3fwd.c
>>  create mode 100644 app/test-pmd/l3fwd.h
>>  create mode 100644 app/test-pmd/l3fwd_common.h
>>  create mode 100644 app/test-pmd/l3fwd_lpm.h
>>  create mode 100644 app/test-pmd/l3fwd_lpm_neon.h
>>  create mode 100644 app/test-pmd/l3fwd_neon.h
>>
> 

Re: [dpdk-dev] [PATCH 3/3] net/bonding: start ethdev prior to setting 8023ad flow

[Ferruh Yigit]

On 7/15/2021 2:58 PM, Thomas Monjalon wrote:
> 14/07/2021 17:00, Jan Viktorin:
 On Tue, 13 Jul 2021 12:26:35 +0300
 Andrew Rybchenko  wrote:
>> This matters for the bonding case as well, doesn't it?.
>> It is not desirable to accidently omit a packet that was
>> received by primary ingress logic instead of being
>> redirected into the dedicated queue.
>>
>> Are there any chances that for mlx5 it would be possible
>> to insert flow rules before calling rte_eth_dev_start?
>> Anyway, the behaviour should be specified and documented
>> in DPDK more precisely to avoid such uncertainty in the
>> future. 
> I agree the documentation should be fixed.  

 +1  
>
> Cc Thomas and Ferruh since ethdev documentation should be
> clarified.
>
> It looks like there is no consensus if the patch is a right
> direction or wrong. For me it looks wrong taking all above
> arguments in to account (mainly necessity to be able to insert
> flows before pushing start button which enables the traffic if HW
> supports it).
>
> So, I'm applying first two patches and hold on this one.  
>>
>> Andrew, I believe that it would be helpful to start some new thread
>> otherwise we would get lost here :). It seems that we will have few
>> more fixes for the bonding driver. Do you prefer an entirely new
>> patchset or v2 of this topic? Or any other advise how to proceed?
> 
> This thread is about 3 things:
>   - bonding issue
>   - ethdev doc
>   - mlx5 design
> That's too much topics to address in one thread :)
> 
> You may restart the discussion with a doc update
> if the stop/start requirement is not clear.
> 
> 

Is separate discussions created as follow up?

Re: [dpdk-dev] [PATCH v16] app/testpmd: support multi-process

[Min Hu (Connor)]

Thanks Ferruh, I will handle it as quickly as possible.

在 2021/8/24 20:18, Ferruh Yigit 写道:

On 8/16/2021 7:12 PM, Singh, Aman Deep wrote:


On 8/2/2021 1:33 PM, Thomas Monjalon wrote:

02/08/2021 03:51, Min Hu (Connor):

在 2021/7/26 15:28, Min Hu (Connor) 写道:

在 2021/7/26 14:30, Thomas Monjalon 写道:

26/07/2021 02:26, Min Hu (Connor):

在 2021/7/24 19:45, Thomas Monjalon 写道:

10/07/2021 05:50, Min Hu (Connor):

This patch adds multi-process support for testpmd.
For example the following commands run two testpmd
processes:

* the primary process:

./dpdk-testpmd --proc-type=auto -l 0-1 -- -i \
  --rxq=4 --txq=4 --num-procs=2 --proc-id=0

* the secondary process:

./dpdk-testpmd --proc-type=auto -l 2-3 -- -i \
  --rxq=4 --txq=4 --num-procs=2 --proc-id=1

Signed-off-by: Min Hu (Connor) 
Signed-off-by: Lijun Ou 
Signed-off-by: Andrew Rybchenko 
Acked-by: Xiaoyun Li 
Acked-by: Ajit Khaparde 
Reviewed-by: Ferruh Yigit 
---
V16:
* revert unrelated changes.
* add some restrictions in doc.

I didn't see clear agreement to integrate this feature in DPDK 21.08.

BTW, the testpmd maintainer was not Cc'ed.


Hi, Thomas,
This patch has two "acked" and one "reviewed-by".
And Xiaoyun Li is the maintainer, I has already Cc'ed to him/her,
please check it out, thanks.

Andrew's comment from v15:
"
IMHO, as I state above, current state is insufficient to
consider is a start point to be applied.
"

Hi, Andrew, Thomos,
  What is the least thing should be done for this patch to
meet the state sufficient to be applied?

Hi, all,
How about this patch, could it be applied?

I was not confident enough to apply it in 21.08.
When others will be back, we'll discuss it again for 21.11.


For 21.11 release.

Acked-by: Aman Deep Singh 



Hi Connor,

Can you please rebase it to latest dpdk (v21.11-rc0) so we can proceed with it?

I am for getting the patch as early as possible in the release cycle, specially
before it is getting busy for -rc1.

Thanks,
ferruh
.

Re: [dpdk-dev] [RFC 12/15] eventdev: move timer adapters memory to hugepage

[Carrillo, Erik G]

Hi Pavan,

> -Original Message-
> From: pbhagavat...@marvell.com 
> Sent: Monday, August 23, 2021 2:40 PM
> To: jer...@marvell.com; Carrillo, Erik G 
> Cc: Ananyev, Konstantin ; dev@dpdk.org;
> Pavan Nikhilesh 
> Subject: [dpdk-dev] [RFC 12/15] eventdev: move timer adapters memory to
> hugepage
> 
> From: Pavan Nikhilesh 
> 
> Move memory used by timer adapters to hugepage.
> Allocate memory on the first adapter create or lookup to address both
> primary and secondary process usecases.
> 

Is the motivation for this change performance or space improvement?  Can we add 
something to the commit message to say?

Thanks,
Erik

> Signed-off-by: Pavan Nikhilesh 
> ---
>  lib/eventdev/rte_event_timer_adapter.c | 24
> +++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/eventdev/rte_event_timer_adapter.c
> b/lib/eventdev/rte_event_timer_adapter.c
> index ae55407042..c4dc7a5fd4 100644
> --- a/lib/eventdev/rte_event_timer_adapter.c
> +++ b/lib/eventdev/rte_event_timer_adapter.c
> @@ -33,7 +33,7 @@ RTE_LOG_REGISTER_SUFFIX(evtim_logtype,
> adapter.timer, NOTICE);
> RTE_LOG_REGISTER_SUFFIX(evtim_buffer_logtype, adapter.timer, NOTICE);
> RTE_LOG_REGISTER_SUFFIX(evtim_svc_logtype, adapter.timer.svc,
> NOTICE);
> 
> -static struct rte_event_timer_adapter
> adapters[RTE_EVENT_TIMER_ADAPTER_NUM_MAX];
> +static struct rte_event_timer_adapter *adapters;
> 
>  static const struct event_timer_adapter_ops swtim_ops;
> 
> @@ -138,6 +138,17 @@ rte_event_timer_adapter_create_ext(
>   int n, ret;
>   struct rte_eventdev *dev;
> 
> + if (adapters == NULL) {
> + adapters = rte_zmalloc("Eventdev",
> +sizeof(struct rte_event_timer_adapter) *
> +
> RTE_EVENT_TIMER_ADAPTER_NUM_MAX,
> +RTE_CACHE_LINE_SIZE);
> + if (adapters == NULL) {
> + rte_errno = ENOMEM;
> + return NULL;
> + }
> + }
> +
>   if (conf == NULL) {
>   rte_errno = EINVAL;
>   return NULL;
> @@ -312,6 +323,17 @@ rte_event_timer_adapter_lookup(uint16_t
> adapter_id)
>   int ret;
>   struct rte_eventdev *dev;
> 
> + if (adapters == NULL) {
> + adapters = rte_zmalloc("Eventdev",
> +sizeof(struct rte_event_timer_adapter) *
> +
> RTE_EVENT_TIMER_ADAPTER_NUM_MAX,
> +RTE_CACHE_LINE_SIZE);
> + if (adapters == NULL) {
> + rte_errno = ENOMEM;
> + return NULL;
> + }
> + }
> +
>   if (adapters[adapter_id].allocated)
>   return &adapters[adapter_id]; /* Adapter is already loaded
> */
> 
> --
> 2.17.1

Re: [dpdk-dev] [RFC V2] ethdev: fix issue that dev close in PMD calls twice

[Ferruh Yigit]

On 8/19/2021 4:45 AM, Huisong Li wrote:
> 在 2021/8/18 19:24, Ferruh Yigit 写道:
>> On 8/13/2021 9:16 AM, Huisong Li wrote:
>>> 在 2021/8/13 14:12, Thomas Monjalon 写道:
 13/08/2021 04:11, Huisong Li:
> Hi, all
>
> This patch can enhance the security of device uninstallation to
> eliminate dependency on user usage methods.
>
> Can you check this patch?
>
>
> 在 2021/8/3 10:30, Huisong Li 写道:
>> Ethernet devices in DPDK can be released by rte_eth_dev_close() and
>> rte_dev_remove(). These APIs both call xxx_dev_close() in PMD layer
>> to uninstall hardware. However, the two APIs do not have explicit
>> invocation restrictions. In other words, at the ethdev layer, it is
>> possible to call rte_eth_dev_close() before calling rte_dev_remove()
>> or rte_eal_hotplug_remove(). In such a bad scenario,
 It is not a bad scenario.
 If there is no more port for the device after calling close,
 the device should be removed automatically.
 Keep in mind "close" is for one port, "remove" is for the entire device
 which can have more than one port.
>>> I know.
>>>
>>> dev_close() is for removing an eth device. And rte_dev_remove() can be used
>>>
>>> for removing the rte device and all its eth devices belonging to the rte 
>>> device.
>>>
>>> In rte_dev_remove(), "remove" is executed in primary or one of secondary,
>>>
>>> all eth devices having same pci address will be closed and removed.
>>>
>> the primary
>> process may be fine, but it may cause that xxx_dev_close() in the PMD
>> layer will be called twice in the secondary process. So this patch
>> fixes it.
 If a port is closed in primary, it should be the same in secondary.


>> +    /*
>> + * The eth_dev->data->name doesn't be cleared by the secondary 
>> process,
>> + * so above "eth_dev" isn't NULL after rte_eth_dev_close() called.
 This assumption is not clear. All should be closed together.
>>> However, dev_close() does not have the feature similar to rte_dev_remove().
>>>
>>> Namely, it is not guaranteed that all eth devices are closed together in 
>>> ethdev
>>> layer. It depends on app or user.
>>>
>>> If the app does not close together, the operation of repeatedly 
>>> uninstalling an
>>> eth device in the secondary process
>>>
>>> will be triggered when dev_close() is first called by one secondary 
>>> process, and
>>> then rte_dev_remove() is called.
>>>
>>> So I think it should be avoided.
>> First of all, I am not sure about calling 'rte_eth_dev_close()' or
>> 'rte_dev_remove()' from the secondary process.
>> There are explicit checks in various locations to prevent clearing resources
>> completely from secondary process.
> 
> There's no denying that.
> 
> Generally, hardware resources of eth device and shared data of the primary and
> secondary process
> 
> are cleared by primary, which are controled by ethdev layer or PMD layer.
> 
> But there may be some private data or resources of each process (primary or
> secondary ), such as mp action
> 
> registered by rte_mp_action_register() or others.  For these resources, the
> secondary process still needs to clear.
> 
> Namely, both primary and secondary processes need to prevent repeated 
> offloading
> of resources.
> 
>>
>> Calling 'rte_eth_dev_close()' or 'rte_dev_remove()' by secondary is 
>> technically
>> can be done but application needs to be extra cautious and should take extra
>> measures and synchronization to make it work.
>> Regular use-case is secondary processes do the packet processing and all 
>> control
>> commands run by primary.
> 
> You are right. We have a consensus that 'rte_eth_dev_close()' or 
> 'rte_dev_remove()'
> 
> can be called by primary and secondary processes.
> 
> But DPDK framework cannot assume user behavior.😁
> 
> We need to make it more secure and reliable for both primary and secondary
> processes.
> 
>>
>> In primary, if you call 'rte_eth_dev_close()' it will clear all ethdev 
>> resources
>> and further 'rte_dev_remove()' call will detect missing ethdev resources and
>> won't try to clear them again.
>>
>> In secondary, if you call 'rte_eth_dev_close()', it WON'T clear all resources
>> and further 'rte_dev_remove()' call (either from primary or secondary) will 
>> try
>> to clean ethdev resources again. You are trying to prevent this retry in 
>> remove
>> happening for secondary process.
> 
> Right. However, if secondary process in PMD layer has its own private 
> resources
> to be
> 
> cleared, it still need to do it by calling 'rte_eth_dev_close()' or
> 'rte_dev_remove()'.
> 
>> In secondary it won't free ethdev resources anyway if you let it continue, 
>> but I
>> guess here you are trying to prevent the PMD dev_close() called again. Why? 
>> Is
>> it just for optimization or does it cause unexpected behavior in the PMD?
>>
>>
>> Overall, to free resources you need to do the 'rte_eth_dev_close()' or
>> 'rte_dev_remove()' in the pri

Re: [dpdk-dev] [RFC 0/1] app/testpmd: add l3fwd mode to testpmd

[Honnappa Nagarahalli]

> 
> On 7/2/2021 11:15 AM, Andrew Rybchenko wrote:
> > @Xiaoyun could you share your thoughts on it?
> >
> > As far as I remember there is no agreement on the topic. Adding more
> > people in Cc.
> >
> 
> I was OK for adding simple l3fwd forwarding engine to testpmd, to benefit from
> configuration/debugging/measurement benefits testpmd brings as patch
> mentions.
> 
> But adding neon will likely bring other architecture specific implementations,
> and there will be more code duplicates, which is not good.
> Also it is possible that people may want to add more lookup methods (em, 
> fib..)
> making things worse.
The main goal we are trying to address is the ability to debugging the 
performance issues of the L3fwd application. As far as I know, the marketing 
folks care about LPM (may be replace LPM with fib). We could definitely avoid 
adding exact match.
Since the L3fwd application is about showcasing the best possible performance, 
it is better to keep vector implementation and skip scalar code. This will help 
debug the correct code path.

> 
> If we get the feature, what about limiting it to scalar implementation and 
> LPM?
I agree with LPM, scalar only might not be very useful.

> Still it is questionable to have the feature in the testpmd, but at least we 
> limit
> the scope.
> For performance measurements can use the l3fwd sample application.
> 
> Another point is testing, this feature should come with dts updates to test
> testpmd l3fwd, otherwise it may not be tested and turn into dead code easily.
Agree

> 
> 
> > On 5/1/21 12:37 AM, Kathleen Capella wrote:
> >> Performance of the LPM mode in L3fwd example application is used as
> >> an industry standard to compare between various platforms.
> >>
> >> Unfortunately, L3fwd example application lacks debugging capabilities
> >> to understand the performance bottlenecks and fix them.
> >>
> >> While debugging performance issues we need all the flexibility possible.
> >> Some of the capabilities we have used are:
> >> 1) ability to print hardware and software statistics - xstats, stats at
> >>port/queue level, burst stats to identify any headroom available,
> >>CPU cycles/packet etc
> >> 2) ability to modify all possible configurable parameters for the PMD
> >>as well as the application at run time without recompiling the code.
> >>Some of the parameters we have used are RX/TX queue depths, burst size,
> >>number of receive queues, PMD specific parameters etc. This
> >>configurability at runtime helps to understand and debug L3fwd
> >>performance issues quickly and effectively.
> >>
> >> It is possible to add all these capabilities to L3fwd example application.
> >> However, doing that we will result in L3fwd example application
> >> losing its purpose (of being a sample application). At the same time,
> >> testpmd application has all these capabilities to debug an
> >> application. In my opinion it makes sense to add L3fwd mode to testpmd.
> >>
> >> This patch adds l3fwd mode into testpmd to take advantage of the
> >> existing infrastructure in testpmd.
> >>
> >> I'd like to hear from the community if the structure of this change
> >> makes sense, namely, adding l3fwd as a separate fwd_engine into testpmd.
> >>
> >> This feature is not yet implemeted for SSE or AltiVec.
> >>
> >> Kathleen Capella (1):
> >>   app/testpmd: add l3fwd mode to testpmd
> >>
> >>  app/test-pmd/config.c |  66 +++
> >>  app/test-pmd/l3fwd.c  | 356 ++
> >>  app/test-pmd/l3fwd.h  | 143 ++
> >>  app/test-pmd/l3fwd_common.h   | 268 +
> >>  app/test-pmd/l3fwd_lpm.h  | 107 ++
> >>  app/test-pmd/l3fwd_lpm_neon.h | 169 
> >>  app/test-pmd/l3fwd_neon.h | 234 ++
> >>  app/test-pmd/meson.build  |   3 +-
> >>  app/test-pmd/testpmd.c|   4 +-
> >>  app/test-pmd/testpmd.h|  20 ++
> >>  10 files changed, 1368 insertions(+), 2 deletions(-)  create mode
> >> 100644 app/test-pmd/l3fwd.c  create mode 100644 app/test-pmd/l3fwd.h
> >> create mode 100644 app/test-pmd/l3fwd_common.h  create mode 100644
> >> app/test-pmd/l3fwd_lpm.h  create mode 100644
> >> app/test-pmd/l3fwd_lpm_neon.h  create mode 100644
> >> app/test-pmd/l3fwd_neon.h
> >>
> >

[dpdk-dev] Zeroing out memory on free

[Dmitry Kozlyuk]

Hello,

Me and Xueming are wondering why DPDK clears the memory on free
and not only when it's explicitly requested (rte_zmalloc).

It's been so for a while:

commit ea0bddbd14e68fb42d9774bc3543e51b510e48d3
Author: Sergio Gonzalez Monroy 
Date:   Tue Jul 5 12:01:15 2016 +0100

mem: zero out memory on free

Since commit fafcc11985a2, memzones are not guaranteed to be zeroed out.
This could potentially cause issues as applications might have been
relying on the allocated memory being zeroed out.

On init all allocated memory is zeroed by the kernel, so by zeroing out
memory on free, all available dpdk memory is always zeroed.

Fixes: fafcc11985a2 ("mem: rework memzone to be allocated by malloc")

Signed-off-by: Sergio Gonzalez Monroy 

At present this explanation doesn't look satisfying:
1. Memzone API does not promise they will be zeroed out.
   Memzones are mostly used for DMA, so their content will likely be 
overwritten.
2. If application assumptions are wrong, DPDK should not try to fix it.
   Memory manager poisons memory in debug mode to detect such errors.

Zeroing memory is quite slow, but in many cases unneeded.
It looks attractive to only do it in rte_zmalloc().
AFAIK what prohibits moving memset() there unconditionally
is that the kernel already gives us cleared pages,
so the first allocation of each piece of memory would do unnecessary work.
This can be solved by giving the user a choice in EAL options
or with more elaborate tracking of memory dirtiness in MM.
Are there any other reasons why clearing is done the current way?

Re: [dpdk-dev] [PATCH v6 1/2] net: added macro for MAC address print

[Stephen Hemminger]

On Tue, 24 Aug 2021 16:33:25 +0530
Aman Singh  wrote:

> diff --git a/lib/net/rte_ether.h b/lib/net/rte_ether.h
> index 7ee5e9a292..8d126d4c81 100644
> --- a/lib/net/rte_ether.h
> +++ b/lib/net/rte_ether.h
> @@ -221,6 +221,11 @@ rte_ether_addr_copy(const struct rte_ether_addr 
> *__restrict ea_from,
>   *ea_to = *ea_from;
>  }
>  
> +/**
> + * Macro to print six-bytes of MAC address in hex format
> + */
> +#define RTE_ETHER_ADDR_PRT_FMT "%02X:%02X:%02X:%02X:%02X:%02X"
> +
>  #define RTE_ETHER_ADDR_FMT_SIZE 18
>  /**
>   * Format 48bits Ethernet address in pattern xx:xx:xx:xx:xx:xx.

Please uses same macro in rte_ether_format_addr

Re: [dpdk-dev] [RFC 11/15] eventdev: reserve fields in timer object

[Stephen Hemminger]

On Tue, 24 Aug 2021 01:10:15 +0530
 wrote:

> From: Pavan Nikhilesh 
> 
> Reserve fields in rte_event_timer data structure to address future
> use cases.
> Also, remove volatile from rte_event_timer.
> 
> Signed-off-by: Pavan Nikhilesh 

Reserve fields are not a good idea. They don't solve future API/ABI problems.

The issue is that you need to zero them and check they are zero otherwise
they can't safely be used later.  This happened with the Linux kernel
system calls where in several cases a flag field was added for future.
The problem is that old programs would work with any garbage in the flag
field, and therefore the flag could not be extended.

A better way to make structures internal opaque objects that
can be resized.  Why is rte_event_timer_adapter exposed in API?

Re: [dpdk-dev] [PATCH] net/virtio: wait device ready in device reset

[Andrew Rybchenko]

On 8/23/21 4:54 PM, Xueming(Steven) Li wrote:
> 
> 
>> -Original Message-
>> From: Andrew Rybchenko 
>> Sent: Monday, August 23, 2021 5:57 PM
>> To: Xueming(Steven) Li 
>> Cc: dev@dpdk.org; Maxime Coquelin ; Chenbo Xia 
>> 
>> Subject: Re: [dpdk-dev] [PATCH] net/virtio: wait device ready in device reset
>>
>> On 8/23/21 9:39 AM, Xueming Li wrote:
>>> According to virtio spec, the device MUST reset when 0 is written to
>>> device_status, and present a 0 in device_status once that is done.
>>>
>>> This patch adds the missing part of waiting status 0 in reset function.
>>>
>>> Signed-off-by: Xueming Li 
>>> ---
>>>  drivers/net/virtio/virtio.c | 7 +--
>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/virtio/virtio.c b/drivers/net/virtio/virtio.c
>>> index 7e1e77797f..f003f612d6 100644
>>> --- a/drivers/net/virtio/virtio.c
>>> +++ b/drivers/net/virtio/virtio.c
>>> @@ -3,6 +3,8 @@
>>>   * Copyright(c) 2020 Red Hat, Inc.
>>>   */
>>>
>>> +#include 
>>> +
>>>  #include "virtio.h"
>>>
>>>  uint64_t
>>> @@ -39,8 +41,9 @@ void
>>>  virtio_reset(struct virtio_hw *hw)
>>>  {
>>> VIRTIO_OPS(hw)->set_status(hw, VIRTIO_CONFIG_STATUS_RESET);
>>> -   /* flush status write */
>>> -   VIRTIO_OPS(hw)->get_status(hw);
>>> +   /* Flush status write and wait device ready. */
>>> +   while (VIRTIO_OPS(hw)->get_status(hw) != VIRTIO_CONFIG_STATUS_RESET)
>>> +   usleep(1000L);
>>
>> Don't we need a protection against forever loop here?
> 
> Good question, ideally we need, kernel driver function vp_reset() seems to 
> have same issue.

Yes, I've seen it.

> How about leaving an error message before return? 

@Maxime, @Chenbo, what do you think?

Re: [dpdk-dev] [PATCH V3 1/2] netdev-offload-dpdk: Use has_vlan match attribute

[Ilya Maximets]

On 8/24/21 5:25 PM, Eli Britstein wrote:
> 
> On 8/24/2021 6:08 PM, Finn, Emma wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> -Original Message-
>> From: Eli Britstein 
>> Sent: Monday 16 August 2021 14:55
>> To: d...@openvswitch.org; Ilya Maximets 
>> Cc: Finn, Emma ; Stokes, Ian ; 
>> Sriharsha Basavapatna ; Gaetan Rivet 
>> ; Majd Dibbiny ; Eli Britstein 
>> ; Salem Sol 
>> Subject: [PATCH V3 1/2] netdev-offload-dpdk: Use has_vlan match attribute
>>
>> DPDK 20.11 introduced an ability to specify existance/non-existance of VLAN 
>> tag by [1].
>> Use this attribute.
>>
>> [1]: 09315fc83861 ("ethdev: add VLAN attributes to ethernet and VLAN items")
>>
>> Signed-off-by: Eli Britstein 
>> Reviewed-by: Salem Sol 
>>
>> Hi Eli,
>>
>> I tested this but currently we don't have support in the i40e pmd for the 
>> has_vlan match attribute and with these patches it is breaking offload for 
>> VLAN packets on Intel devices.
> 
> Hi Emma,
> 
> Thanks for testing.
> 
> Is adding such support in your plans?
> 
> How do you suggest to proceed? It is needed in order to fix OVS bug.
> 
> Thanks,
> 
> Eli

The "Table 1.2 rte_flow items availability in networking drivers"
here: https://doc.dpdk.org/guides/nics/overview.html
says that both ixgbe and i40e has a full support for 'vlan' and
'eth' items.  Is it a bug?  Should it be 'partial' instead?

In general, this sounds like a big limitation of rte_flow API.
I mean the fact that there is no way to get what is implemented by
a particular driver and what is not implemented in runtime.
Someone should, probably, work on adding this kind of API to DPDK.
Otherwise, we will stuck with inability to use certain actions/matches
unless all the drivers supports them (which is also hard to check
taking documentation issues into account).  If I missed it and the
API actually exists, we should definitely start using it.

CC: dpdk-dev and rte_flow maintainers.

Thoughts?

Best regards, Ilya Maximets.

Re: [dpdk-dev] [PATCH v8] eal: remove sys/queue.h from public headers.

[William Tu]

On Mon, Aug 23, 2021 at 12:14 PM Dmitry Kozlyuk
 wrote:
>
> 2021-08-23 13:03 (UTC+), William Tu:
> [...]
> >  /* This macro permits both remove and free var within the loop safely.*/
> > -#ifndef TAILQ_FOREACH_SAFE
> > -#define TAILQ_FOREACH_SAFE(var, head, field, tvar)   \
> > - for ((var) = TAILQ_FIRST((head));   \
> > - (var) && ((tvar) = TAILQ_NEXT((var), field), 1);\
> > +#ifndef RTE_TAILQ_FOREACH_SAFE
> > +#define RTE_TAILQ_FOREACH_SAFE(var, head, field, tvar) \
> > + for ((var) = RTE_TAILQ_FIRST((head)); \
> > + (var) && ((tvar) = RTE_TAILQ_NEXT((var), field), 1); \
> >   (var) = (tvar))
> >  #endif
>
> 1. Unlike TAILQ_FOREACH_SAFE, new RTE_ macro doesn't need #ifdef.
>
> 2. There should be no period at the end of the subject
>(./devtools/check-git-log.sh would show that).
>
> Except for these nits,
> Acked-by: Dmitry Kozlyuk 

Thanks for your review.
I will fix it and send another version.
William

Re: [dpdk-dev] [PATCH V3 1/2] netdev-offload-dpdk: Use has_vlan match attribute

[Ilya Maximets]

On 8/24/21 6:04 PM, Eli Britstein wrote:
> 
> On 8/24/2021 6:47 PM, Ilya Maximets wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On 8/24/21 5:25 PM, Eli Britstein wrote:
>>> On 8/24/2021 6:08 PM, Finn, Emma wrote:
 External email: Use caution opening links or attachments


 -Original Message-
 From: Eli Britstein 
 Sent: Monday 16 August 2021 14:55
 To: d...@openvswitch.org; Ilya Maximets 
 Cc: Finn, Emma ; Stokes, Ian ; 
 Sriharsha Basavapatna ; Gaetan Rivet 
 ; Majd Dibbiny ; Eli Britstein 
 ; Salem Sol 
 Subject: [PATCH V3 1/2] netdev-offload-dpdk: Use has_vlan match attribute

 DPDK 20.11 introduced an ability to specify existance/non-existance of 
 VLAN tag by [1].
 Use this attribute.

 [1]: 09315fc83861 ("ethdev: add VLAN attributes to ethernet and VLAN 
 items")

 Signed-off-by: Eli Britstein 
 Reviewed-by: Salem Sol 

 Hi Eli,

 I tested this but currently we don't have support in the i40e pmd for the 
 has_vlan match attribute and with these patches it is breaking offload for 
 VLAN packets on Intel devices.
>>> Hi Emma,
>>>
>>> Thanks for testing.
>>>
>>> Is adding such support in your plans?
>>>
>>> How do you suggest to proceed? It is needed in order to fix OVS bug.
>>>
>>> Thanks,
>>>
>>> Eli
>> The "Table 1.2 rte_flow items availability in networking drivers"
>> here: https://doc.dpdk.org/guides/nics/overview.html
>> says that both ixgbe and i40e has a full support for 'vlan' and
>> 'eth' items.  Is it a bug?  Should it be 'partial' instead?
>>
>> In general, this sounds like a big limitation of rte_flow API.
>> I mean the fact that there is no way to get what is implemented by
>> a particular driver and what is not implemented in runtime.
>> Someone should, probably, work on adding this kind of API to DPDK.
>> Otherwise, we will stuck with inability to use certain actions/matches
>> unless all the drivers supports them (which is also hard to check
>> taking documentation issues into account).  If I missed it and the
>> API actually exists, we should definitely start using it.
>>
>> CC: dpdk-dev and rte_flow maintainers.
>>
>> Thoughts?
> 
> There is such an API - rte_flow_validate().
> 
> However, in OVS, as each flow is independent and can have different matches 
> and actions, we just call rte_flow_create(). The PMD (at least mlx5) first 
> internally validates it (as if rte_flow_validate() is called), and bail out 
> with a failure in case validate fails.
> 
> Can you suggest an effective way to utilize it in OVS?

This one is hard to use.  And I guess, it's hard to determine
what exactly is not supported as some things can be only
supported in certain combinations or otherwise not supported in
certain combinations.  So, rte_flow_validate() doesn't seem to
be suitable for checking particular features and alternating
the flow construction based on that.  If we had clear yes/no
flags for all features that could be easily probed/verified or
otherwise retrived from the driver, that would be better.

But it seems to be a problem for current rte_flow implementations
in actual drivers.

> 
> In theory, if the API exists in rte_flow, OVS should not care if all PMDs 
> support it or not.
> 
> In practice, the "has_vlan" field was introduced only in 20.11, and 
> apparently Intel has not adapted i40e PMD, so it breaks their offloads. I 
> suspected this so I've added Emma and Ian to review it.
> 
> I don't know i40e HW capabilities, but at least from PMD point of view, it 
> can be silently ignored until a proper support is added.
> 
>>
>> Best regards, Ilya Maximets.

[dpdk-dev] [PATCH v9] eal: remove sys/queue.h from public headers

[William Tu]

Currently there are some public headers that include 'sys/queue.h', which
is not POSIX, but usually provided by the Linux/BSD system library.
(Not in POSIX.1, POSIX.1-2001, or POSIX.1-2008. Present on the BSDs.)
The file is missing on Windows. During the Windows build, DPDK uses a
bundled copy, so building a DPDK library works fine.  But when OVS or other
applications use DPDK as a library, because some DPDK public headers
include 'sys/queue.h', on Windows, it triggers an error due to no such
file.

One solution is to install the 'lib/eal/windows/include/sys/queue.h' into
Windows environment, such as [1]. However, this means DPDK exports the
functionalities of 'sys/queue.h' into the environment, which might cause
symbols, macros, headers clashing with other applications.

The patch fixes it by removing the "#include " from
DPDK public headers, so programs including DPDK headers don't depend
on the system to provide 'sys/queue.h'. When these public headers use
macros such as TAILQ_xxx, we replace it by the ones with RTE_ prefix.
For Windows, we copy the definitions from  to rte_os.h
in Windows EAL. Note that these RTE_ macros are compatible with
, both at the level of API (to use with 
macros in C files) and ABI (to avoid breaking it).

Additionally, the TAILQ_FOREACH_SAFE is not part of ,
the patch replaces it with RTE_TAILQ_FOREACH_SAFE.

[1] http://mails.dpdk.org/archives/dev/2021-August/216304.html

Suggested-by: Nick Connolly 
Suggested-by: Dmitry Kozliuk 
Acked-by: Dmitry Kozliuk 
Signed-off-by: William Tu 
---
v8-v9:
* Acked by Dmitry Kozliuk
* remove #ifdef at RTE_TAILQ_FOREACH_SAFE
* remove period at title
v7-v8:
* remove duplicate RTE_TAILQ_FOREACH_SAFE at rte_os.h
  put the macro at rte_tailq.h
* remove inline comments
* diff
  https://github.com/williamtu/dpdk/compare/a4144ff11b..6cb7cd8daf
v6-v7:
* remove some redundant "#incldue "
* remove extra newline, add comment at rte_os.h for windows
  use of bundled sys/queue

v5-v6:
* fix tab/indent issue, fix type and spelling
* fix duplicate RTE_TAILQ_FOREACH_SAFE
* fix build error due to drivers/net/mlx5/mlx5_flow_meter.c
---

 drivers/bus/auxiliary/private.h|  1 +
 drivers/bus/auxiliary/rte_bus_auxiliary.h  |  5 ++--
 drivers/bus/dpaa/dpaa_bus.c|  4 ++--
 drivers/bus/fslmc/fslmc_bus.c  |  4 ++--
 drivers/bus/fslmc/fslmc_vfio.c |  9 +---
 drivers/bus/ifpga/rte_bus_ifpga.h  |  8 +++
 drivers/bus/pci/pci_params.c   |  2 ++
 drivers/bus/pci/rte_bus_pci.h  | 13 +--
 drivers/bus/pci/windows/pci.c  |  3 +++
 drivers/bus/pci/windows/pci_netuio.c   |  2 ++
 drivers/bus/vdev/rte_bus_vdev.h|  7 +++---
 drivers/bus/vdev/vdev.c|  3 ++-
 drivers/bus/vmbus/rte_bus_vmbus.h  | 13 +--
 drivers/net/bnxt/tf_ulp/bnxt_ulp.c |  2 +-
 drivers/net/bonding/rte_eth_bond_flow.c|  2 +-
 drivers/net/failsafe/failsafe_flow.c   |  2 +-
 drivers/net/i40e/i40e_ethdev.c |  9 
 drivers/net/i40e/i40e_ethdev.h |  1 +
 drivers/net/i40e/i40e_flow.c   |  6 ++---
 drivers/net/i40e/i40e_hash.c   |  2 +-
 drivers/net/i40e/rte_pmd_i40e.c|  6 ++---
 drivers/net/iavf/iavf_generic_flow.c   | 14 +--
 drivers/net/ice/ice_dcf_ethdev.c   |  1 +
 drivers/net/ice/ice_ethdev.c   |  4 ++--
 drivers/net/ice/ice_generic_flow.c | 14 +--
 drivers/net/ipn3ke/ipn3ke_flow.c   |  2 +-
 drivers/net/mlx5/mlx5_flow_dv.c|  2 +-
 drivers/net/mlx5/mlx5_flow_meter.c |  2 +-
 drivers/net/softnic/rte_eth_softnic_flow.c |  3 ++-
 drivers/net/softnic/rte_eth_softnic_swq.c  |  2 +-
 drivers/raw/dpaa2_qdma/dpaa2_qdma.c|  2 +-
 lib/bbdev/rte_bbdev.h  |  2 +-
 lib/cryptodev/rte_cryptodev.h  |  2 +-
 lib/cryptodev/rte_cryptodev_pmd.h  |  2 +-
 lib/eal/common/eal_common_devargs.c|  4 ++--
 lib/eal/common/eal_common_log.c|  1 +
 lib/eal/common/eal_common_options.c|  2 +-
 lib/eal/common/eal_private.h   |  1 +
 lib/eal/freebsd/include/rte_os.h   | 10 
 lib/eal/include/rte_bus.h  |  5 ++--
 lib/eal/include/rte_class.h|  6 ++---
 lib/eal/include/rte_dev.h  |  5 ++--
 lib/eal/include/rte_devargs.h  |  3 +--
 lib/eal/include/rte_log.h  |  1 -
 lib/eal/include/rte_service.h  |  1 -
 lib/eal/include/rte_tailq.h| 15 +---
 lib/eal/linux/include/rte_os.h | 10 
 lib/eal/windows/eal_alarm.c|  1 +
 lib/eal/windows/include/rte_os.h   | 27 ++
 lib/efd/rte_efd.c  |  2 +-
 lib/ethdev/rte_ethdev_core.h   |  2 +-
 lib/hash/rte_fbk_hash.h|  1 -
 lib/hash/rte_thash.c   |  2 ++
 lib/

Re: [dpdk-dev] [PATCH v5 0/4] app/testpmd: flowgen fixes and improvements

[Ferruh Yigit]

On 8/13/2021 9:05 AM, Zhihong Wang wrote:
> This series fixes a tx retry defect and improves multi-core performance
> by using per-core variable for flow indexing.
> 
> v5: replace modulo operation to improve performance
> v4: use loop local variable to improve performance
> v3: split changes and keep original flow generation logic
> v2: fix assigning ip header cksum
> 
> Zhihong Wang (4):
>   app/testpmd: fix tx retry in flowgen
>   app/testpmd: use rte_ipv4_cksum in flowgen
>   app/testpmd: record rx_burst and fwd_dropped in flowgen
>   app/testpmd: use per-core variable in flowgen
> 

Series applied to dpdk-next-net/main, thanks.

Re: [dpdk-dev] [PATCH] ring: fix comment for __rte_ring_move_cons_head()

[Honnappa Nagarahalli]

> 
> Change "enqueue" to "dequeue" because the __rte_ring_move_cons_head()
> function is updating the consumer head for dequeue.
> 
> Fixes: 0dfc98c507b1 ("ring: separate out head index manipulation")
> Cc: bruce.richard...@intel.com
> Cc: sta...@dpdk.org
> 
> Signed-off-by: Cian Ferriter 
LGTM
Acked-by: Honnappa Nagarahalli 

> ---
>  lib/ring/rte_ring_c11_pvt.h | 2 +-
>  lib/ring/rte_ring_generic_pvt.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/ring/rte_ring_c11_pvt.h b/lib/ring/rte_ring_c11_pvt.h index
> 37e0b2afd6..f895950df4 100644
> --- a/lib/ring/rte_ring_c11_pvt.h
> +++ b/lib/ring/rte_ring_c11_pvt.h
> @@ -111,7 +111,7 @@ __rte_ring_move_prod_head(struct rte_ring *r,
> unsigned int is_sp,
>   * @param is_sc
>   *   Indicates whether multi-consumer path is needed or not
>   * @param n
> - *   The number of elements we will want to enqueue, i.e. how far should the
> + *   The number of elements we will want to dequeue, i.e. how far should the
>   *   head be moved
>   * @param behavior
>   *   RTE_RING_QUEUE_FIXED:Dequeue a fixed number of items from a ring
> diff --git a/lib/ring/rte_ring_generic_pvt.h b/lib/ring/rte_ring_generic_pvt.h
> index c95ad7e12c..5acb6e59be 100644
> --- a/lib/ring/rte_ring_generic_pvt.h
> +++ b/lib/ring/rte_ring_generic_pvt.h
> @@ -106,7 +106,7 @@ __rte_ring_move_prod_head(struct rte_ring *r,
> unsigned int is_sp,
>   * @param is_sc
>   *   Indicates whether multi-consumer path is needed or not
>   * @param n
> - *   The number of elements we will want to enqueue, i.e. how far should the
> + *   The number of elements we will want to dequeue, i.e. how far should the
>   *   head be moved
>   * @param behavior
>   *   RTE_RING_QUEUE_FIXED:Dequeue a fixed number of items from a ring
> --
> 2.32.0

Re: [dpdk-dev] [RFC v2] eal: simplify the implementation of rte_ctrl_thread_create

[Honnappa Nagarahalli]

> 
> Hi Honnappa,
> 
> On Mon, Aug 02, 2021 at 12:16:52AM -0500, Honnappa Nagarahalli wrote:
> > The current described behaviour of rte_ctrl_thread_create is rigid
> > which makes the implementation of the function complex.
> > The behavior is abstracted to allow for simplified implementation.
> 
> I agree that the behavior description should not reference the pthread
> functions, however I don't think the current description prevents from 
> rewriting
> the code as you do.
Ok

> 
> I think it would be better to explain in commit log why the proposed code is
> simpler than the current one.
> 
> > Signed-off-by: Honnappa Nagarahalli 
> > ---
> > v2: Used compiler's C++11 atomic built-ins to access the shared variable.
> >
> >  lib/eal/common/eal_common_thread.c | 65 +-
> >  lib/eal/include/rte_lcore.h|  8 ++--
> >  2 files changed, 32 insertions(+), 41 deletions(-)
> >
> > diff --git a/lib/eal/common/eal_common_thread.c
> > b/lib/eal/common/eal_common_thread.c
> > index 1a52f42a2b..e3e0bf4bff 100644
> > --- a/lib/eal/common/eal_common_thread.c
> > +++ b/lib/eal/common/eal_common_thread.c
> > @@ -169,35 +169,35 @@ __rte_thread_uninit(void)  struct
> > rte_thread_ctrl_params {
> > void *(*start_routine)(void *);
> > void *arg;
> > -   pthread_barrier_t configured;
> > -   unsigned int refcnt;
> > +   int ret;
> > +   /* Synchronization variable between the control thread
> > +* and the thread calling rte_ctrl_thread_create function.
> > +* 0 - Initialized
> > +* 1 - Control thread is running successfully
> > +* 2 - Control thread encountered an error. 'ret' has the
> > +* error code.
> > +*/
> > +   unsigned int sync;
> 
> what do you think about using an enum or defines?
Will use defines

> 
> >  };
> >
> > -static void ctrl_params_free(struct rte_thread_ctrl_params *params)
> > -{
> > -   if (__atomic_sub_fetch(¶ms->refcnt, 1, __ATOMIC_ACQ_REL) ==
> 0) {
> > -   (void)pthread_barrier_destroy(¶ms->configured);
> > -   free(params);
> > -   }
> > -}
> > -
> >  static void *ctrl_thread_init(void *arg)  {
> > struct internal_config *internal_conf =
> > eal_get_internal_configuration();
> > rte_cpuset_t *cpuset = &internal_conf->ctrl_cpuset;
> > struct rte_thread_ctrl_params *params = arg;
> > -   void *(*start_routine)(void *);
> > +   void *(*start_routine)(void *) = params->start_routine;
> > void *routine_arg = params->arg;
> >
> > __rte_thread_init(rte_lcore_id(), cpuset);
> > -
> > -   pthread_barrier_wait(¶ms->configured);
> > -   start_routine = params->start_routine;
> > -   ctrl_params_free(params);
> > -
> > -   if (start_routine == NULL)
> > +   params->ret = pthread_setaffinity_np(pthread_self(),
> > +   sizeof(*cpuset), cpuset);
> > +   if (params->ret != 0) {
> > +   __atomic_store_n(¶ms->sync, 2, __ATOMIC_RELEASE);
> > return NULL;
> > +   }
> 
> Sorry if the question is stupid (I'm still not familiar with C++11 atomic 
> built-ins),
> but do we have the assurance that params->ret is set in memory before
> params->sync is set? See below at [1].
Yes, the '__ATOMIC_RELEASE' store ensures that all prior memory operations are 
completed before 'sync' is updated.

> 
> > +
> > +   __atomic_store_n(¶ms->sync, 1, __ATOMIC_RELEASE);
> >
> > return start_routine(routine_arg);
> >  }
> > @@ -207,9 +207,6 @@ rte_ctrl_thread_create(pthread_t *thread, const char
> *name,
> > const pthread_attr_t *attr,
> > void *(*start_routine)(void *), void *arg)  {
> > -   struct internal_config *internal_conf =
> > -   eal_get_internal_configuration();
> > -   rte_cpuset_t *cpuset = &internal_conf->ctrl_cpuset;
> > struct rte_thread_ctrl_params *params;
> > int ret;
> >
> > @@ -219,15 +216,12 @@ rte_ctrl_thread_create(pthread_t *thread, const
> > char *name,
> >
> > params->start_routine = start_routine;
> > params->arg = arg;
> > -   params->refcnt = 2;
> > -
> > -   ret = pthread_barrier_init(¶ms->configured, NULL, 2);
> > -   if (ret != 0)
> > -   goto fail_no_barrier;
> > +   params->ret = 0;
> > +   params->sync = 0;
> >
> > ret = pthread_create(thread, attr, ctrl_thread_init, (void *)params);
> > if (ret != 0)
> > -   goto fail_with_barrier;
> > +   goto thread_create_failed;
> >
> > if (name != NULL) {
> > ret = rte_thread_setname(*thread, name); @@ -236,24
> +230,21 @@
> > rte_ctrl_thread_create(pthread_t *thread, const char *name,
> > "Cannot set name for ctrl thread\n");
> > }
> >
> > -   ret = pthread_setaffinity_np(*thread, sizeof(*cpuset), cpuset);
> > -   if (ret != 0)
> > -   params->start_routine = NULL;
> > +   /* Wait for the control thread to initialize successfully */
> > +   while (!__atomic_load_n(¶ms->sync, __ATOMIC_ACQUIRE))
> > +   rte_pause();
> 
> One difference between this implementati

Re: [dpdk-dev] [PATCH V3 1/2] netdev-offload-dpdk: Use has_vlan match attribute

[Eli Britstein]

On 8/24/2021 6:47 PM, Ilya Maximets wrote:

External email: Use caution opening links or attachments


On 8/24/21 5:25 PM, Eli Britstein wrote:

On 8/24/2021 6:08 PM, Finn, Emma wrote:

External email: Use caution opening links or attachments


-Original Message-
From: Eli Britstein 
Sent: Monday 16 August 2021 14:55
To: d...@openvswitch.org; Ilya Maximets 
Cc: Finn, Emma ; Stokes, Ian ; Sriharsha Basavapatna 
; Gaetan Rivet ; Majd Dibbiny 
; Eli Britstein ; Salem Sol 
Subject: [PATCH V3 1/2] netdev-offload-dpdk: Use has_vlan match attribute

DPDK 20.11 introduced an ability to specify existance/non-existance of VLAN tag 
by [1].
Use this attribute.

[1]: 09315fc83861 ("ethdev: add VLAN attributes to ethernet and VLAN items")

Signed-off-by: Eli Britstein 
Reviewed-by: Salem Sol 

Hi Eli,

I tested this but currently we don't have support in the i40e pmd for the 
has_vlan match attribute and with these patches it is breaking offload for VLAN 
packets on Intel devices.

Hi Emma,

Thanks for testing.

Is adding such support in your plans?

How do you suggest to proceed? It is needed in order to fix OVS bug.

Thanks,

Eli

The "Table 1.2 rte_flow items availability in networking drivers"
here: https://doc.dpdk.org/guides/nics/overview.html
says that both ixgbe and i40e has a full support for 'vlan' and
'eth' items.  Is it a bug?  Should it be 'partial' instead?

In general, this sounds like a big limitation of rte_flow API.
I mean the fact that there is no way to get what is implemented by
a particular driver and what is not implemented in runtime.
Someone should, probably, work on adding this kind of API to DPDK.
Otherwise, we will stuck with inability to use certain actions/matches
unless all the drivers supports them (which is also hard to check
taking documentation issues into account).  If I missed it and the
API actually exists, we should definitely start using it.

CC: dpdk-dev and rte_flow maintainers.

Thoughts?


There is such an API - rte_flow_validate().

However, in OVS, as each flow is independent and can have different 
matches and actions, we just call rte_flow_create(). The PMD (at least 
mlx5) first internally validates it (as if rte_flow_validate() is 
called), and bail out with a failure in case validate fails.


Can you suggest an effective way to utilize it in OVS?

In theory, if the API exists in rte_flow, OVS should not care if all 
PMDs support it or not.


In practice, the "has_vlan" field was introduced only in 20.11, and 
apparently Intel has not adapted i40e PMD, so it breaks their offloads. 
I suspected this so I've added Emma and Ian to review it.


I don't know i40e HW capabilities, but at least from PMD point of view, 
it can be silently ignored until a proper support is added.




Best regards, Ilya Maximets.

Re: [dpdk-dev] [RFC v2] eal: simplify the implementation of rte_ctrl_thread_create

[Stephen Hemminger]

On Tue, 24 Aug 2021 20:03:03 +
Honnappa Nagarahalli  wrote:

> > One difference between this implementation and the previous one is this busy
> > loop. rte_pause() relaxes the cpu, but will not make the calling thread to 
> > sleep
> > and wait for the sync event. So here we can spin a quite long time until the
> > other thread is scheduled by the OS.  
> Yes, this is a difference. We could add a microsleep to allow for the OS to 
> un-schedule the current thread.

Why not use sched_yield() here?

Re: [dpdk-dev] [RFC v2] eal: simplify the implementation of rte_ctrl_thread_create

[Honnappa Nagarahalli]

> 
> On Tue, 24 Aug 2021 20:03:03 +
> Honnappa Nagarahalli  wrote:
> 
> > > One difference between this implementation and the previous one is
> > > this busy loop. rte_pause() relaxes the cpu, but will not make the
> > > calling thread to sleep and wait for the sync event. So here we can
> > > spin a quite long time until the other thread is scheduled by the OS.
> > Yes, this is a difference. We could add a microsleep to allow for the OS to 
> > un-
> schedule the current thread.
> 
> Why not use sched_yield() here?
Makes sense

[dpdk-dev] [PATCH v17] app/testpmd: support multi-process

[Min Hu (Connor)]

This patch adds multi-process support for testpmd.
For example the following commands run two testpmd
processes:

 * the primary process:

./dpdk-testpmd --proc-type=auto -l 0-1 -- -i \
   --rxq=4 --txq=4 --num-procs=2 --proc-id=0

 * the secondary process:

./dpdk-testpmd --proc-type=auto -l 2-3 -- -i \
   --rxq=4 --txq=4 --num-procs=2 --proc-id=1

Signed-off-by: Min Hu (Connor) 
Signed-off-by: Lijun Ou 
Signed-off-by: Andrew Rybchenko 
Acked-by: Xiaoyun Li 
Acked-by: Ajit Khaparde 
Reviewed-by: Ferruh Yigit 
Acked-by: Aman Deep Singh 
---
v17:
rebase 21.11

V16:
* revert unrelated changes.
* add some restrictions in doc. 

v15:
* Fixed release notes.
* Cleanup documentation.

v14:
* Fixed comments by Andrew Rybchenko.

v13:
* Modified the doc syntax.

v12:
* Updated doc info.

v11:
* Fixed some minor syntax.

v10:
* Hid process type checks behind new functions.
* Added comments.

v9:
* Updated release notes and rst doc.
* Deleted deprecated codes.
* move macro and variable.

v8:
* Added warning info about queue numbers and process numbers.

v7:
* Fixed compiling error for unexpected unindent.

v6:
* Add rte flow description for multiple process.

v5:
* Fixed run_app.rst for multiple process description.
* Fix compiling error.

v4:
* Fixed minimum vlaue of Rxq or Txq in doc.

v3:
* Fixed compiling error using gcc10.0.

v2:
* Added document for this patch.
---
 app/test-pmd/cmdline.c |  6 +++
 app/test-pmd/config.c  | 20 ++-
 app/test-pmd/parameters.c  |  9 
 app/test-pmd/testpmd.c | 95 +-
 app/test-pmd/testpmd.h |  9 
 doc/guides/rel_notes/release_21_11.rst |  4 ++
 doc/guides/testpmd_app_ug/run_app.rst  | 84 ++
 7 files changed, 214 insertions(+), 13 deletions(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 82253bc..395122b 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -5491,6 +5491,12 @@ cmd_set_flush_rx_parsed(void *parsed_result,
__rte_unused void *data)
 {
struct cmd_set_flush_rx *res = parsed_result;
+
+   if (num_procs > 1 && (strcmp(res->mode, "on") == 0)) {
+   printf("multi-process doesn't support to flush Rx queues.\n");
+   return;
+   }
+
no_flush_rx = (uint8_t)((strcmp(res->mode, "on") == 0) ? 0 : 1);
 }
 
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 31d8ba1..bd404db 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2998,6 +2998,8 @@ rss_fwd_config_setup(void)
queueid_t  rxq;
queueid_t  nb_q;
streamid_t  sm_id;
+   int start;
+   int end;
 
nb_q = nb_rxq;
if (nb_q > nb_txq)
@@ -3015,7 +3017,21 @@ rss_fwd_config_setup(void)
init_fwd_streams();
 
setup_fwd_config_of_each_lcore(&cur_fwd_config);
-   rxp = 0; rxq = 0;
+
+   if (proc_id > 0 && nb_q % num_procs != 0)
+   printf("Warning! queue numbers should be multiple of processes, 
or packet loss will happen.\n");
+
+   /**
+* In multi-process, All queues are allocated to different
+* processes based on num_procs and proc_id. For example:
+* if supports 4 queues(nb_q), 2 processes(num_procs),
+* the 0~1 queue for primary process.
+* the 2~3 queue for secondary process.
+*/
+   start = proc_id * nb_q / num_procs;
+   end = start + nb_q / num_procs;
+   rxp = 0;
+   rxq = start;
for (sm_id = 0; sm_id < cur_fwd_config.nb_fwd_streams; sm_id++) {
struct fwd_stream *fs;
 
@@ -3032,6 +3048,8 @@ rss_fwd_config_setup(void)
continue;
rxp = 0;
rxq++;
+   if (rxq >= end)
+   rxq = start;
}
 }
 
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 7c13210..26192f1 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -512,6 +512,9 @@ parse_link_speed(int n)
 void
 launch_args_parse(int argc, char** argv)
 {
+#define PARAM_PROC_ID "proc-id"
+#define PARAM_NUM_PROCS "num-procs"
+
int n, opt;
char **argvopt;
int opt_idx;
@@ -631,6 +634,8 @@ launch_args_parse(int argc, char** argv)
{ "rx-mq-mode", 1, 0, 0 },
{ "record-core-cycles", 0, 0, 0 },
{ "record-burst-stats", 0, 0, 0 },
+   { PARAM_NUM_PROCS,  1, 0, 0 },
+   { PARAM_PROC_ID,1, 0, 0 },
{ 0, 0, 0, 0 },
};
 
@@ -1397,6 +1402,10 @@ launch_args_parse(int argc, char** argv)
record_core_cycles = 1;
if (!strcmp(lgopts[opt_idx].name, "record-burst-stats"))
record_burst_stats = 1;
+   if (!strcmp(lgopts[opt_idx].name, PARAM_NUM_PROCS))
+

[dpdk-dev] [PATCH] net/bnxt: fix VNIC config error in port start

[Ajit Khaparde]

During port stop/start sequence the Thor FW is returning an error.
This is because we are deriving incorrect active Rx ring and using
that wrong information in the bnxt_vnic_rss_cfg HWRM command.

Fix it by using the rx_queue_state from eth_dev.

Fixes: 0105ea1296c91 ("net/bnxt: support runtime queue setup")
Cc: sta...@dpdk.org

Signed-off-by: Ajit Khaparde 
Reviewed-by: Somnath Kotur 
---
 drivers/net/bnxt/bnxt_hwrm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index eb9de45cb9..f29d574235 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -5078,6 +5078,7 @@ static int
 bnxt_vnic_rss_configure_p5(struct bnxt *bp, struct bnxt_vnic_info *vnic)
 {
struct hwrm_vnic_rss_cfg_output *resp = bp->hwrm_cmd_resp_addr;
+   uint8_t *rxq_state = bp->eth_dev->data->rx_queue_state;
struct hwrm_vnic_rss_cfg_input req = {.req_type = 0 };
struct bnxt_rx_queue **rxqs = bp->rx_queues;
uint16_t *ring_tbl = vnic->rss_table;
@@ -5111,7 +5112,7 @@ bnxt_vnic_rss_configure_p5(struct bnxt *bp, struct 
bnxt_vnic_info *vnic)
 
/* Find next active ring. */
for (cnt = 0; cnt < max_rings; cnt++) {
-   if (rxqs[k]->rx_started)
+   if (rxq_state[k] != RTE_ETH_QUEUE_STATE_STOPPED)
break;
if (++k == max_rings)
k = 0;
-- 
2.21.1 (Apple Git-122.3)

[dpdk-dev] [PATCH] examples/ipsec-secgw: use mbuf packet type in ev worker

[Nithin Dabilpuram]

Use mbuf packet type for traffic identification as
packet is parsed already by HW before and HW/PMD updates
necessary info in mbuf packet type of the found protocols.

This change is specifically for event mode.

Signed-off-by: Nithin Dabilpuram 
---
 examples/ipsec-secgw/ipsec_worker.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/examples/ipsec-secgw/ipsec_worker.c 
b/examples/ipsec-secgw/ipsec_worker.c
index 647e22d..b77afb5 100644
--- a/examples/ipsec-secgw/ipsec_worker.c
+++ b/examples/ipsec-secgw/ipsec_worker.c
@@ -16,19 +16,22 @@ static inline enum pkt_type
 process_ipsec_get_pkt_type(struct rte_mbuf *pkt, uint8_t **nlp)
 {
struct rte_ether_hdr *eth;
+   uint32_t ptype = pkt->packet_type;
 
eth = rte_pktmbuf_mtod(pkt, struct rte_ether_hdr *);
-   if (eth->ether_type == rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV4)) {
+   rte_prefetch0(eth);
+
+   if (RTE_ETH_IS_IPV4_HDR(ptype)) {
*nlp = RTE_PTR_ADD(eth, RTE_ETHER_HDR_LEN +
offsetof(struct ip, ip_p));
-   if (**nlp == IPPROTO_ESP)
+   if ((ptype & RTE_PTYPE_TUNNEL_MASK) == RTE_PTYPE_TUNNEL_ESP)
return PKT_TYPE_IPSEC_IPV4;
else
return PKT_TYPE_PLAIN_IPV4;
-   } else if (eth->ether_type == rte_cpu_to_be_16(RTE_ETHER_TYPE_IPV6)) {
+   } else if (RTE_ETH_IS_IPV6_HDR(ptype)) {
*nlp = RTE_PTR_ADD(eth, RTE_ETHER_HDR_LEN +
offsetof(struct ip6_hdr, ip6_nxt));
-   if (**nlp == IPPROTO_ESP)
+   if ((ptype & RTE_PTYPE_TUNNEL_MASK) == RTE_PTYPE_TUNNEL_ESP)
return PKT_TYPE_IPSEC_IPV6;
else
return PKT_TYPE_PLAIN_IPV6;
@@ -336,7 +339,7 @@ process_ipsec_ev_outbound(struct ipsec_ctx *ctx, struct 
route_table *rt,
}
 
/* Validate sa_idx */
-   if (sa_idx >= ctx->sa_ctx->nb_sa)
+   if (unlikely(sa_idx >= ctx->sa_ctx->nb_sa))
goto drop_pkt_and_exit;
 
/* Else the packet has to be protected */
@@ -351,7 +354,7 @@ process_ipsec_ev_outbound(struct ipsec_ctx *ctx, struct 
route_table *rt,
sess = ipsec_get_primary_session(sa);
 
/* Allow only inline protocol for now */
-   if (sess->type != RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL) {
+   if (unlikely(sess->type != RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL)) {
RTE_LOG(ERR, IPSEC, "SA type not supported\n");
goto drop_pkt_and_exit;
}
-- 
2.8.4