-Original Message-
> Date: Sat, 10 Nov 2018 12:55:34 -0600
> From: Honnappa Nagarahalli
> To: bruce.richard...@intel.com, pablo.de.lara.gua...@intel.com
> CC: dev@dpdk.org, jerin.ja...@caviumnetworks.com, hemant.agra...@nxp.com,
> chao...@linux.vnet.ibm.com, yipeng1.w...@intel.com,
> dha
From: Jeff Guo
> On 11/9/2018 1:24 PM, Matan Azrad wrote:
> >
> > From: Jeff Guo
> >> On 11/8/2018 5:35 PM, Matan Azrad wrote:
> >>> From: Jeff Guo
> On 11/8/2018 3:28 PM, Matan Azrad wrote:
> > From: Ananyev, Konstantin
> >>> -Original Message-
> >>> From: Guo, Jia
>
Hi, Burakov
Thanks very much for your reply.
I run the testpmd dpdk18.08 on my router with 200GB huge page configured.
And find it still takes 50s in zeroing the 200GB huge page each time the
program restarts.
As you mentioned app shall calls rte_eal_cleanup() to do the cleanup.
H
> > @@ -1211,49 +1205,25 @@ __rte_hash_lookup_with_hash(const struct
> > rte_hash *h, const void *key,
> >
> > __hash_rw_reader_lock(h);
> >
> > - do {
> > - /* Load the table change counter before the lookup
> > -* starts. Acquire semantics will make sur
The lock-free algorithm has caused significant lookup
performance regression for certain use cases. The
regression is attributed to the use of non-relaxed
memory orderings. 2 versions of the lookup functions
are created. One that uses the RW lock and the one that
is lock-free. This restores the per
The lock-free algorithm has caused significant lookup
performance regression for certain use cases. The
regression is attributed to the use of non-relaxed
memory orderings.
To address the issue, 2 versions of the lookup functions
are created. One that uses the RW lock and the one that
is lock-free
HI Anatoly,
>Do all other distros have lspci in package called pciutils? If not, i
>prefer to keep it the way it is.
Your original patch have:
+if ret != 0:
+print("'lspci' not found - please install 'lspci'")
And I suggest to consider changing it to:
>> + if ret != 0:
>>
If rule contains tunneling action (like VXLAN encapsulation)
the VTEP (Virtual Tunneling EndPoint) device is preconfigured
before appying the rule. If kernel returnsan error this
VTEP configuration should be rolled back to the origin state.
The patch adds the missing VTEP configuration restoration.
The VXLAN related rule cleanup routine queries and gathers all
existing local IP and neigh rules into buffer list. One buffer
may contain multiple rule deletetion commands and is prepared
to send into Netlink as single message. But, if error occurs
for some deletion commands in the buffer, the mult
This patch is preparation for the following fix, we are going to send
Netlink message from buffer in one-by-one fashion. It is highly
desirable to check multimessage buffer consistency for debug purposes.
Signed-off-by: Viacheslav Ovsiienko
---
drivers/net/mlx5/mlx5_flow_tcf.c | 33 +
The Netlink message buffer is allocated and there is the typo,
the other pointer is checked instead of returned one. If no
memory is allocated and NULL is returned by allocation routine
the bug causes segmentation fault. The patch fixes typo,
returned pointer is validated.
Fixes: f420f03d6772 ("ne
The VXLAN related rule cleanup routine queries and gathers all
existing local IP and neigh rules into buffer list. One buffer
may contain multiple rule deletetion commands and is prepared
to send into Netlink as single message. But, if error occurs
for some deletion commands in the buffer, the mult
Meeting notes for the DPDK technical board meeting
held on 2018-10-24
Attendees:
- Bruce Richardson
- Ferruh Yigit
- Hemant Agrawal
- Jerin Jacob
- Konstantin Ananyev
- Maxime Coquelin
- Olivier Matz
- Stephen Hemminger
- Thom
-Original Message-
> Date: Fri, 9 Nov 2018 10:39:16 -0600
> From: Honnappa Nagarahalli
> To: bruce.richard...@intel.com, pablo.de.lara.gua...@intel.com
> CC: dev@dpdk.org, jerin.ja...@caviumnetworks.com, hemant.agra...@nxp.com,
> chao...@linux.vnet.ibm.com, yipeng1.w...@intel.com,
> dhar
14 matches
Mail list logo
