Hi Raj,
Inline.
> On Jun 5, 2020, at 4:14 PM, Raj Kumar wrote:
>
> Hi Florin,
> VPP from the "stable/2005" branch is working fine. Thanks! for your help.
FC: Great!
>
> I have one question; for the UDP tx if the destination address is not in the
> same subnet then it works after adding a
Hi Florin,
VPP from the "stable/2005" branch is working fine. Thanks! for your help.
I have one question; for the UDP tx if the destination address is not in
the same subnet then it works after adding a route for the next hop.
In my case , VPP interface ip is 2001:5b0::701:b883:31f:29e:68f0 an
Dear Chris,
Whew, that just made my weekend a lot happier.
I'll look into why the relevant patch didn't make it back into 19.08 - it will
now! - unfortunately "stuff happens..."
Thanks for confirming... Dave
-Original Message-
From: Christian Hopps
Sent: Friday, June 5, 2020 5:09 PM
Never mind. I have not caught up to newer messages in the thread when I
replied. -John
From: vpp-dev@lists.fd.io On Behalf Of John Lo (loj) via
lists.fd.io
Sent: Friday, June 05, 2020 4:40 PM
To: dmar...@me.com; m...@ciena.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] #vpp #vnet apparent
Bingo.
In fact in 19.08 the value is left as 0 which defaults to 15. I took it from 20
down to 15, starting successfully until I reached 15 which then hit the problem
(both with the arp path and the other).
Thanks for the help finding this!
Chris.
> On Jun 5, 2020, at 4:52 PM, Dave Barach via
Hmmm. That begins to smell like an undetected stack overflow. To test that
theory: s/18/20/ below:
/* *INDENT-OFF* */
VLIB_REGISTER_NODE (startup_config_node,static) = {
.function = startup_config_process,
.type = VLIB_NODE_TYPE_PROCESS,
.name = "startup-config-process",
.process
May be it is this one? https://gerrit.fd.io/r/c/vpp/+/26961 -John
From: vpp-dev@lists.fd.io On Behalf Of Damjan Marion via
lists.fd.io
Sent: Friday, June 05, 2020 11:51 AM
To: m...@ciena.com
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] #vpp #vnet apparent buffer prefetch issue - seeing "l3
> On Jun 5, 2020, at 2:10 PM, Dave Barach via lists.fd.io
> wrote:
>
> Step 1 is to make the silly-looking sibling recursion in
> vlib_node_add_next_with_slot(...) disappear. I’m on it...
>
> Just to ask, can you repro w/ master/latest?
I will try and do this.
In the meantime I moved the ar
Dear Chris,
Does this happen w/ master/latest? Can you share the startup config so I can
try to repro the problem?
Thanks... Dave
From: vpp-dev@lists.fd.io On Behalf Of Christian Hopps
Sent: Friday, June 5, 2020 1:29 PM
To: vpp-dev
Cc: Christian Hopps
Subject: [vpp-dev] Interesting backtrace
Yup - I fixed it up in a change 27455, so whenever the verify job passes, will
merge into stable/1908. Thanks a lot for nailing it down!
--a
> On 5 Jun 2020, at 20:08, Bly, Mike wrote:
>
>
> Yeah, it did not cherry pick clean for me either as it needs a line # change.
>
> -Mike
>
> From: And
Step 1 is to make the silly-looking sibling recursion in
vlib_node_add_next_with_slot(...) disappear. I’m on it...
Just to ask, can you repro w/ master/latest?
Thanks... Dave
From: vpp-dev@lists.fd.io On Behalf Of Christian Hopps
Sent: Friday, June 5, 2020 1:29 PM
To: vpp-dev
Cc: Christian Ho
Yeah, it did not cherry pick clean for me either as it needs a line # change.
-Mike
From: Andrew 👽 Yourtchenko
Sent: Friday, June 05, 2020 10:58 AM
To: ayour...@gmail.com
Cc: Bly, Mike ; vpp-dev@lists.fd.io
Subject: [**EXTERNAL**] Re: [vpp-dev] #vpp #vnet apparent buffer prefetch issue
- seeing
Ah sorry, didn’t see your reply. I’ll take a look. It doesn’t appear to
cherry-pick cleanly to stable/1908, so it probably was among those that 500 :(
--a
> On 5 Jun 2020, at 19:54, Andrew Yourtchenko via lists.fd.io
> wrote:
>
> Hi Mike,
>
> Any chances you might do “git bisect” on this ?
Hi Mike,
Any chances you might do “git bisect” on this ? Should take about 8-9
iterations I suppose...
You could use v20.01-rc0 label as the “git bisect bad” start and the v20.09-rc0
as the “git bisect good” start.
I am currently working on integrating a bunch of “fix” commits that happened
b
I'm wondering if maybe this SIGSEGV/backtrace might be related to the other
recently reported problem with the FIB and barrier code? The workers are at the
barrier when the SIGSEGV happens, but maybe they aren't when they need to be
earlier on?
In this case I've compiled w/o CLIB_DEBUG set, but
Damjan,
Yes, after posting yesterday, I worked through a git bisect sequence and found
the following single commit is was fixed v20.05. I cherry picked this back to
v19.08.2 and confirmed it fixes that release as well.
Please cherry-pick the following accordingly to 2019 LTS. Feel free to use t
Have you tried to use "git bisect" to find which patch fixes this issue?
—
Damjan
> On 4 Jun 2020, at 22:15, Bly, Mike via lists.fd.io
> wrote:
>
> Hello,
>
> We are observing a small percentage of frames being discarded in simple
> 2-port L2 xconnect setup when a constant, same frame, sin
Hello,
What's the best way to punt L2 packets to the control plane?
If I'm correct, now we have these ways:
- VPP communication library (it works only for TCP and UDP packets)
- a punt through Unix socket (it's only one-way punt)
- also, we can redirect IP packets (but it's not flexible and not wo
Dear All,
Due to ongoing network issues in LFN hosted Data Centres CSIT project is
stopping all automated benchmarking tests until further notice.
All daily and weekly trending, as well as CSIT-2005 report test jobs are
stopped.
LFN IT and Vexxhost teams are engaged. For latest see these two ti
19 matches
Mail list logo
