> -Original Message-
> From: Ajit Khaparde
> Sent: Thursday, January 14, 2021 10:09 PM
> To: Shiri Kuzin
> Cc: dpdk-dev ; Slava Ovsiienko ;
> NBU-Contact-Adrien Mazarguil ; Raslan
> Darawsheh
> Subject: Re: [dpdk-dev] [RFC v3 2/8] app/testpmd: add GENEVE option item
> support
>
> On W
> -Original Message-
> From: Ferruh Yigit
> Sent: Friday, January 15, 2021 3:34 AM
> To: Shiri Kuzin ; dev@dpdk.org
> Cc: Slava Ovsiienko ; NBU-Contact-Adrien
> Mazarguil ; Ori Kam ;
> NBU-Contact-Thomas Monjalon ; Raslan
> Darawsheh ; andrew.rybche...@oktetlabs.ru
> Subject: Re: [PATCH
> -Original Message-
> From: Ori Kam
> Sent: Friday, January 15, 2021 20:04
> To: Alexander Kozyrev ; dev@dpdk.org
> Cc: Slava Ovsiienko ; NBU-Contact-Thomas
> Monjalon ; ferruh.yi...@intel.com;
> andrew.rybche...@oktetlabs.ru; jerinjac...@gmail.com
> Subject: RE: [PATCH v5 1/2] ethdev: in
Currently, for a flow containing a count action, if flow is split to
sub-flows, a new counter will be created for each sub-flow.
However only the counter created for the last sub-flow will be queried
on flow query and cleared on flow removal.
This behavior is wrong, causing a leak of resources.
Ne
Currently, for a flow containing an age action, if flow is split to
sub-flows, a new age action will be created for each sub-flow.
However only the action created for the last sub-flow will be queried
on flow query and cleared on flow removal.
This behavior is wrong, causing a leak of resources.
N
From: Dekel Peled
> Currently, for a flow containing an age action, if flow is split to
> sub-flows, a new
> age action will be created for each sub-flow.
> However only the action created for the last sub-flow will be queried on flow
> query and cleared on flow removal.
>
> This behavior is
From: Dekel Peled
> Currently, for a flow containing a count action, if flow is split to
> sub-flows, a
> new counter will be created for each sub-flow.
> However only the counter created for the last sub-flow will be queried on flow
> query and cleared on flow removal.
>
> This behavior is w
The Geneve tunneling protocol is designed to allow the user to specify
some data context on the packet.
The GENEVE TLV (Type-Length-Variable) Option is the mean intended to
present the user data.
In order to support GENEVE TLV Option the new rte_flow item
"rte_flow_item_geneve_opt" is introduce
The Geneve tunneling protocol is designed to allow the
user to specify some data context on the packet.
The GENEVE TLV (Type-Length-Variable) Option
is the mean intended to present the user data.
In order to support GENEVE TLV Option the new rte_flow
item "rte_flow_item_geneve_opt" is added.
The n
From: Viacheslav Ovsiienko
The patch adds the GENEVE rte flow option length support to
command line interpreter. The flow command with GENEVE
option items looks like:
flow create 0 ingress pattern eth / ipv4 / udp / geneve vni
is 100 optlen is 2 / end actions drop / end
The option lengt
From: Viacheslav Ovsiienko
The patch adds the GENEVE option rte flow item support to
command line interpreter. The flow command with GENEVE
option items looks like:
flow create 0 ingress pattern eth / ipv4 / udp / geneve vni is 100 /
geneve-opt class is 99 length is 1 type is 0 data is
This is preparation step to support match on GENEVE TLV option.
In this Patch we add the HCA attributes that will allow
supporting GENEVE TLV option matching.
Signed-off-by: Shiri Kuzin
Acked-by: Viacheslav Ovsiienko
---
drivers/common/mlx5/mlx5_devx_cmds.c | 7 +++
drivers/common/mlx5/ml
TLV object is a special firmware maintained entity used
to support match on GENEVE header extension option.
The TLV object is created with DevX API and accepts
the option class, type and lehgth fields.
The class type and length fields are set using MLX5_SET
and the Devx object is created using ml
Currently firmware supports the only TLV object per device
to match on the GENEVE header option.
This patch adds the simple TLV object management to the mlx5 PMD.
Signed-off-by: Shiri Kuzin
Acked-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/mlx5.c | 2 +
drivers/net/mlx5/mlx5.h
This patch adds validation routine for the GENEVE
header TLV option.
The GENEVE TLV option match must include all fields
with full masks due to NIC does not support masking
on option class, type and length.
The option data length must be non zero and provided
data pattern should be zero neither d
The GENEVE TLV option matching flows must be created
using a translation function.
This function checks whether we already created a Devx
object for the matching and either creates the objects
or updates the reference counter.
Signed-off-by: Shiri Kuzin
Acked-by: Viacheslav Ovsiienko
---
drive
GENEVE TLV option support added to mlx5 PMD.
The limitations and support were updated in
documentation.
Signed-off-by: Shiri Kuzin
Acked-by: Viacheslav Ovsiienko
---
doc/guides/nics/mlx5.rst | 26 +-
doc/guides/rel_notes/release_21_02.rst | 5 +
2 fil
https://bugs.dpdk.org/show_bug.cgi?id=619
Bug ID: 619
Summary: i40e build on windows broken
Product: DPDK
Version: unspecified
Hardware: x86
OS: Windows
Status: UNCONFIRMED
Severity: normal
Prior
> > Subject: [PATCH v3 0/3] AVX512 vPMD on i40e
> >
> > This patchset aims to support AVX512 vPMD on i40e.
> > And the changes are only target to AVX512 vector path.
> >
> > ---
> > v3:
> > - Extract get_avx_supported() to get the proper vector data path to
> choose.
> >
> > v2:
> > - Add return va
16/01/2021 10:02, Lijun Ou:
> Because Wei Hu has changed to a new job and the
> email address(xavier.hu...@huawei.com) has
> expired, we remove him from the hns3 maintainer
> list.
>
> All patches signed-off-by Wei Hu will be copied
> to Lijun Ou.
>
> Signed-off-by: Lijun Ou
Applied
15/01/2021 20:21, Tyler Retzlaff:
> would you also like a patch submitted that stops installing the header. the
> change will be breaking if any other consumers have made the same mistake as
> we did. i'm not sure what dpdk's stance is on pulling headers back out of
> public space.
That's a good q
15/01/2021 20:38, Tyler Retzlaff:
> Explicitly cast void * to type * so that eal headers may be compiled
> as C or C++.
>
> Fixes: e8428a9d89f1 ("eal/windows: add some basic functions and macros")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Tyler Retzlaff
Applied with title "eal/windows: fix C++ c
14/01/2021 17:48, Stephen Hemminger:
> Trivial fix to for spelling errors and incorrect spacing.
> No change to any built code.
>
> Signed-off-by: Stephen Hemminger
> ---
> - /* restore by bytes in reverese order */
> + /* restore by bytes in reveres order */
This comment may require one
14/01/2021 18:01, Van Haaren, Harry:
> > From: Stephen Hemminger
> > Sent: Thursday, January 14, 2021 4:46 PM
> > To: Richardson, Bruce ; Van Haaren, Harry
> > ; De Lara Guarch, Pablo
> >
> > Cc: sta...@dpdk.org; dev@dpdk.org; Stephen Hemminger
> >
> > Subject: [PATCH] test: don't break terminal
14/01/2021 17:58, Stephen Hemminger:
> The ticketlock test is fast and should be run all the time.
I think it was not added because it includes a perf test.
Cc'ing more people for comments.
On Fri, 15 Jan 2021 11:38:21 -0800
Tyler Retzlaff wrote:
> Explicitly cast void * to type * so that eal headers may be compiled
> as C or C++.
>
> Fixes: e8428a9d89f1 ("eal/windows: add some basic functions and macros")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Tyler Retzlaff
> ---
> lib/librt
On Sun, 17 Jan 2021 18:57:56 +0100
Thomas Monjalon wrote:
> 14/01/2021 17:58, Stephen Hemminger:
> > The ticketlock test is fast and should be run all the time.
>
> I think it was not added because it includes a perf test.
> Cc'ing more people for comments.
>
>
Other lock code (rwlock is ve
On Sun, 17 Jan 2021 10:10:39 -0800, Stephen Hemminger wrote:
> > - *buffer = malloc(size);
> > + *buffer = (char *)malloc(size);
> > if (*buffer == NULL)
> > return -1;
> >
>
> Why is the compiler enforcing C++ rules on code that is inside "extern C {"?
Code inside extern
21/12/2020 22:32, Long Li:
> From: Long Li
>
> In some cases, a device or infrastructure may want to enable hotplug
> but application may also try and start hotplug as well. Therefore
> change the monitor_started from a boolean into a reference count.
>
> Signed-off-by: Long Li
Series applied,
05/01/2021 09:57, Nithin Dabilpuram:
> Currently bitmap line not empty check API assumes cache line
> of 64B and only checks 8 slabs. Since in 128B cacheline, we
> have 16 slabs per cacheline, rte_bitmap_clear() will mark
> complete line as empty as soon as 8 slabs are empty thereby
> breaking bitm
08/01/2021 18:05, Bruce Richardson:
> On Fri, Jan 08, 2021 at 10:22:16PM +0530, Kumar Amber wrote:
> > Add support for secondary processes in ioat devices. The update
> > allocates a memzone for a primary process or returns it in a
> > secondary process.
> >
> > Signed-off-by: Kumar Amber
> >
>
11/12/2020 00:15, dheemanth:
> In order to improve performance, the KNI is made to
> support multiple fifos, So that multiple threads pinned
> to multiple cores can process packets in parallel.
>
> Signed-off-by: dheemanth
Is there a patch 1/2?
Cc Ferruh, KNI maintainer.
05/01/2021 03:35, Narcisa Ana Maria Vasile:
> From: Narcisa Vasile
>
> The librte_cfgfile lib is functional on Windows.
> Enable compilation of this lib for Windows.
>
> Signed-off-by: Narcisa Vasile
It was an easy one :)
Applied, thanks.
12/01/2021 02:30, Tyler Retzlaff:
> From: Tyler Retzlaff
>
> declare reduced set of exports for rte_metrics on windows and include
> it in the set of libraries to build and install.
>
> rte_metrics_tel* exports depend on conditionally available component.
> this change minimally allows enabling
An application may submit all-zeros masks for a given field
to be used in two given specifications and, in the meantime,
use different unmasked values. Later on, when compared, the
two specifications will prove unequal, and, if the rules in
question are outer, the client driver will have to allocat
16/01/2021 05:50, Alexander Kozyrev:
> Implement the generic modify flow API to allow manipulations on
> an arbitrary header field (as well as mark, metadata or tag) using
> data from another field or a user-specified value.
> This generic modify mechanism removes the necessity to implement
> a sep
At 2021-01-15 18:24:47, "Thomas Monjalon" wrote:
>15/01/2021 04:51, yang_y_yi:
>>
>> At 2020-11-19 14:49:23, "Hu, Jiayu" wrote:
>> >Acked-by: Jiayu Hu
>>
>> Hi, Thomas
>>
>> This patch has been acked very long, but it isn't merged into master, what's
>> wrong?
>
>Sorry for the miss.
>
>Appli
Acked-by: Lijun Ou
在 2021/1/14 17:46, Steve Yang 写道:
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition,
but the Ether overhead is larger than 18 when it supports dual VLAN tags.
That will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will
Hi,
-Original Message-
From: Xu, Rosen
Sent: Tuesday, January 12, 2021 18:46
To: Huang, Wei ; dev@dpdk.org; Zhang, Qi Z
Cc: sta...@dpdk.org; Zhang, Tianfei
Subject: RE: [PATCH v9 1/4] raw/ifpga: add fpga rsu function
Hi,
> -Original Message-
> From: Huang, Wei
> Sent: Tuesd
> -Original Message-
> From: Ferruh Yigit
> Sent: Friday, January 15, 2021 8:23 PM
> To: Guo, Jia ; Zhang, Qi Z ;
> tho...@monjalon.net; andrew.rybche...@oktetlabs.ru; Iremonger,
> Bernard ; Lu, Wenzhuo
> ; Xing, Beilei
> Cc: Wu, Jingjing ; Yang, Qiming
> ; Wang, Haiyue ;
> dev@dpdk.org;
Hi,
-Original Message-
From: Xu, Rosen
Sent: Tuesday, January 12, 2021 19:00
To: Huang, Wei ; dev@dpdk.org; Zhang, Qi Z
Cc: sta...@dpdk.org; Zhang, Tianfei
Subject: RE: [PATCH v9 3/4] raw/ifpga: add opae API for Cyborg
Hi,
> -Original Message-
> From: Huang, Wei
> Sent: Tue
From: Kalesh AP
Driver is not logging the complete FW version along with HSI version.
Fix it to indicate complete FW version string.
Fixes: 9a891c1764ea ("net/bnxt: update HWRM to version 1.9.2")
Cc: sta...@dpdk.org
Signed-off-by: Kalesh AP
Reviewed-by: Somnath Kotur
Reviewed-by: Ajit Kumar K
Hi Thomas:
Thanks for review, comment in line
> -Original Message-
> From: Thomas Monjalon
> Sent: Friday, January 15, 2021 11:52 PM
> To: Zhang, Qi Z
> Cc: dev@dpdk.org; Yigit, Ferruh ; or...@nvidia.com;
> getel...@nvidia.com; andrew.rybche...@oktetlabs.ru;
> ajit.khapa...@broad
> -Original Message-
> From: Wang, Haiyue
> Sent: Friday, January 15, 2021 2:57 PM
> To: dev@dpdk.org
> Cc: Yang, Qiming ; Zhang, Qi Z
> ; Fu, Qi ; Wang, Haiyue
> ; Wu, Jingjing ; Xing, Beilei
>
> Subject: [PATCH v1] net/iavf: adjust the CRC statistics calculation
>
> The AVF can supp
From: Alvin Zhang
For some types of NIC, jumbo frame is not supported in IOV mode,
so if a VF requests to configure the frame size to not bigger
than RTE_ETHER_MAX_LEN, the kernel driver returns 0, but the DPDK
ixgbe PMD returens -1, this will cause the VF to fail to start
when the PF driven by D
Huang, Wei would like to recall the message, "[PATCH v9 1/4] raw/ifpga: add
fpga rsu function".
Hi,
-Original Message-
From: Xu, Rosen
Sent: Tuesday, January 12, 2021 18:46
To: Huang, Wei ; dev@dpdk.org; Zhang, Qi Z
Cc: sta...@dpdk.org; Zhang, Tianfei
Subject: RE: [PATCH v9 1/4] raw/ifpga: add fpga rsu function
Hi,
> -Original Message-
> From: Huang, Wei
> Sent: Tuesd
On 1/14/2021 7:14 PM, David Marchand wrote:
On Thu, Jan 14, 2021 at 8:24 AM Hemant Agrawal wrote:
Secondary process may not have all the tailq available for
mapping, so better to ignore the error.
e.g. if the primary process is linked with N libs
and secondary process is linked with less num
Tested-by: Xie,WeiX < weix@intel.com>
Regards,
Xie Wei
> -Original Message-
> From: Zhang,Alvin [mailto:alvinx.zh...@intel.com]
> Sent: Monday, January 18, 2021 1:04 PM
> To: Guo, Jia ; Xie, WeiX ; Wang,
> Haiyue
> Cc: dev@dpdk.org; Zhang, AlvinX ;
> sta...@dpdk.org
> Subject: [PATC
Huang, Wei would like to recall the message, "[PATCH v9 3/4] raw/ifpga: add
opae API for Cyborg".
This patch is a draft for upcoming full-fledged support
for newly added modify_field RTE Flow action.
The example shows how to use the modify_field API to set
a source or destination MAC address with an immediate
value specified by a user:
flow create 0 ingress group 0 pattern eth / end
actio
Hi,
-Original Message-
From: Xu, Rosen
Sent: Tuesday, January 12, 2021 19:00
To: Huang, Wei ; dev@dpdk.org; Zhang, Qi Z
Cc: sta...@dpdk.org; Zhang, Tianfei
Subject: RE: [PATCH v9 3/4] raw/ifpga: add opae API for Cyborg
Hi,
> -Original Message-
> From: Huang, Wei
> Sent: Tue
Enable the double VLAN support for switch QinQ filtering.
Signed-off-by: Wei Zhao
Signed-off-by: Haiyue Wang
Signed-off-by: Junfeng Guo
---
doc/guides/rel_notes/release_21_02.rst | 4 +
drivers/net/ice/ice_generic_flow.c | 15
drivers/net/ice/ice_generic_flow.h | 1 +
drivers
The jumbo frame used the 'RTE_ETHER_MAX_LEN' as boundary condition, this
fix will change the boundary condition with 'RTE_ETHER_MTU' and overhead.
When the MTU(1500) set, the frame type of rx packet will be different
if used different overhead, it will cause the consistency issue, and the
normal p
Ethdev is using default Ethernet overhead to decide if provided
'max_rx_pkt_len' value is bigger than max (non jumbo) MTU value,
and limits it to MAX if it is.
Since the application/driver used Ethernet overhead is different than
the ethdev one, check result is wrong.
If the driver is using Ether
When the max rx packet length is smaller than the sum of mtu size and
ether overhead size, it should be enlarged, otherwise the VLAN packets
will be dropped.
Removed the rx_offloads assignment for jumbo frame during command line
parsing, and set the correct jumbo frame flag if MTU size is larger t
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition,
but the Ether overhead is larger than 18 when it supports VLAN tag.
That will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will change the boundary condition with 'RTE_ETHER_MTU' and
overhead
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition,
but the Ether overhead is larger than 18 when it supports VLAN tag.
That will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will change the boundary condition with 'RTE_ETHER_MTU' and
overhead
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition,
but the Ether overhead is larger than 18 when it supports VLAN tag.
That will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will change the boundary condition with 'RTE_ETHER_MTU' and
overhead
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition,
but the Ether overhead is larger than 18 when it supports dual VLAN tags.
That will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will change the boundary condition with 'HSN3_DEFAULT_FRAME_LE
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition,
but the Ether overhead is larger than 18 when it supports dual VLAN tags.
That will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will change the boundary condition with 'RTE_ETHER_MTU' and
ov
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition,
but the Ether overhead is larger than 18 when it supports dual VLAN tags.
That will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will change the boundary condition with 'RTE_ETHER_MTU' and
ov
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition,
but the Ether overhead is larger than 18 when it supports dual VLAN tags.
That will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will change the boundary condition with 'RTE_ETHER_MTU' and
ov
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition,
but the Ether overhead is larger than 18 when it supports dual VLAN tags.
That will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will change the boundary condition with 'RTE_ETHER_MTU' and
ov
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition,
but the Ether overhead is larger than 18 when it supports dual VLAN tags.
That will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will change the boundary condition with 'RTE_ETHER_MTU' and
ov
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition,
but the Ether overhead is larger than 18 when it supports dual VLAN tags.
That will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will change the boundary condition with 'RTE_ETHER_MTU' and
ov
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition,
but the Ether overhead is larger than 18 when it supports dual VLAN tags.
That will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will change the boundary condition with 'RTE_ETHER_MTU' and
ov
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition,
but the Ether overhead is larger than 18 when it supports VLAN tag.
That will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will change the boundary condition with 'RTE_ETHER_MTU',
that perhap
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition,
but the Ether overhead is larger than 18 when it supports dual VLAN tags.
That will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will change the boundary condition with 'RTE_ETHER_MTU' and
ov
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition.
If the Ether overhead is larger than 18 when it supports VLAN tag,
that will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will normalize the boundary condition with 'RTE_ETHER_MTU'
and overhe
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition.
If the Ether overhead is larger than 18 when it supports VLAN tag,
that will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will normalize the boundary condition with 'RTE_ETHER_MTU'
and overhe
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition.
If the Ether overhead is larger than 18 when it supports VLAN tag,
that will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will normalize the boundary condition with 'RTE_ETHER_MTU'
and overhe
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition.
If the Ether overhead is larger than 18 when it supports VLAN tag,
that will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will normalize the boundary condition with 'RTE_ETHER_MTU'
and overhe
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition.
If the Ether overhead is larger than 18 when it supports VLAN tag,
that will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will normalize the boundary condition with 'RTE_ETHER_MTU'
and overhe
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition.
If the Ether overhead is larger than 18 when it supports VLAN tag,
that will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will change the boundary condition with 'RTE_ETHER_MTU',
that perhaps
The jumbo frame uses the 'RTE_ETHER_MAX_LEN' as boundary condition.
If the Ether overhead is larger than 18 when it supports VLAN tag,
that will cause the jumbo flag rx offload is wrong when MTU size is
'RTE_ETHER_MTU'.
This fix will normalize the boundary condition with 'RTE_ETHER_MTU'
and overhe
Acked-by: Xiaoyun Li
> -Original Message-
> From: Thomas Monjalon
> Sent: Thursday, January 14, 2021 04:41
> To: Li, Xiaoyun
> Cc: dev@dpdk.org; Yigit, Ferruh ; Iremonger, Bernard
> ; Xing, Beilei
> Subject: Re: [dpdk-dev] [PATCH v2] maintainers: update for testpmd
>
> 07/12/2020 21:5
77 matches
Mail list logo
