Le 25/05/2020 à 22:34, Thomas Monjalon a écrit :
25/05/2020 20:44, Morten Brørup:
From: Thomas Monjalon
25/05/2020 18:09, Burakov, Anatoly:
obviously, but i have a suspicion that we'll get more of it if we
lower
the barrier for entry (not the barrier for merge!). I think there is
a
way to
26/05/2020 04:04, wangyunjian:
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > 25/05/2020 03:46, wangyunjian:
> > > From: Yunjian Wang
> > >
> > > This patch fixes the Huawei internal coverity reported resource leak
> > > issue.
> >
> > The problem is not seen in the community Coverity?
On 5/26/20 9:06 AM, Tom Barbette wrote:
> Le 25/05/2020 à 22:34, Thomas Monjalon a écrit :
>> 25/05/2020 20:44, Morten Brørup:
>>> From: Thomas Monjalon
25/05/2020 18:09, Burakov, Anatoly:
> obviously, but i have a suspicion that we'll get more of it if we
lower
> the barrier f
On Tue, May 26, 2020 at 2:54 AM Thomas Monjalon wrote:
>
> Since dynamic fields and flags were added in 19.11,
> the idea was to use them for new features, not only PMD-specific.
>
> The rule is made more explicit in doxygen, in the mbuf guide,
> and in the contribution design guidelines.
>
> For
Le 22/05/2020 à 20:43, PATRICK KEROULAS a écrit :
mlx5 part of libibverbs includes a ts-to-ns converter which takes the
instantaneous clock info. It's unused in dpdk so far. I've tested it in the
device/port init routine and the result looks reliable. Since this approach
looks very simple, comp
DPDK-20.05 RC4 quick report
* Totally create ~400+ new test cases for DPDK20.05 new features.
* Totally run 9976 cases, execution percentage is 100%, pass rate is about
99.5%, 2 new issues are found, no critical issues.
* Checked build and compile, no new issue found.
* Checked Ba
Hi Lijun,
On 26/5/2020 4:50 AM, oulijun wrote:
Hi，
I have update the code into 20.05-rc2. However， the l3fwd-power
startup fail.
[root@centos-C3 build]# l3fwd-power -w :7d:00.1 -c 0xc00 -n 4
-- -P -p 0x01 --config '(0,0,27)' --parse-ptype
--snip--
POWER: Attempting to initi
DPDK provides generic rte_atomic APIs to do several atomic operations.
These APIs are using the deprecated __sync built-ins and enforce full
memory barriers on aarch64. However, full barriers are not necessary
in many use cases. In order to address such use cases, C language offers
C11 atomic APIs.
Add the maintainership of c11 atomics code.
Signed-off-by: Phil Yang
Reviewed-by: Honnappa Nagarahalli
---
MAINTAINERS | 4
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d2b2867..3528907 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -265,6 +265,10 @@ F: lib/
In order to deprecate the rte_atomic APIs, prevent the patches from
using rte_atomic APIs in the converted modules and compilers __sync
built-ins in all modules.
The converted modules:
lib/librte_distributor
lib/librte_hash
lib/librte_kni
lib/librte_lpm
lib/librte_rcu
lib/librte_ring
lib/librte_st
Add deprecating the generic rte_atomic_xx APIs to c11 atomic built-ins
guide and examples.
Signed-off-by: Phil Yang
Signed-off-by: Honnappa Nagarahalli
---
doc/guides/prog_guide/writing_efficient_code.rst | 139 ++-
1 file changed, 138 insertions(+), 1 deletion(-)
diff --gi
Provide a wrapper for __atomic_thread_fence built-in to support
optimized code for __ATOMIC_SEQ_CST memory order for x86 platforms.
Suggested-by: Honnappa Nagarahalli
Signed-off-by: Phil Yang
Reviewed-by: Ola Liljedahl
---
lib/librte_eal/arm/include/rte_atomic_32.h | 6 ++
lib/librte_eal
在 2020/5/26 16:36, Hunt, David 写道:
Hi Lijun,
On 26/5/2020 4:50 AM, oulijun wrote:
Hi，
I have update the code into 20.05-rc2. However， the l3fwd-power
startup fail.
[root@centos-C3 build]# l3fwd-power -w :7d:00.1 -c 0xc00 -n 4
-- -P -p 0x01 --config '(0,0,27)' --parse-ptype
On 26-May-20 8:31 AM, Maxime Coquelin wrote:
On 5/26/20 9:06 AM, Tom Barbette wrote:
Le 25/05/2020 à 22:34, Thomas Monjalon a écrit :
25/05/2020 20:44, Morten Brørup:
From: Thomas Monjalon
25/05/2020 18:09, Burakov, Anatoly:
obviously, but i have a suspicion that we'll get more of it if we
On Tue, May 26, 2020 at 11:27:10AM +0530, Deepak Gowda wrote:
> Hi All,
>
> I'm fairly new to xdp, i'm trying to run the testpmd with af_xdp. I have
> checked all the prerequisites for af_xdp.
> I see testpmd exiting with the following error,
> ./testpmd -c 0x3 -n 4 --vdev net_af_xdp0,iface=tap0 -
0x is invalid for IPv4 checksum(RFC1624)
Fixes: 6006818cfb26 ("net: new checksum functions")
Reviewed-By: Morten Brørup
Acked-by: Olivier Matz
Signed-off-by: guohongzhi
---
lib/librte_net/rte_ip.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_net/rte_ip.h
On 26-May-20 4:50 AM, oulijun wrote:
Hi，
I have update the code into 20.05-rc2. However， the l3fwd-power
startup fail.
[root@centos-C3 build]# l3fwd-power -w :7d:00.1 -c 0xc00 -n 4
-- -P -p 0x01 --config '(0,0,27)' --parse-ptype
EAL: Detected 128 lcore(s)
EAL: Detected 4 NUMA no
guohongzhi,
You must use your real name in the Signed-off-by line.
The signoff must be a real name and not an alias or nickname. For further
details, please refer to:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#developer-s-certificate-of-origin-1-1
Med venlig hilsen
On 25-May-20 8:26 PM, Tom Barbette wrote:
Le 25/05/2020 à 19:50, Wiles, Keith a écrit :
On May 25, 2020, at 12:32 PM, Thomas Monjalon
wrote:
25/05/2020 18:57, Wiles, Keith:
On May 25, 2020, at 11:28 AM, Thomas Monjalon
wrote:
25/05/2020 18:09, Burakov, Anatoly:
On 25-May-20 5:04 PM, Ma
On 25-May-20 7:44 PM, Morten Brørup wrote:
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
Sent: Monday, May 25, 2020 6:29 PM
25/05/2020 18:09, Burakov, Anatoly:
On 25-May-20 5:04 PM, Maxime Coquelin wrote:
On 5/25/20 5:59 PM, Burakov, Anatoly wrote:
On 25-May-20 4:52 PM,
From: Hongzhi Guo
0x is invalid for IPv4 checksum(RFC1624)
Fixes: 6006818cfb26 ("net: new checksum functions")
Cc: sta...@dpdk.org
Reviewed-By: Morten Brørup
Acked-by: Olivier Matz
Signed-off-by: Hongzhi Guo
---
lib/librte_net/rte_ip.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On Tue, May 26, 2020 at 3:13 PM Burakov, Anatoly
wrote:
>
> On 25-May-20 7:44 PM, Morten Brørup wrote:
> >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon
> >> Sent: Monday, May 25, 2020 6:29 PM
> >>
> >> 25/05/2020 18:09, Burakov, Anatoly:
> >>> On 25-May-20 5:04 PM, Maxime
26/05/2020 12:16, Jerin Jacob:
> Burakov, Anatoly wrote:
> > On 25-May-20 7:44 PM, Morten Brørup wrote:
> > > From: Thomas Monjalon
> > >> About the barrier for entry, maybe it is not obvious because I don't
> > >> communicate a lot about it, but please be aware that I (and other
> > >> maintainers
On 26-May-20 11:33 AM, Thomas Monjalon wrote:
And therein lies the problem: Thomas (David, etc.) doesn't look at every
area of the code, he relies on us to do it. However, *he* is doing the
committing, and fixing up patches, etc. - so, i can't really say things
like, "hey, your indentation's w
On Tue, May 26, 2020 at 4:04 PM Thomas Monjalon wrote:
>
> 26/05/2020 12:16, Jerin Jacob:
> > Burakov, Anatoly wrote:
> > > On 25-May-20 7:44 PM, Morten Brørup wrote:
> > > > From: Thomas Monjalon
> > > >> About the barrier for entry, maybe it is not obvious because I don't
> > > >> communicate a
26/05/2020 12:52, Burakov, Anatoly:
> On 26-May-20 11:33 AM, Thomas Monjalon wrote:
>
> >>> And therein lies the problem: Thomas (David, etc.) doesn't look at every
> >>> area of the code, he relies on us to do it. However, *he* is doing the
> >>> committing, and fixing up patches, etc. - so, i ca
18/02/2020 06:07, Jerin Jacob:
> On Mon, Feb 17, 2020 at 9:08 PM Ferruh Yigit wrote:
> >
> > For the ABI compatibility it is better to hide internal data structures
> > from the application as much as possible. But because of some inline
> > functions 'struct eth_dev_ops' can't be hidden completel
> On May 25, 2020, at 2:26 PM, Tom Barbette wrote:
>
>
> Le 25/05/2020 à 19:50, Wiles, Keith a écrit :
>>
>>> On May 25, 2020, at 12:32 PM, Thomas Monjalon wrote:
>>>
>>> 25/05/2020 18:57, Wiles, Keith:
On May 25, 2020, at 11:28 AM, Thomas Monjalon wrote:
> 25/05/2020 18:09, Burak
> On May 26, 2020, at 4:33 AM, Burakov, Anatoly
> wrote:
>
> On 25-May-20 8:26 PM, Tom Barbette wrote:
>> Le 25/05/2020 à 19:50, Wiles, Keith a écrit :
>>>
On May 25, 2020, at 12:32 PM, Thomas Monjalon wrote:
25/05/2020 18:57, Wiles, Keith:
> On May 25, 2020, at 11:28 AM,
> -Original Message-
> From: David Marchand
> Sent: Friday, May 22, 2020 1:59 AM
> To: dev@dpdk.org
> Cc: tho...@monjalon.net; techbo...@dpdk.org; sta...@dpdk.org; Chautru,
> Nicolas ; Ananyev, Konstantin
> ; Trahe, Fiona ;
> Ashish Gupta ; Medvedkin, Vladimir
> ; Iremonger, Bernard
> ;
25/05/2020 11:11, Andrew Rybchenko:
> On 5/25/20 2:18 AM, Thomas Monjalon wrote:
> > 04/03/2020 10:57, Ferruh Yigit:
> >> For the ABI compatibility it is better to hide internal data structures
> >> from the application as much as possible. But because of some inline
> >> functions 'struct eth_dev_
On 26-May-20 1:45 PM, Thomas Monjalon wrote:
26/05/2020 12:52, Burakov, Anatoly:
On 26-May-20 11:33 AM, Thomas Monjalon wrote:
And therein lies the problem: Thomas (David, etc.) doesn't look at every
area of the code, he relies on us to do it. However, *he* is doing the
committing, and fixing
26/05/2020 15:57, Burakov, Anatoly:
> On 26-May-20 1:45 PM, Thomas Monjalon wrote:
> > 26/05/2020 12:52, Burakov, Anatoly:
> >> On 26-May-20 11:33 AM, Thomas Monjalon wrote:
> >>
> > And therein lies the problem: Thomas (David, etc.) doesn't look at every
> > area of the code, he relies on
Hi-
IBM - DPDK on Power result
*Basic PF on Mallanox: No new errors or regressions were seen.
*Performance: no degradation compared to 20.02
System tested:
- IBM Power9 Model 8335-101 CPU: 2.3 (pvr 004e 1203)
Tested NICs:
- Mellanox Technologies MT28800 Family [ConnectX-5 Ex]
- firmware vers
On Mon, May 25, 2020 at 10:20:29AM +0200, Maxime Coquelin wrote:
>
>
> On 5/25/20 10:15 AM, jer...@marvell.com wrote:
> > From: Jerin Jacob
> >
> > In order to optimize the DPDK PCI enumeration management, RTE_KDRV_NONE
> > based device driver probing will be removed in v20.08.
> > The legacy v
26/05/2020 16:44, Olivier Matz:
> On Mon, May 25, 2020 at 10:20:29AM +0200, Maxime Coquelin wrote:
> > On 5/25/20 10:15 AM, jer...@marvell.com wrote:
> > > From: Jerin Jacob
> > >
> > > In order to optimize the DPDK PCI enumeration management, RTE_KDRV_NONE
> > > based device driver probing will
13/05/2020 12:42, Gaetan Rivet:
> When modifying the rte_devargs implementation, a deprecation notice was
> done for v18.11, regarding internal rte_devargs structure and exposed
> functions.
>
> Most of the changes were part of v18.11, but the notice was not removed.
>
> Signed-off-by: Gaetan Riv
Hi, Patrick
ConnectX HW timestamp is the captured value of internal 64-bit counter running
at the frequency,
reported in the device_frequency_khz field of struct
mlx5_ifc_cmd_hca_cap_bits{}.
This structure is queried in mlx5_devx_cmd_query_hca_attr() routine.
So, with known frequency it is possi
Hi,
On Tue, May 26, 2020 at 01:09:37PM +0530, Jerin Jacob wrote:
> On Tue, May 26, 2020 at 2:54 AM Thomas Monjalon wrote:
> >
> > Since dynamic fields and flags were added in 19.11,
> > the idea was to use them for new features, not only PMD-specific.
> >
> > The rule is made more explicit in dox
On Tue, May 26, 2020 at 9:36 PM Olivier Matz wrote:
>
> Hi,
>
> On Tue, May 26, 2020 at 01:09:37PM +0530, Jerin Jacob wrote:
> > On Tue, May 26, 2020 at 2:54 AM Thomas Monjalon wrote:
> > >
> > > Since dynamic fields and flags were added in 19.11,
> > > the idea was to use them for new features,
Hello Jerin, Kiran,
On Thu, Mar 19, 2020 at 10:26 AM Thomas Monjalon wrote:
> > > > We have the following use case.
> > > > We have 2 PF's pf0, pf1 and corresponding VF's pf0_vf0 , pf1_vf0. And
> > > > we have
> > > > 3 applications running.
> > > > 1st application on pf0 and pf1
> > > > 2nd appl
On Tue, May 26, 2020 at 10:25 PM David Marchand
wrote:
>
> Hello Jerin, Kiran,
Hello David,
>
> On Thu, Mar 19, 2020 at 10:26 AM Thomas Monjalon wrote:
> > > > > We have the following use case.
> > > > > We have 2 PF's pf0, pf1 and corresponding VF's pf0_vf0 , pf1_vf0. And
> > > > > we have
> >
On Tue, May 26, 2020 at 6:58 PM Jerin Jacob wrote:
> > > > > It seems that what you are describing it the port action with
> > > > > representors, or any
> > > > > other way you wish to implement it.
> > > >
> > > > Let's say we have a VF with kernel and we want to send the traffic to
> > > > th
In function rte_sched_subport_free (lib/librte_sched/rte_sched.c,
line 865), there is code to free all allocated stuff related to
scheduler subport. First there are some checks, and in the end,
rte_bitmap_free is called.
Now, rte_bitmap_free is a dummy function, and it just checks if
provided poin
Kilheeney, Louise :
> Sent: Friday, May 22, 2020 6:23 AM
> To: dev@dpdk.org
> Cc: Kilheeney, Louise ; Chautru, Nicolas
>
> Subject: [PATCH 20.08 1/9] app/test-bbdev: support python3 only
>
> Changed script to explicitly use python3 only.
>
> Cc: Nicolas Chautru
>
> Signed-off-by: Louise Kilhe
From: Thomas Monjalon
When querying the link information, the link status is
a mandatory major information.
Other boolean values are supposed to be accurate:
- duplex mode (half/full)
- negotiation (auto/fixed)
This API update is making explicit that the link speed information
is
This commit add function which treat link status structure
and format it to text representation.
Signed-off-by: Ivan Dyukov
---
lib/librte_ethdev/rte_ethdev.c | 39 ++
lib/librte_ethdev/rte_ethdev.h | 31 +++
2 files changed, 70 insertions(
app/proc-info/main.c | 15 +--
app/test-pipeline/init.c | 11 ++-
app/test-pmd/config.c | 20
app/test-pmd/testpmd.c| 10 ++
app/test/test_pmd_perf.c
rte_ethdev has declared new NUM_UNKNOWN speed which
could be used in case when no speed information is available and
link is up. NUM_NONE should be returned, if link is down.
Signed-off-by: Ivan Dyukov
---
drivers/net/ice/ice_ethdev.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
di
Add usage of rte_eth_link_prepare_text function to example
applications
Signed-off-by: Ivan Dyukov
---
app/proc-info/main.c | 15 +--
app/test-pipeline/init.c | 11 ++-
app/test-pmd/config.c| 20
app/test-pmd/testpmd.c | 10 ++
app/test/
rte_ethdev has declared new NUM_UNKNOWN speed which
could be used in case when no speed information is available
Signed-off-by: Ivan Dyukov
---
drivers/net/ixgbe/ixgbe_ethdev.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net
Add usage of rte_eth_link_prepare_text function to example
applications
Signed-off-by: Ivan Dyukov
---
doc/guides/sample_app_ug/link_status_intr.rst | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/doc/guides/sample_app_ug/link_status_intr.rst
b/doc/guides/sample_app_ug
rte_ethdev has declared new NUM_UNKNOWN speed which
could be used in case when no speed information is available and
link is up. NUM_NONE should be returned, if link is down.
Signed-off-by: Ivan Dyukov
---
drivers/net/i40e/i40e_ethdev.c| 5 -
drivers/net/i40e/i40e_ethdev_vf.c | 10 +
A new release is available:
https://fast.dpdk.org/rel/dpdk-20.05.tar.xz
It was a quite big release cycle:
1304 commits from 189 authors
1983 files changed, 145825 insertions(+), 29147 deletions(-)
It is not planned (yet) to start a maintenance branch for 20.05.
This versio
With Doxygen 1.8.18, a warning appears when tagging
the main markdown header with {#index}.
That's why the tag has been removed from the API index in DPDK 20.05.
Unfortunately it makes the index page classified as a standard
"related page" instead of being the "main page".
The tag {#mainpage} coul
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Tuesday, May 26, 2020 3:14 PM
> To: wangyunjian
> Cc: dev@dpdk.org; sta...@dpdk.org; Lilijun (Jerry) ;
> xudingke ; cristian.dumitre...@intel.com;
> john.mcnam...@intel.com
> Subject: Re: [dpdk-stable] [dpdk-
在 2020/5/26 17:24, Burakov, Anatoly 写道:
On 26-May-20 4:50 AM, oulijun wrote:
Hi，
I have update the code into 20.05-rc2. However， the l3fwd-power
startup fail.
[root@centos-C3 build]# l3fwd-power -w :7d:00.1 -c 0xc00 -n 4
-- -P -p 0x01 --config '(0,0,27)' --parse-ptype
EAL: D
在 2020/5/26 16:36, Hunt, David 写道:
Hi Lijun,
On 26/5/2020 4:50 AM, oulijun wrote:
Hi，
I have update the code into 20.05-rc2. However， the l3fwd-power
startup fail.
[root@centos-C3 build]# l3fwd-power -w :7d:00.1 -c 0xc00 -n 4
-- -P -p 0x01 --config '(0,0,27)' --parse-ptype
yes - I noticed the rpm packaging has become very pedantic about this of late.
Ray K
On 22/05/2020 14:23, Louise Kilheeney wrote:
> Changed script to explicitly use python3 only.
>
> Cc: Neil Horman
> Cc: Ray Kinsella
>
> Signed-off-by: Louise Kilheeney
> ---
> devtools/update_version_map
Are wrappers 100% are required.
Would it be simpler (and less invasive) to have a windows_compat.h that plugged
this holes?
I am not sure on the standard approach here - so I will leave this to others.
Outside of that - do these symbols really require experimental status.
Are they really likel
60 matches
Mail list logo
