Hi HieuNT,
I am not surprised performance is this bad.
There could be a number of causes for this ... but it's not worth debugging.
Use the method Dave suggests ...
Ray K
On 06/05/2020 14:44, Nguyễn Thế Hiếu wrote:
> Hi Dave & Joe.
> Thanks for your both answers. I'm glad to see them.
> I
Hello all,
just a friendly reminder - we are now past the API Freeze milestone,
which means we do not merge to master branch any patches containing
API changes, and limit the commits to low-risk ones and fixes.
Our next milestone is next wednesday - 13th of May, when we pull the
stable/2005
Hi Muthu,
I don't see any reason why your approach shouldn't work.
Do you have any specific problem with it?
Filip
From: Muthu Raj
Sent: Thursday, May 7, 2020 9:08 AM
To: Filip Tehlar -X (ftehlar - PANTHEON TECH SRO at Cisco)
Cc: vpp-dev@lists.fd.io
Subject:
ok, this is quite common to see. What is your question / concern?
—
Damjan
> On 7 May 2020, at 04:42, zhangt...@inspur.com wrote:
>
> Hi all；
> I am using Intel 82599 (10G) , running with VPP v20.01-release with line
> rate of 10G 128 bytes of packet size， i am observing Rx misses on the
Is there a way to keep ipsecX naming, use of ipipX for ipsec tunnels seems to
be confusing for many people...
> On 7 May 2020, at 14:15, Neale Ranns via lists.fd.io
> wrote:
>
>
> Hi Chris,
>
> They were replaced by ipip interfaces protected by SAs:
>
Hi Andrew,
They’re the first UT I’ve seen that screen scrape show output. I wasn’t sure
this was acceptable practice. But if I had a better alternative I’d have
suggested it already…
/neale
From: Andrew Yourtchenko
Date: Wednesday 6 May 2020 at 15:45
To: Nick Zavaritsky
Cc:
Hi Chris,
They were replaced by ipip interfaces protected by SAs:
https://wiki.fd.io/view/VPP/IPSec#Tunnel_Mode
the tunnel always adds encap. You can configure your SA to add additional encap
if you want.
/neale
From: on behalf of Christian Hopps
Date: Wednesday 6 May 2020 at 14:32
To:
Hi Neale,
My personal opinion (because we don’t have anything written down about the
“acceptable practices in tests” - should we ?)
I view it within two axis:
1) ownership.
The owner of the component owns the tests that own the component and is free to
do whatever it makes it easy to test
Thanks for the patch, merged...
The cpu tick counters are different on each thread, so calling vlib_time_now
(wrong_vlib_main_t *) wrecks the victim thread's timebase. Knock-on effects
include all manner of obscure / hard-to-reproduce failures.
Dave
-Original Message-
From:
> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns) wrote:
>
>
> Hi Chris,
>
> They were replaced by ipip interfaces protected by SAs:
> https://wiki.fd.io/view/VPP/IPSec#Tunnel_Mode
>
> the tunnel always adds encap. You can configure your SA to add additional
> encap if you want.
Ok, but
Hello VPP experts,
When trying the current VPP master branch using a debug build we
encountered an assertion failure in vlib_time_now() here:
always_inline f64
vlib_time_now (vlib_main_t * vm)
{
#if CLIB_DEBUG > 0
extern __thread uword __os_thread_index;
#endif
/*
* Make sure folks don't
Hello people interested in PAPI (VPP's Python API client library).
In CSIT, our tests are using PAPI to interact with VPP.
We are using socket transport (instead of shared memory transport),
as VPP is running on machines separate from machines running the tests.
We use SSH to forward the socket
Hi Chris,
On 07/05/2020 16:55, "Christian Hopps" wrote:
> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns) wrote:
>
>
> Hi Chris,
>
> They were replaced by ipip interfaces protected by SAs:
> https://wiki.fd.io/view/VPP/IPSec#Tunnel_Mode
>
> the
Ack. vmovdqa64 is an aligned move [google it...] so it's no surprise whatsoever
that it blew up. If you check the new/improved assembly code, you'll probably
see that the compiler generated a 'u' flavor [unaligned] vector move.
Thanks... Dave
-Original Message-
From:
Hello,
With the current master branch (def78344) we now get an assertion
failure on startup, here:
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:51
#1 0x7462e801 in __GI_abort () at abort.c:79
#2 0x004071f3 in os_panic ()
at
> On May 7, 2020, at 1:41 PM, Neale Ranns (nranns) wrote:
>
>
> Hi Chris,
>
> On 07/05/2020 16:55, "Christian Hopps" wrote:
>
>
>
>> On May 7, 2020, at 8:15 AM, Neale Ranns (nranns) wrote:
>>
>>
>> Hi Chris,
>>
>> They were replaced by ipip interfaces protected by SAs:
>>
Right, sorry, I've pinged the Responsible Parties offline to fix the problem.
vec_len(vlib_mains) will be 1 in an init routine. Start_threads() which builds
the final vlib_mains vector doesn't occur until just prior to main dispatch
loop entry.
vec_elt_at_index (...) is meant to catch this
17 matches
Mail list logo
