From: Vamsi Attunuru
Current l2fwd application configures adjacent ports as destination
ports for forwarding the traffic which is a kind of static mapping
that can not be altered by the command line options.
Patch adds a config option to pass the forwarding port pair mapping
as a command line pa
> -Original Message-
> From: Andrzej Ostruszka [C]
> Sent: Friday, April 3, 2020 6:22 PM
> To: Vamsi Krishna Attunuru ; dev@dpdk.org
> Cc: jerinjac...@gmail.com; bruce.richard...@intel.com;
> david.march...@redhat.com; gr...@u256.net; Jerin Jacob Kollanukkaran
> ; Pavan Nikhilesh Bhagava
Introduce new command to dump memory statistics of each socket,
summary, also show changes since last call.
Usage:
dump_socket_mem
Signed-off-by: Xueming Li
---
app/test-pmd/cmdline.c | 53 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 6 +
v0: initial version
v1: update user guide
v2: change CLI to "dump_socket_mem
change memory unit MB caculation from 1e6 to 1024*1024
Xueming Li (1):
app/testpmd: add memory dump command
app/test-pmd/cmdline.c | 53 +
doc/guides/testpmd_app_ug
> > Subject: [PATCH v3 10/12] service: identify service running on another
> > core correctly
> >
> > From: Honnappa Nagarahalli
> >
> > The logic to identify if the MT unsafe service is running on another
> > core can return -EBUSY spuriously. In such cases, running the service
> > becomes cost
On Mon, 30 Mar 2020 16:33:30 +0200
Laurent Hardy wrote:
> When a port is handled by the i40evf dpdk pmd we could observe a cpu usage
> around 70% in case of rte eth stats functions (rte_eth_stats_get and
> rte_eth_xstats_get) called periodically via an application control thread.
>
> This is due
On Sat, 4 Apr 2020 13:15:57 +0300
Vadim Podovinnikov wrote:
> Signed-off-by: Vadim Podovinnikov
> ---
> drivers/net/memif/rte_eth_memif.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/memif/rte_eth_memif.c
> b/drivers/net/memif/rte_eth_memif.c
> index 8
04/04/2020 20:30, Andrzej Ostruszka [C]:
> Thomas,
>
> I have replied to the other mail, here I just want to confirm, that I'm
> fine with the proposed "general messaging" which other libraries (IF
> Proxy including) could utilize.
>
> See also below.
>
> On 4/3/20 7:19 PM, Thomas Monjalon wrote
04/04/2020 20:07, Andrzej Ostruszka [C]:
> On 4/3/20 11:42 PM, Thomas Monjalon wrote:
> > 10/03/2020 12:10, Andrzej Ostruszka:
> [...]
> >> The purpose of this library is to help with both of these tasks (as long
> >> as they remain in domain of configuration available to the system). In
> >> othe
Thomas,
I have replied to the other mail, here I just want to confirm, that I'm
fine with the proposed "general messaging" which other libraries (IF
Proxy including) could utilize.
See also below.
On 4/3/20 7:19 PM, Thomas Monjalon wrote:
> 02/04/2020 15:48, Andrzej Ostruszka [C]:
>> On 3/26/20
First of all Thomas, thank you for taking time to look at this.
Please scroll below for my comments. It looks like we are going to
detour a bit for a general config mechanism on top of which we can
"rebase" IF Proxy and other libs/apps.
Note - since I often like to think in concrete terms I migh
> > Subject: [PATCH v3 09/12] service: avoid race condition for MT unsafe
> > service
> >
> > From: Honnappa Nagarahalli
> >
> > There has possible that a MT unsafe service might get configured to
> > run on another core while the service is running currently. This might
> > result in the MT uns
> -Original Message-
> From: dev On Behalf Of Konstantin Ananyev
> Sent: Saturday, April 4, 2020 01:42
> To: dev@dpdk.org
> Cc: honnappa.nagaraha...@arm.com; david.march...@redhat.com;
> jielong@antfin.com; Ananyev,
> Konstantin
> Subject: [dpdk-dev] [PATCH v3 3/9] ring: introduce RT
On Sat, 04 Apr 2020 02:42:15 +
bugzi...@dpdk.org wrote:
> https://bugs.dpdk.org/show_bug.cgi?id=438
>
> Bug ID: 438
>Summary: memif sock does not honor file-prefix
>Product: DPDK
>Version: 20.02
> Hardware: x86
> OS: Li
On Mon, Mar 30, 2020 at 11:56 AM Phil Yang wrote:
> > if (flags & OTX2_TIM_ENA_STATS)
> > - rte_atomic64_add(&tim_ring->arm_cnt, index);
> > + __atomic_fetch_add(&tim_ring->arm_cnt, index,
> > __ATOMIC_RELAXED);
> >
> > return index;
> > }
> > @@ -130,7 +130,8
> >
> > Should we have a command line option to configure the forwarding rules
> > in the application (2)? I think yes.
> > Should we implement an application logic to automatically create the
> > best forwarding rules (1)? It would be nice, but anyway, I think we
> > need manual config (2) as a fa
On Tue, Mar 31, 2020 at 10:37 PM Andrzej Ostruszka wrote:
>
> On 3/31/20 2:53 PM, pbhagavat...@marvell.com wrote:
> > From: Pavan Nikhilesh
> >
> > Current l2fwd-event application statically configures adjacent ports as
> > destination ports for forwarding the traffic.
> >
> > Add a config option
>Subject: [dpdk-dev] [PATCH v3 4/4] ipfrag: add unit test case
>
>Initial IP fragmentation unit test.
>
>Signed-off-by: Aaron Conole
>---
> MAINTAINERS| 1 +
> app/test/meson.build | 2 +
> app/test/test_ipfrag.c | 277
>+
> 3 files changed, 2
From: Pavan Nikhilesh
When an application invokes rte_eth_dev_configure consecutively without
setting up Rx/Tx queues, it will incorrectly return error while trying
to restore Rx/Tx queue configuration.
Fix configuration sequence by checking if any Rx/Tx queues are
previously configured before t
On Fri, Apr 3, 2020 at 1:08 AM Pavan Nikhilesh wrote:
>
> From: Pavan Nikhilesh
>
> Validate the producer type used for pipeline and order test suites.
>
> Signed-off-by: Pavan Nikhilesh
Applied to dpdk-next-eventdev/master. Thanks.
> ---
> app/test-eventdev/evt_options.h | 16 +
> #
>+# Compile regex device support
>+#
>+CONFIG_RTE_LIBRTE_REGEXDEV=y
>+CONFIG_RTE_LIBRTE_REGEXDEV_DEBUG=n
The above flag is never used in the patchset.
>+
>+#
> # Compile librte_ring
> #
> CONFIG_RTE_LIBRTE_RING=y
>@@ -,3 +1117,4 @@ CONFIG_RTE_APP_CRYPTO_PERF=y
> # Compile the eventdev a
Looks like this implementation is incomplete?
I don't see any pmd specific helper functions for @see rte_cryptodev_pmd.c,
rte_eventdev_pmd*
>This commit introduce the API that is needed by the RegEx devices in
>order to work with the RegEX lib.
>
>During the probe of a RegEx device, the device sh
> -Original Message-
> From: Mattias Rönnblom
> Sent: Monday, March 9, 2020 12:21 PM
> To: Jerin Jacob Kollanukkaran
> Cc: dev@dpdk.org; stefan.sundkv...@ericsson.com; ola.liljed...@arm.com;
> Mattias Rönnblom
> Subject: [EXT] [PATCH 0/8] DSW performance and statistics improvements
>
>
Hi,
This patchset really helps my case a lot.
We have a case which would have several hundreds of threads
get/put concurrently on single mempool(ring-based) without cache.
Even on a simplified test case in which 32 threads putting into mempool
concurrently for 1024 times respectively, it works
>This commit implements all the RegEx public API.
>
>Signed-off-by: Ori Kam
>---
> lib/librte_regexdev/rte_regexdev.c | 298
>+
> 1 file changed, 298 insertions(+)
>
>diff --git a/lib/librte_regexdev/rte_regexdev.c
>b/lib/librte_regexdev/rte_regexdev.c
>index 439
https://bugs.dpdk.org/show_bug.cgi?id=439
Bug ID: 439
Summary: memif pmd is allocating from Node 0, even after
passing Node 1 in eal args
Product: DPDK
Version: 20.02
Hardware: x86
OS: Linux
Stat
The behavior is probably going to be inconsistent. Only one of the calls
to mac_address_slaves_update() is checked for failure. The two calls
are in bond_ethdev_lsc_event_callback()
if (internals->active_slave_count < 1) {
mac_address_slaves_update(bonded_e
On Sat, Apr 4, 2020 at 1:27 PM Wang, Xiao W wrote:
> > +static void
> > +node_scan_dump(FILE *f, rte_node_t id, bool all)
> > +{
> > + struct node *node;
> > +
> > + RTE_ASSERT(f != NULL);
> > + NODE_ID_CHECK(id);
This one is using fail: jump. See below
> > + STAILQ_FOREACH(node,
On Fri, Apr 3, 2020 at 4:24 PM Wang, Xiao W wrote:
> > +
> > +static rte_edge_t
> > +edge_update(struct node *node, struct node *prev, rte_edge_t from,
> > + const char **next_nodes, rte_edge_t nb_edges)
> > +{
[..]
> > + /* Update the linked list to point new node address in prev node
Hi Ori,
Looks like the series is missing support for virtual devices i.e. vdev
@see rte_eventdev_pmd_vdev.h, rte_ethdev_vdev.h.
Hyperscan and PCRE based regexdev would need vdev support.
Thanks,
Pavan.
>This patch set adds the RegEx class, which enables RegEx pattern
>matching, both on HW/SW
On Fri, Mar 6, 2020 at 11:35 AM Venky Venkatesh
wrote:
>
> Hi Mattias,
> Have a question on this fix. I understand you wanting a certain number of
> events before making a decision to migrate (in the above fix).
> However, suppose there are fewer events over a few flows (even if not many)
> and ye
> > +
> > +static struct node_head node_list = STAILQ_HEAD_INITIALIZER(node_list);
> > +static rte_node_t node_id;
> > +
> > +#define NODE_ID_CHECK(id) ID_CHECK(id, node_id)
>
> It's better to move this MACRO into the next patch since it's first used
> there, and ID_CHECK is defined there.
Will f
On Fri, Apr 3, 2020 at 2:56 PM Wang, Xiao W wrote:
>
> Hi Jerin,
Hi Xiao. Thanks for the review.
> Found small typos on this patch. Please check comments inline.
>
> Best Regards,
> Xiao
>
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + *
On Sat, Apr 4, 2020 at 3:27 AM Thomas Monjalon wrote:
>
> 03/04/2020 23:18, Morten Brørup:
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jerin Jacob
> > > Thomas Monjalon wrote:
> > > > 02/04/2020 15:48, Andrzej Ostruszka [C]:
> > > > > On 3/26/20 6:42 PM, Andrzej Ostruszka wrote:
> >
Signed-off-by: Vadim Podovinnikov
---
drivers/net/memif/rte_eth_memif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/memif/rte_eth_memif.c
b/drivers/net/memif/rte_eth_memif.c
index 81d71c53a..653ffa9b8 100644
--- a/drivers/net/memif/rte_eth_memif.c
+++ b/driver
Signed-off-by: Vadim Podovinnikov
---
drivers/net/memif/rte_eth_memif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/memif/rte_eth_memif.c
b/drivers/net/memif/rte_eth_memif.c
index 81d71c53a..653ffa9b8 100644
--- a/drivers/net/memif/rte_eth_memif.c
+++ b/driver
Hi,
Comment inline.
Best Regards,
Xiao
> -Original Message-
> From: dev On Behalf Of jer...@marvell.com
> Sent: Wednesday, April 1, 2020 3:29 AM
> To: Jerin Jacob ; Kiran Kumar K
>
> Cc: dev@dpdk.org; tho...@monjalon.net; david.march...@redhat.com;
> m...@ashroe.eu; mattias.ronnb...@er
37 matches
Mail list logo