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"))
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 ever
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* */
VLIB_REGISTER_NODE
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: https://lists.fd.io/g/vpp-de
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, Septe
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. Conside
+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: mauricio.so
28643)
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>>
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: vpp-dev
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 manipu
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 Maintainers
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
origi
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:
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 tryin
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]
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
H
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
“... 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 tabl
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: Re
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
Please don’t SHOUT by capitalizing; especially in a case like this which
amounts to trying (unsuccessfully) to put two interfaces on the same subnet.
What this trace actually shows is that the dhcp client received two addresses.
D.
[0] GigabitEthernet2/1/0 state DHCP_BOUND installed 1 addr 192.
arach)
Cc: Christian Hopps ; vpp-dev
Subject: Re: [vpp-dev] debugging corrupted frame arguments
> On Jul 23, 2020, at 4:09 PM, Dave Barach via lists.fd.io
> wrote:
>
[ swapped the order of my reply :) ]
> Without having all of the source code available and a reasonable way to r
What is the invalid buffer index value? How many elements are in the frame? Is
it always the same frame element which takes a lightning hit?
Without having all of the source code available and a reasonable way to repro
the issue, it's going to be quite hard to help you find the culprit.
D.
You could use the vlib_node_runtime_perf_counter callback hook to run code
between node dispatches, which SHOULD give adequate precision.
Alternatively, spin up 1-N threads to run the shaper and driver TX path, and
nothing else. See also the handoff node.
HTH... Dave
-Original Message--
+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
> mailto:cho...@ch
Branches hurt performance more than arithmetic and/or conditional moves.
From: vpp-dev@lists.fd.io On Behalf Of "??
Sent: Monday, July 20, 2020 10:17 PM
To: vpp-dev
Subject: [vpp-dev] Why not break the check flow when the first error occurs of
ip4_inout()?
Hi all,
When I'm reading the ip4_inp
Hint: “pcap dispatch trace on max 1 buffer-trace 1000”,
then look at the resulting trace in wireshark. It will explain in excruciating
detail how packets flow through the graph.
D.
From: vpp-dev@lists.fd.io On Behalf Of
gerard.ke...@owmobility.com
Sent: Monday, July 20, 2020 9:18 AM
To:
We can merge the patch as soon as Neale removes his -2 from it... D.
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Christian Hopps
Sent: Monday, July 20, 2020 7:50 AM
To: vpp-dev
Cc: Christian Hopps ; Neale Ranns (nranns)
Subject: [vpp-dev] Regarding new ipsec interface patc
You’ve shown that your proprietary code runs a packet through a path which hits
the tx pcap recorder twice, so you get two trace records.
Solutions include creating a no-pcap-trace variant node, or marking buffer
metadata to suppress the second record.
HTH... Dave
From: vpp-dev@lists.fd.io O
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: [vpp-de
)
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 c
+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 4:
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 master/s
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 `vlib_get_th
“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...
Dav
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 would
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 e
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: vpp-dev@l
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-
F
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 misbeh
"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 Issue
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;
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
#
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 a
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
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 ne
vpp "process" nodes are cooperative multitasking threads. Emphasis on
cooperative. There is no force of physics which will cause such a thread to
deschedule unless it chooses to give up the CPU. Toss in a runtime limit +
vlib_process_suspend (...) and see if that improves matters...
Dave
_
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 don
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 API
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
-Original
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 A
+check hardware addresses with “show hardware”, to make sure you’ve configured
the interface which is actually connected to the peer system / switch...
HTH... Dave
From: vpp-dev@lists.fd.io On Behalf Of steven luong via
lists.fd.io
Sent: Friday, June 12, 2020 4:18 PM
To: Manoj Iyer ; vpp-dev@l
mailto: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
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 ol
0585616e0 .../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
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): https://l
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 s
blem
(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:
>
>
Christian 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...
>
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
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
vpp 18.10 is not supported anymore, and the skip-list code has been deprecated.
From: vpp-dev@lists.fd.io On Behalf Of hari_akkin via
lists.fd.io
Sent: Thursday, June 4, 2020 12:53 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] format_slist
Hi,
I am facing an issue with format_slist where it is
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):
* @clie
+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 manu
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
--
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 handl
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: vpp-dev
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)
{
uwo
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,
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 Barach
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 nat_get_vlib_main
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 sor
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: vpp-dev@
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: vpp-dev@lists.fd.i
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 f
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,
MYPLUGIN_ERROR_WHAT
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 Glaz
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 Beha
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 " opti
+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 o
+1... Dave
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Dave Barach via
lists.fd.io
Sent: Tuesday, April 21, 2020 7:40 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] vpp project committer nomination: Benoit Ganne
Vpp project committers: please vote +1, 0, -1 on the
Vpp project committers: please vote +1, 0, -1 on the mailto:vpp-dev@lists.fd.io
mailer as to whether we should add Benoit Ganne as a vpp project committer.
Ben has about 150 merged patches, see
https://gerrit.fd.io/r/q/status:merged+owner:bganne%2540cisco.com. He has
expressed interest in the
>
mailto:vpp-dev@lists.fd.io>> On Behalf Of Dave Barach via
lists.fd.io
Sent: Saturday, April 18, 2020 2:06 PM
To: csit-...@lists.fd.io<mailto:csit-...@lists.fd.io>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] perftest stuck: "do_not_use_du
If you turn on the main loop dispatch event logs and look at the results in the
g2 viewer [or dump them in ascii] you can make pretty accurate lap time
estimates for any workload. Roughly speaking, packets take 1 lap time to arrive
and then leave.
The “circuit-node ” game produces one elog even
Folks,
I kicked off a "perftest-3n-skx" run for https://gerrit.fd.io/r/c/vpp/+/26549.
24 hours later, the job is still stuck:
07:58:00 +++ python3
/w/workspace/vpp-csit-verify-perf-master-3n-skx/csit/resources/tools/scripts/topo_reservation.py
-t
/w/workspace/vpp-csit-verify-perf-master-3n-sk
mailto:ayour...@gmail.com>> wrote:
I made https://gerrit.fd.io/r/#/c/vpp/+/22963/ that you can try and see how it
works for you.
It allows to install the “correct” version of indent into the build tree, so
the rest of the system is unaffected.
--a
On 11 Apr 2020, at 14:04, Dave Barach vi
Please try https://gerrit.fd.io/r/c/vpp/+/26505. Bit rot.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16071): https://lists.fd.io/g/vpp-dev/message/16071
Mute This Topic: https://lists.fd.io/mt/73008683/21656
Mute #vat: https://lists.fd.io/mk?has
As a matter of discipline, you’d be better off to continue binding symbols
explicitly. Otherwise, what you end up with amounts to one plugin split into
pieces.
As things stand, if someone misconfigures the set of loaded plugins it ought to
be obvious what happened. (“Where is the foo plugin?”).
See src/vnet/ip4_neighbor.c:ip4_arp_inline (...), look for
“throttle_check(...)”.
D.
From: vpp-dev@lists.fd.io On Behalf Of
super_and...@sina.com
Sent: Sunday, April 12, 2020 8:46 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] a question about vpp arp processing
when vpp recevie a data packet，
The script works fine. You have the wrong version of gnu indent installed. This
is the version you need:
$ indent --version
GNU indent 2.2.11
From: vpp-dev@lists.fd.io On Behalf Of Zhang Yuwei
Sent: Saturday, April 11, 2020 1:04 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Checkstyle script no
Vpp has a built-in leakfinder which should help. Try:
“memory-trace on main-heap”
“show memory main-heap [verbose]”
Which will display objects allocated since “memory-trace on”, complete with the
allocation backtrace.
Suggest turning off debug CLI history to avoid looking at newly-allocated
Folks,
I built a test tool to make vlib_buffer_alloc(...) pretend that the system is
running out of buffers. In so doing, I found a certain number of 1-off bugs.
That's not the subject here.
I found a number of these floating around:
c0 = vlib_buffer_copy (vm, p0);
ci0 = vlib_get_buffer_in
1 - 100 of 527 matches
Mail list logo
