From: Ophir Munk:
> v1:
> Initial release
> v2:
> Following review comments.
>
> Ophir Munk (3):
> common/mlx5: move glue files under Linux directory
> common/mlx5: move netlink files under Linux directory
> common/mlx5: split common file under Linux directory
Series-Acked-by: Matan Azra
Hi, Renata Saiakhova
I think this patch is very important, It seems all kind of NIC has memory
leak problem that used for store
Tx or rx descriptor. If that is true, memory point by rxq-> rx_ring/ txq->
tx_ring will never be freed even if dev_close?
Is my understanding right or wrong?
If th
Combine https://patches.dpdk.org/patch/67855/ with v2 of this patch to fix
the overall behaviour of dpdk-setup.sh on non-alphanumeric inputs.
Instead of crashing the script will prompt the user to re-enter the input
in case of non-alphanumberic input.
Bugzilla ID: 419
Signed-off-by: Sarosh Arif
From: Tal Shnaiderman
This patchset enables compilation and build of librte_mbuf on Windows.
Depends-on: series-10276 ("build mempool on Windows")
Depends-on: series-10156 ("Windows bus/pci support")
Tal Shnaiderman (4):
eal: move OS common config code to single file
eal: set byteorder in W
From: Tal Shnaiderman
Move common struct rte_config and function
rte_eal_mbuf_user_pool_ops to eal_config.
Signed-off-by: Tal Shnaiderman
---
lib/librte_eal/common/eal_common_config.c | 11 +++
lib/librte_eal/freebsd/eal.c | 10 --
lib/librte_eal/linux/eal.c
From: Tal Shnaiderman
Export needed eal functions used by the lib.
Signed-off-by: Tal Shnaiderman
---
lib/librte_eal/common/meson.build | 1 +
lib/librte_eal/rte_eal_exports.def | 3 +++
lib/librte_eal/rte_eal_version.map | 1 +
3 files changed, 5 insertions(+)
diff --git a/lib/librte_eal/co
From: Tal Shnaiderman
Build the lib for Windows.
Signed-off-by: Tal Shnaiderman
---
lib/meson.build | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/meson.build b/lib/meson.build
index 5486628625..e1a729da8a 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -40,8 +
From: Tal Shnaiderman
Set the endianness in Windows to RTE_LITTLE_ENDIAN as support
for Windows is limited to x86 architecture for now.
Signed-off-by: Tal Shnaiderman
---
lib/librte_eal/include/generic/rte_byteorder.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/l
Added changes in order to build mempool lib on windows.
Depends-on: patch-70497 ("ring: build on Windows")
v2:
* Replace ifndef of tracepoints with symbol export from memory management
patchset.
Fady Bader (4):
eal: disable function versioning on Windows
mempool: use generic memory
Some eal functions were used by mempool lib but not exported on Windows.
The function was exported.
Signed-off-by: Fady Bader
---
lib/librte_eal/rte_eal_exports.def | 6 ++
lib/librte_eal/rte_eal_version.map | 3 +++
2 files changed, 9 insertions(+)
diff --git a/lib/librte_eal/rte_eal_expor
mempool used Unix memory management calls, which are not supported
on Windows.
Used generic memory management instead.
Signed-off-by: Fady Bader
---
lib/librte_mempool/rte_mempool.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/lib/librte_mempool/rte
Added mempool to supported libraries for Windows compilation.
Signed-off-by: Fady Bader
---
lib/meson.build | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/meson.build b/lib/meson.build
index 30ed9e05e..c53732383 100644
--- a/lib/meson.build
+++ b/lib/meson.build
@@ -39
Function versioning is not needed on Windows, also the function versioning
implementation is not supported by Windows.
Function versioning was disabled on Windows.
Signed-off-by: Fady Bader
---
lib/librte_eal/include/rte_function_versioning.h | 4
1 file changed, 4 insertions(+)
diff --git
Hi DPDK devs,
I'm hitting a build failure with dpdk 20.02.1 with rte_ethdev.h that's
happening seemingly at random:
make install T=arm64-armv8a-linuxapp-gcc -j
In file included from
/tmp/openvpp-testing/dpdk/lib/librte_ethdev/rte_class_eth.c:13:0:
/tmp/openvpp-testing/dpdk/lib/librte_ethdev/rte_
On 30-May-20 11:02 AM, Harman Kalra wrote:
On Fri, May 29, 2020 at 03:19:45PM +0100, Burakov, Anatoly wrote:
External Email
--
On 29-May-20 2:19 PM, Harman Kalra wrote:
if (ret < 0)
rte_exit(EXIT_FAILU
From: Selwin Sebastian
Add ethdev APIs to support PTP timestamping
Signed-off-by: Selwin Sebastian
---
drivers/net/axgbe/axgbe_common.h | 8 +
drivers/net/axgbe/axgbe_ethdev.c | 327 ++-
drivers/net/axgbe/axgbe_ethdev.h | 14 ++
drivers/net/axgbe/axgbe_rxtx.c |
From: Selwin Sebastian
Add support for rx, tx queue utility APIs
Add support for 'fw_revision_get' API
Signed-off-by: Selwin Sebastian
---
drivers/net/axgbe/axgbe_ethdev.c | 7 +++
drivers/net/axgbe/axgbe_rxtx.c | 89
drivers/net/axgbe/axgbe_rxtx.h | 4 ++
On Mon, Jun 1, 2020 at 6:15 PM Juraj Linkeš wrote:
>
> Hi DPDK devs,
>
> I'm hitting a build failure with dpdk 20.02.1 with rte_ethdev.h that's
> happening seemingly at random:
> make install T=arm64-armv8a-linuxapp-gcc -j
> In file included from
> /tmp/openvpp-testing/dpdk/lib/librte_ethdev/rte
From: gnandiba
This patch adds support for set_mtu API which can be used to change
the Maximum Transmission unit (MTU) from application.
Signed-off-by: gnandiba
---
drivers/net/axgbe/axgbe_ethdev.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --g
Memzones are created in testpmd in order to test external data
buffers functionality. Each memzone is 2Mb in size and divided among
the pool of external memory buffers.
Memzone may not always be fully utilized because mbufs size can vary
and some space can be left unused at the tail of a memzone.
In case of RTA_SEC_ERA = 8, where the length of shared desc
is large for some of PDCP cases, the descriptor buffer cannot
hold 2 extra words when HFN override is enabled. As a result,
the descriptor fails.
This patch converts one of the keys from immediate key to
reference key hence reducing the l
As most of the real woeld use cases need HFN value to
be updated on per packet basis, changing the default
testing with HFN override enabled for all PDCP cases.
Signed-off-by: Akhil Goyal
---
app/test-crypto-perf/cperf_ops.c | 10 +++---
app/test/test_cryptodev.c| 13 +++--
2
On Mon, Jun 01, 2020 at 01:31:36PM +0300, Fady Bader wrote:
> Function versioning is not needed on Windows, also the function versioning
> implementation is not supported by Windows.
> Function versioning was disabled on Windows.
>
I get that windows doesn't seem to support symbol level versioning
On Mon, 1 Jun 2020 13:31:37 +0300
Fady Bader wrote:
[snip]
> /* populate the mempool with an anonymous mapping */
> @@ -740,20 +739,20 @@ rte_mempool_populate_anon(struct rte_mempool *mp)
> }
>
> /* get chunk of virtually continuous memory */
> - addr = mmap(NULL, size, PROT_R
On 6/1/2020 12:59 PM, Dmitry Kozlyuk wrote:
On Mon, 1 Jun 2020 13:31:37 +0300
Fady Bader wrote:
[snip]
/* populate the mempool with an anonymous mapping */
@@ -740,20 +739,20 @@ rte_mempool_populate_anon(struct rte_mempool *mp)
}
/* get chunk of virtually continuous memory */
28/05/2020 13:26, Burakov, Anatoly:
> On 25-May-20 1:37 AM, Dmitry Kozlyuk wrote:
> > +/**
> > + * Memory protection flags.
> > + */
> > +enum rte_mem_prot {
> > + RTE_PROT_READ = 1 << 0, /**< Read access. */
> > + RTE_PROT_WRITE = 1 << 1, /**< Write access. */
> > + RTE_PROT_EXECUTE = 1 <
01/06/2020 21:59, Dmitry Kozlyuk:
> 1. What do you think about changing rte_ to rte_eal_ prefix for memory
> management wrappers in MM series as Andrew Rybchenko suggested for v1? Since
> the functions are DPDK-internal, this sounds reasonable to me.
For lib-internal function, the prefix should no
29/05/2020 05:05, Song, Keesang:
> Hi Thomas & David,
>
> We haven't got the final status on this patch, and I don't see this change
> even from the latest LTS 20.04 repo.
> So I'd like to confirm whether this patch has been safely submitted to the
> main upstream.
> Can you check the status of
>> Do we know if we have future plans of supporting dlls on windows in the
>> future?
- Hi Neil, yes this is of interest to us (Windows).
- Specifically to aid in non-disruptive granular servicing/updating.
- Our primary scenario Userspace VMSwitch is biased towards share
Casting thread ID to handle is not accurate way to get thread handle.
Need to use OpenThread function to get thread handle from thread ID.
pthread_setaffinity_np and pthread_getaffinity_np functions
for Windows are affected because of it.
Signed-off-by: Tasnim Bashar
---
v3: WA to remove warning
Maximum burst size of Vectorized Rx burst routine is set to
MLX5_VPMD_RX_MAX_BURST(64). This limits the performance of any
application that would like to gather more than 64 packets from
the single Rx burst for batch processing (i.e. VPP).
The situation gets worse with a mix of zipped and unzipped
Can these patches be considered again for 20.08?
I thought that I addressed all of the issues or at least provided
reasonable responses to all of the concerns.
thanks
dan
On Mon, May 4, 2020 at 11:19 AM Dan Gora wrote:
>
> On Mon, May 4, 2020 at 11:13 AM Dan Gora wrote:
> >
> > On Mon, May 4,
From: Alexander Kozyrev
> Maximum burst size of Vectorized Rx burst routine is set to
> MLX5_VPMD_RX_MAX_BURST(64). This limits the performance of any
> application that would like to gather more than 64 packets from the single Rx
> burst for batch processing (i.e. VPP).
>
> The situation gets
Hi
From: Thomas Monjalon
> 10/08/2019 23:31, Thomas Monjalon:
> > 06/08/2019 20:17, Andrew Rybchenko:
> > > On 8/6/19 5:56 PM, Matan Azrad wrote:
> > > > The API breakage is because the ``tso_segsz`` field was documented
> > > > for LRO.
> > > >
> > > > The ``tso_segsz`` field in mbuf indicates th
34 matches
Mail list logo
