Thanks for the report. This seems like a bug, most likely pretty simple to fix.
As you pointed out, static RA’s should include constant lifetime values.
It will take a bit of time to fix it and release the fix as part of a 20.01
maintenance release.
Dave
From: vpp-dev@lists.fd.io On Behalf
If you have the thread index handy, that's OK. Otherwise, use vlib_get_main()
which grabs the thread index from thread local storage.
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Elias Rudberg
Sent: Sunday, April 5, 2020 4:58 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev]
placement: not found
DBGvpp#
Is there another command to bind a pg interface to a worker thread?
On Sun, Apr 5, 2020 at 8:08 AM Dave Barach via lists.fd.io<http://lists.fd.io>
mailto:cisco@lists.fd.io>> wrote:
If you have the thread index handy, that's OK. Otherwise, use vlib_ge
Vlib_main_t *vm->main_loop_count.
One trip around the main loop accounts for all per-worker local graph edges /
acyclic graph behaviors.
As to the magic number E (not to be confused with e): repeatedly handing off
packets from thread to thread seems like a bad implementation strategy. The
We scrape the 32-bit node-runtime counters back into the 64 bit node counters
when they overflow.
It should take a good long time for a 32-bit counter to overflow – O(1 seconds’
worth of node runtime) – we do this to reduce the cache footprint of the
node-runtime.
HTH... Dave
From:
Could be. In real life, objects allocated from pools have widely variable
lifetimes. It would be virtually impossible to unmap less than an entire pool.
If your application would tolerate something akin garbage collection, I suppose
you could create a fresh pool with a fresh set of indices, and
Data segment, .bss segment, stack segment addresses to name a few. Although it
doesn’t happen every day, it’s almost too easy to free an object which wasn’t
allocated.
D
From: vpp-dev@lists.fd.io On Behalf Of
xiapengli...@gmail.com
Sent: Friday, April 3, 2020 2:57 AM
To: vpp-dev@lists.fd.io
OK, no need to see the script... Classifier table out of memory... If you’re
using the “classify table” debug CLI to set up the tables, change (or add)
“memory-size xxxM” or “memory-size xxxG” to give the classifier enough memory.
Depending on how many concurrent entries you expect, set the
+1.
View any metadata subject to table add/del accidents with suspicion. There is a
safe delete paradigm: each vlib_main_t has a “lap counter”. When deleting
table entries: atomically update table entries. Record the lap counter and wait
until all worker threads have completed a lap. Then,
Running for 2.5 seconds in a single graph node is certainly a problem.
See if you can use the vppinfra “file” infrastructure for non-blocking file
I/O. Search for clib_file_add(...). You can use a VLIB_NODE_TYPE_PROCESS node,
suspend the process node after a realistic amount of runtime
vlib_node_runtime_update_stats(...)
From: Nagaraju Vemuri
Sent: Friday, March 27, 2020 12:54 PM
To: Dave Barach (dbarach)
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] clocks stored in vlib_node_runtime_t #vpp #counters
Thanks for your reply Dave.
Can you please point me to the code where we
Hmmm, yeah. Been at this for years, I can’t really remember when we settled on
e.g. n_vectors vs. n_vector_elts or some such.
In new code, it’s perfectly fair to use whatever names seem fit for purpose.
Vlib would be happy doing image processing, or any other kind of vector
processing. There’s
ve a reasonable name for it. One way could be to start with
renaming things in some of the main data structures like those in vlib/node.h
and vlib/threads.h and such places, and the changes the compiler will force as
a result of that.
Best regards,
Elias
On Tue, 2020-03-31 at 00:45 +0000, Dave Barach v
If you care about master/latest, also check out
https://docs.fd.io/csit/master/trending/
From: vpp-dev@lists.fd.io On Behalf Of Jerome Tollet via
Lists.Fd.Io
Sent: Monday, March 30, 2020 2:40 PM
To: Majumdar, Kausik ; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP
It’s an on-demand performance monitor controlled by a set of debug CLI
commands. It doesn’t anything unless enabled, and it certainly won’t hurt
anything to disable it.
Disable the plugin in /etc/vpp/startup.conf if you like.
Dave
From: vpp-dev@lists.fd.io On Behalf Of Nagaraju Vemuri
Sent:
Cheat sheet:
“show pmc events”
Start traffic
“set pmc events ”
[example: “set pmc events instructions-per-clock”]
Show results:
“show pmc [verbose]”
Clear counters:
“clear pmc”
HTH... Dave
From: Nagaraju Vemuri
Sent: Monday, March 30, 2020 4:12 PM
To: Dave Barach (dbarach)
Cc:
“show log” – plugin loader spew redirected to the log.
From: vpp-dev@lists.fd.io On Behalf Of
mythosmonkeyk...@163.com
Sent: Thursday, March 26, 2020 6:53 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] clib_waring is not printing
[cid:image001.png@01D60341.17489A80]
Why is there no log
How about: send a backtrace (preferably from a debug image), and put the script
somewhere so that we can work the problem?
From: vpp-dev@lists.fd.io On Behalf Of Luc Pelletier
Sent: Wednesday, March 25, 2020 7:53 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP Crashes When Executing Large
+1, with two additional notes.
18.01 is over two years old. It's not supported anymore. If you absolutely must
go there, "Use the Force and Read the Source..."
Since vpp 18.01 was released, I've rewritten the pcap trace cli. Ben is
probably right, but that's about all I can say at this point.
Ack. If all else fails, suggest a quick peek at the assembly code.
From: vpp-dev@lists.fd.io On Behalf Of Peng Xia
Sent: Thursday, April 23, 2020 12:15 AM
To: Peng Xia
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Regarding lookup in vppinfra/hash.c
Sorry, I was confused with the later lines.
Adding a feature arc node e.g. to the device input feature arc would allow you
to classify and (optionally) generate ipfix records [or whatever].
Depending on the size of the records involved, the ratio of classifier hits to
classifier misses, the required PPS to avoid dropping traffic, number
In [live, not core-file] gdb, try this:
(gdb) p pifi(pool, )
Which will tell you if is free (invalid) or not (valid).
Also:
(gdb) p pool_elts(pool)
To see how many elements are in the pool.
Finally:
(gdb) p vl(pool)
To what vec_len(pool) is.
HTH... Dave
From: vpp-dev@lists.fd.io On
For now, we support 19.08 (LTS), and 20.01.
20.05 will be released next month.
We do not support 19.01.
Thanks... Dave
From: vpp-dev@lists.fd.io On Behalf Of Deepak NC
Sent: Wednesday, April 29, 2020 12:44 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] wireshark log capture with "any "
Thanks for the patch. Anyway your code reads much more easily than the
original. [Jenkins is screwed up at the moment, Dave Wallace is working on it.]
We could do something like this to track down min_log2(0) calls:
#if defined (count_leading_zeros)
always_inline uword
min_log2 (uword x)
{
Dear Andreas,
Do you have a handy list of places which convert netmasks to lengths?
Regardless of what one might do with min_log2, we ought to clean up those
places in time for the 20.05 release (if possible).
Dave
From: vpp-dev@lists.fd.io On Behalf Of Andreas Schultz
Sent: Tuesday, May 12,
As an aside, please be very careful to respect the source code licenses
involved.
Fd.io vpp code carries an Apache-2 license. GPL-licensed code must not be used.
FWIW... Dave
From: vpp-dev@lists.fd.io On Behalf Of Damjan Marion via
lists.fd.io
Sent: Tuesday, May 5, 2020 8:57 AM
To: Artem
You’re running old software. In future please include the vpp version so we
know what we’re dealing with.
I fixed this issue last July, it does not exist in either 19.08 (LTS) or 20.01.
IIRC you may be able to cherrypick / backport the fix to an earlier release.
HTH... Dave
Author: Dave
I merged Ole's patch a minute ago. Again, thanks for the report...
Dave
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Elias Rudberg
Sent: Friday, May 8, 2020 5:30 AM
To: otr...@employees.org
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Assertion failure in
API messages in network byte order made sense 10 years ago when I worked with a
mixed x86_64 / ppc32 system. As Damjan points out, API interoperability between
big-endian and little-endian systems is a boutique use-case these days.
Timing is key. We won’t be able to cherry-pick API message
That patch looks OK, but it never – not even once – passed validation. I
rebased it without difficulty, but unless it passes validation it’s not going
to be merged.
It would have been a Good Thing to have pursued the matter at the time, rather
than a long time after the fact.
D.
From:
Nice catch. TBH it won’t make much difference, but the code is clearly wrong.
I’ll push a patch.
Dave
From: vpp-dev@lists.fd.io On Behalf Of
xiapengli...@gmail.com
Sent: Friday, March 20, 2020 11:32 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] regarding disable_trace in vppinfra/dlmalloc.c
See https://gerrit.fd.io/r/c/vpp/+/26061.
I can see why folks thought that the original patch was OK: Jenkins / Gerrit
hid the original test failure.
test_srv6_mobile.TestSRv6EndMGTP6D.test_srv6_mobile failed during validation,
and has been failing 100% of the time since the patch was merged.
Merged https://gerrit.fd.io/r/c/vpp/+/26059 instead...
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Dave Barach via
Lists.Fd.Io
Sent: Sunday, March 22, 2020 9:40 AM
To: vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] Build broken: revert of "srv6-m
See URL below.
The vpp packet dispatch tracer will show you everything you would want to know
about the nodes visited by individual packets:
https://fd.io/docs/vpp/master/gettingstarted/developers/vnet.html#graph-dispatcher-pcap-tracing
This is a developer tool, not a tool for post-mortem
This limitation should come as no surprise, and it’s hardly a “big” limitation.
Options include building container images which match the host distro, or using
a vpp snap image on the host which corresponds to the container images.
Given that there are two ways to deal with the situation, pick
If you want to count things in data plane nodes, use a per-node counter and the
“show error” debug CLI to inspect it.
To count every packet fed to the node dispatch function, you can bump a node
counter once per frame:
vlib_node_increment_counter (vm, myplugin_node.index,
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:
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:
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
Could we please see the faulting instruction, as well as the vector register
contents involved?
As in "x/i $pc", and the ymmX registers involved?
If the vector instruction requires alignment, "movaps" or similar, it wouldn't
be a shock to discover an unaligned address. We've already found and
+1.
I suspect that the most useful occupancy measure may be the number of buffers
in use / total number of buffers.
FWIW... Dave
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Benoit Ganne
(bganne) via lists.fd.io
Sent: Thursday, September 3, 2020 9:27 AM
To:
)
Thanks,
Nitin
From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
mailto:vpp-dev@lists.fd.io>> On Behalf Of Dave Barach via
lists.fd.io
Sent: Wednesday, September 2, 2020 6:44 PM
To: Nitin Saxena mailto:nsax...@marvell.com>>; vpp-dev
mailto:vpp-dev@lists.fd.io>>
Sub
Given the amount of soak-time / perf/scale / stress testing which the tw_timer
code has experienced, it’s reasonably likely that your application is
responsible.
Caution is required when dealing with timers other than the timer which has
expired.
If you have > 1 timer per object and you
It looks like vpp is crashing while expiring timers from the main thread
process timer wheel. That’s not been reported before.
You might want to dust off .../extras/deprecated/vlib/unix/cj.[ch], and make a
circular log of timer pool_put operations to work out what’s happening.
D.
From:
Known Coverity UI bug. Happens all the time for me.
Back up one page, and click on "show me the bugs" again. It should work.
D.
From: vpp-dev@lists.fd.io On Behalf Of Nitin Saxena
Sent: Wednesday, September 2, 2020 3:31 AM
To: vpp-dev
Subject: [vpp-dev] How to see coverity logs
Hi
s/10us/100us/ seems to work as expected. Diffs under separate cover. Let me
know what happens.
HTH... D
From: vpp-dev@lists.fd.io On Behalf Of Dave Barach via
lists.fd.io
Sent: Wednesday, September 9, 2020 8:15 AM
To: Rajith PR
Cc: vpp-dev
Subject: Re: [vpp-dev]: Crash in Timer wheel infra
“wheel slips” – aka calling tw_timer_expire_timer[_vec] later than expected
every so often – is not a catastrophic problem; so long as the delay isn’t
ridiculous. You’d need to compute mean delay and delay variance to know whether
the slips that you’re seeing are trivial, or non-trivial.
Sounds like you may not have enabled the “test-node” feature on the rx
sw_if_index. “show interface features”... Note that if the packet comes
from a bridge group, I suspect that you’ll need to enable the feature on the
bvi vs the rx interface.
This is the kind of problem which “pcap dispatch
You're welcome to dust off, test, and use the skiplist code if you like.
AFAIK, it has never been used, battle-tested, or hardened. That's why it ended
up in the "deprecated" directory...
Dave
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of G. Paul Ziemba
Sent: Sunday,
You can press the “cherrypick” button as easily as Florin... Hint...
From: vpp-dev@lists.fd.io On Behalf Of Raj Kumar
Sent: Monday, August 17, 2020 5:09 PM
To: Ayush Gautam
Cc: Florin Coras ; vpp-dev
Subject: Re: [vpp-dev] VPP 2005 is crashing on stopping the VCL applications
#vpp-hoststack
Sure. Link your plugin against the third-party library and it will work
instantly... See src/plugins/rdma/CMakeLists.txt for an example...
Dave
From: vpp-dev@lists.fd.io On Behalf Of
sachinpp...@gmail.com
Sent: Tuesday, August 18, 2020 1:25 PM
To: vpp-dev@lists.fd.io
Subject: [SUSPECTED SPAM]
Memif / libmemif.
From: vpp-dev@lists.fd.io On Behalf Of
sachinpp...@gmail.com
Sent: Friday, August 28, 2020 6:20 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] communicate with External app
Can someone please answer this query?
Regards,
Sachin P.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive
clib_mem_size() returns the object’s capacity, which will be >= number of bytes
requested...
From: vpp-dev@lists.fd.io On Behalf Of
jiangxiaom...@outlook.com
Sent: Thursday, August 27, 2020 11:26 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] clib_mem_size return wrong mem size
Hi, experts:
The memory allocator does not track how many bytes you requested.
Clib_mem_alloc(...) returns no less than the requested number of bytes. That’s
the API, contract, or promise depending on how you want to put it.
Clib_mem_realloc(...) always allocates a fresh chunk of memory and copies the
Configure proxy-arp.
From: vpp-dev@lists.fd.io On Behalf Of Satya Murthy
Sent: Wednesday, August 19, 2020 9:04 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] ARP resolution from non-connected IP
Hi,
Have a query on the ARP resolution.
We have a Router and VPP-box connected.
We are
Here's a strategy: Use "show run" to identify graph nodes which are active when
passing traffic. Nodes of interest will have names like "ethernet-input,"
"ip4-input", etc.
Obviously, the string "ethernet-input" string comes from "somewhere". In
particular:
/* *INDENT-OFF* */
Folks,
The self-nomination period closed yesterday. We had one self-nomination, from
Damjan Marion. At this point, we can proceed with a vote.
I'm sure that Damjan will do a great job, so let me start:
Damjan Marion as VPP PTL: +1
Please vote +1, 0, -1. For once, the "reply-all" button is
Thanks... Dave
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17487): https://lists.fd.io/g/vpp-dev/message/17487
Mute This Topic: https://lists.fd.io/mt/77025295/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe:
Please don't be this person:
static clib_error_t *
my_cli_command_fn (vlib_main_t * vm,
unformat_input_t * input,
vlib_cli_command_t * cmd)
{
while (unformat_check_input (input) != UNFORMAT_END_OF_INPUT)
{
if (unformat (input, "mystuff"))
The code manages to access a poisoned adjacency – 0x131313 fill pattern –
copying Neale for an opinion.
D.
From: vpp-dev@lists.fd.io On Behalf Of Rajith PR via
lists.fd.io
Sent: Tuesday, June 2, 2020 10:00 AM
To: vpp-dev
Subject: [vpp-dev] SEGMENTATION FAULT in load_balance_get()
Hello All,
Unless you fully communicate your configuration, you’ll have to debug the issue
yourself. Are you using the standard handoff mechanism, or a mechanism of your
own design?
The handoff demo plugin seems to work fine... See
../src/examples/handoffdemo/{README.md, node.c} etc.
DBGvpp# sh trace
+1 ddio makes a first-order perf difference...
From: vpp-dev@lists.fd.io On Behalf Of Damjan Marion via
lists.fd.io
Sent: Wednesday, July 22, 2020 4:04 AM
To: Christian Hopps
Cc: vpp-dev
Subject: Re: [vpp-dev] AMD Epyc and vpp.
> On 22 Jul 2020, at 02:33, Christian Hopps
>
Looks like you forgot to write up the issue, to name one problem.
Please refer to
https://fd.io/docs/vpp/master/troubleshooting/reportingissues/reportingissues.html.
From: vpp-dev@lists.fd.io On Behalf Of Chinmaya Aggarwal
Sent: Friday, August 7, 2020 7:54 AM
To: vpp-dev@lists.fd.io
Subject:
“... create fib table and add interface to it.”
You need to actually create the table:
vpp# ip table 1
vpp# set int ip table 1
From: vpp-dev@lists.fd.io On Behalf Of techi...@gmail.com
Sent: Wednesday, August 12, 2020 8:47 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Unable to create fib
Minus the typo this time:
vpp# ip table 1
vpp# set int ip table 1
From: vpp-dev@lists.fd.io On Behalf Of Dave Barach via
lists.fd.io
Sent: Wednesday, August 12, 2020 9:08 AM
To: techi...@gmail.com; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Unable to create fib table and add interfaces in vpp
For whatever reason, your application didn’t process 3x memclnt_keepalive
messages. Vpp sends one of these messages every 10 seconds.
vpp# sh api messsage table
ID Name
21 memclnt_keepalive
The code in question runs after the client sends a MEMCLNT_DELETE message.
Purpose: make sure that
Patch on the way, thanks for the report.
From: vpp-dev@lists.fd.io On Behalf Of mauricio.solisjr
via lists.fd.io
Sent: Tuesday, June 30, 2020 7:53 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] classify table, mask flow-label, version, and traffic-class
NOT working #classify #vnet
Hi
I've been
Dear Chris,
In looking at the patch, I have a question: the API version number changed
despite the fact that the API itself was unchanged.
Should we revert the API version number bump and then cherry-pick to 19.08?
Looping in Ole for an opinion...
Thanks... Dave
-Original Message-
In order for the statistics to be accurate, please be sure to do the following:
Start traffic... “clear run”... wait a while to accumulate data... “show run”
Otherwise, the statistics will probably include a huge amount of dead airtime,
data from previous runs, etc.
HTH... Dave
From:
Which vpp version are you using?
The code looks substantially different in master/latest. In particular, you
must not have this patch...:
Author: Neale Ranns 2020-05-25 05:09:36
Committer: Ole Trøan 2020-05-26 10:54:23
Parent: 080aa503b23a90ed43d7c0b2bc68e2726190a990 (vcl: do not propagate
Looping in the technical steering committee...
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Stephen Hemminger
Sent: Thursday, July 2, 2020 7:02 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Replacing master/slave nomenclature
Is the VPP project addressing the use of
Do not call vlib_worker_thread_barrier_sync() on a worker thread.
From: vpp-dev@lists.fd.io On Behalf Of ais...@gmail.com
Sent: Thursday, July 9, 2020 1:44 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vpp-20.01/src/vlib/threads.c:1408
(vlib_worker_thread_barrier_sync_int) assertion
The backtrace appears to indicate that ipv6 link-level traffic is involved.
It’s likely that the interface corresponding to sw_if_index 2 isn’t
ipv6-enabled.
Begs the question why the code wipe out – copying Neale but he is on leave at
the moment – please enable ipv6 on the interface.
It
“perf top -p `pidof vpp`” and go figure out what’s happening. Drill down on
your node dispatch function, and look for stalls.
What you’re describing sounds like a non-functional prefetch strategy or other
coding error.
Since we can’t look at the code, that’s about all we have to suggest...
)
Subject: Re: [vpp-dev] Replacing master/slave nomenclature
Hi Stephen,
I agree, I don't think we should ignore this.
Ed - I suggest we table a discussion at the next FD.io TSC?
Ray K
On 09/07/2020 17:05, Dave Barach via lists.fd.io wrote:
> Looping in the technical steering commit
This one is definitely safe, and worth including:
https://gerrit.fd.io/r/c/vpp/+/27281
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Andrew Yourtchenko
Sent: Wednesday, July 15, 2020 6:27 AM
To: Elias Rudberg
Cc: vpp-dev@lists.fd.io; dwallac...@gmail.com
Subject: Re:
+1 to what Chris wrote. For your own sake, please refer to master/latest.
Vpp 16.09 is obsolete, unsupported, and sufficiently different from the current
codebase to lead you down all sorts of blind alleys.
HTH... Dave
From: vpp-dev@lists.fd.io On Behalf Of "??
Sent: Saturday, July 11, 2020
Vpp version? Configuration? Backtraces from other threads? The timer wheel code
is not likely to be directly responsible.
Earlier this year, we addressed a number of issues in vppinfra/time.[ch] having
to do with NTP and/or manual time changes which could lead to symptoms like
this.
If you
Configure vlan subif(s), and configure L2 mode.
Attach your feature code to the L2 input feature arc(s), and enable on the
indicated sw_if_index(es):
.arc_name = "l2-input-ip4",
.arc_name = "l2-input-ip6",
.arc_name = "l2-input-nonip",
Before you mess around spinning up threads, see if
So tell us: what is the interface in question? How was it created?
Was vec_len(hi->hw_address) 6 when the interface was created? At the time of
the crash, was the hardwre address hw->hw_address intact but with an incorrect
length, or was it trash?
Haven’t seen any previous report of such
What is the magnitude of the delta that you observe? What does "show clock
verbose" say about the state of clock-rate convergence? Is a deus ex machina
(e.g. NTP) involved?
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Prashant Upadhyaya
Sent: Sunday, June 14, 2020 10:32
That's within reason given that thread time offsets are not recalculated
immediately, and that (for stability reasons) the clock-rate update algorithm
uses exponential smoothing.
Aside from accounting for the issue in your code, there probably isn't much to
be done about it...
D
HundredGigabitEthernet12/0/0 (sw_if_index=1) has the ip address 192.168.198.2.
The calculation shown in your original email is producing 192.168.198.2, which
seems right to me.
You’ve looked up the ip address of the rx interface, which may not be what you
had in mind.
The packet got nowhere
Coverage runs with gcc can run in parallel. With clang, not so much... CC=gcc
is your friend...
D.
From: vpp-dev@lists.fd.io On Behalf Of Andrew Yourtchenko
Sent: Thursday, June 18, 2020 4:25 PM
To: Balaji Venkatraman (balajiv)
Cc: Neale Ranns (nranns) ; vpp-dev
Subject: Re: [vpp-dev] VPP
"trace add [dpdk-input|memif-input] " ... run failing case ... "show
trace". Should explain what's happening.
Dave
From: vpp-dev@lists.fd.io On Behalf Of Sridhar K. N. Rao
Sent: Saturday, June 27, 2020 9:16 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Userspace CNI - VPP Memif Forwarding
If you want to pinch code from vpp_api_test, please read and understand it:
/* W: wait for results, with timeout */
#define W(ret) \
do {\
f64 timeout = vat_time_now (vam) + 1.0;
Why are you linking against vlib?
From: vpp-dev@lists.fd.io On Behalf Of Chinmaya Aggarwal
Sent: Thursday, June 25, 2020 6:48 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP C API application compilation issue on using S and W
functions
Hi,
We are testing VPP C API for our use case. We have
Unless you’re doing vector processing, vlib is not useful.
Here is the CMakeLists.txt entry for vpp_api_test. It’s not likely that you’ll
need libvatplugin.so, but you get the idea...
##
# vpp_api_test
o:vpp-dev@lists.fd.io>
mailto:vpp-dev@lists.fd.io>> On Behalf Of Dave Barach via
lists.fd.io<http://lists.fd.io>
Sent: Wednesday, June 3, 2020 7:08 AM
To: Benoit Ganne (bganne) mailto:bga...@cisco.com>>;
raj...@rtbrick.com<mailto:raj...@rtbrick.com>
Cc: vpp-dev mailt
Please test https://gerrit.fd.io/r/c/vpp/+/27407 and report results.
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Dave Barach via
lists.fd.io
Sent: Wednesday, June 3, 2020 7:08 AM
To: Benoit Ganne (bganne) ; raj...@rtbrick.com
Cc: vpp-dev ; Neale Ranns (nranns)
Subject
Use the force and read the source:
/*?
* Layer 2 flooding can be enabled and disabled on each
* interface and on each bridge-domain. Use this command to
* manage bridge-domains. It is enabled by default.
*
* @cliexpar
* Example of how to enable flooding (where 200 is the bridge-domain-id):
*
+1, can't tell which poison pattern is involved without a scorecard.
load_balance_alloc_i (...) is clearly not thread-safe due to calls to
pool_get_aligned (...) and vlib_validate_combined_counter(...).
Judicious use of pool_get_aligned_will_expand(...),
_vec_resize_will_expand(...) and a
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
lem
(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 lists.fd.io
> wrote:
>
> Hmmm. That begins to smell like an undetected stack overflow. To test that
> theory: s/18/20/ below:
>
> /* *INDE
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
tian Hopps ; vpp-dev
Subject: Re: [vpp-dev] Interesting backtrace in 1908
> 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...
>
&g
https://gerrit.fd.io/r/c/vpp/+/27458. Next time you find something like this,
feel free to fix it and push a patch.
From: vpp-dev@lists.fd.io On Behalf Of Pac Ette
Sent: Saturday, June 6, 2020 4:15 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] received signal SIGSEGV (vppinfra/time_range.h) no
Folks,
It looks to me like inlining vlib_add_trace(...) is probably a mistake in terms
of code bloat. Does anyone hate the idea of changing it to a standard function?
Thanks... Dave
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16686):
16e0 .../vnet_skx.dir/ipsec/ipsec_input.c.o
Retain the original code as vlib_add_trace_inline, instantiate once as
vlib_add_trace.
Type: refactor
Signed-off-by: Dave Barach
Change-Id: Iaf431dbf00c4aad03663d86f9dd1322e84d03962
From: vpp-dev@lists.fd.io On Behalf Of Dave Barach via
Seems like a design which will cause no end of trouble. Coded this way, key
swaps will put serious pressure on the buffer allocator. What if the server
never replies?
Accept either key for a short period of time. As soon as the new key is in hand
– and one packet decrypts with it – flush the
401 - 500 of 510 matches
Mail list logo
