I think I found it.
vlib_frame_queue_main_init (sm->in2out_output_node_index, 0);
So, it will be passing to the in2out node of the next core.
Thanks Damjan.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12490):
I can see that we can create pg- interface for unit testing various vpp
features.
Is it possible to test multiple workers? How can I make sure the packets will
be sent to different workers on a pg- interface?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
Hello,
I can see that we can create pg- interface for unit testing various vpp
features.
Is it possible to test multiple workers? How can I make sure the packets will
be sent to different workers on a pg- interface?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
Hi Damjan,
Thanks for the reply. I am not very familiar with VPP yet.
Are you suggesting that the pkt will start its journey all the way from
dpdk-input on the new core?
Can't we just send the pkt directly to nat44-in2out node on the new core?
In the code, I see that, we are calling
> On 11 Mar 2019, at 19:53, Ranadip Das wrote:
>
> Hello,
>
> Once handoff node decides to handoff a pkt to another core, which node on the
> other core picks the pkt up?
> I am using 1807, and it seems like nst44-handoff-classify will send the pkt
> to either nat44-in2out-worker-handoff
Hello,
Once handoff node decides to handoff a pkt to another core, which node on the
other core picks the pkt up?
I am using 1807, and it seems like nst44-handoff-classify will send the pkt to
either nat44-in2out-worker-handoff or nat44-out2in-worker-handoff node.
nat44-in2out-worker-handoff
Hello every one
im new to vpp ipsec and i saw there has been an improvment in version vpp 19.01
for ipsec.
i have a couple of questions regarding ipsec on vpp.
1. after that i have new port name lets say "ipsec0", is there a unique
identifier that will show from what *ikev2 profile it has been
Hi Raj,
In case this might help, there is a config for statseg for VPP 18.10 in a
dockerfile entrypoint here:
https://github.com/cisco-ie/vpp-lab/blob/master/hc2vpp/entrypoint.sh#L21
It seems like the following should work because, default config is
/run/vpp/stats.sock
statseg {
default
}
Hi Ole,
I tried various combination of stats and statseg in config file but no
joy. For example this conf gives error in 18.10. though by manual it
seems ok.
stats { socket-name /run/vpp/stats.sock }
statseg { size 128M }
It would be great if you can point to the documentation for 18.10 or a
On Wed, Mar 6, 2019 at 10:42 PM Andrew Yourtchenko
wrote:
> Unfortunately I can’t give you a step by step way to isolate that trigger
> because it can be most everything potentially.
Can you see if you can reproduce the crash by running the attached
script ? In my environment, this script
This also pops up while profiling GRE traffic. Just replacing it with
clib_memcpy_fast() seems to be more clear and faster in my case:
https://gerrit.fd.io/r/c/17968/
AFAICT this should also fix the bug...
Ben
> -Original Message-
> From: vpp-dev@lists.fd.io On Behalf Of Dave Barach
>
Hi, dear VPP
I configured nat on vpp 19.01 and wanted to test it using trex. After a while,
vpp got SIGSEGV and all packets were dropped. My vpp version was
v19.01.1-2~gd0dcf7685.
Here is my vpp configuration:
https://paste.ubuntu.com/p/czRf8g6Nt6/
This is trex config file:
Hi, Neale.
I have tested the fix, the crash can not be reproduced any more.
BR/Lollita Liu
From: Neale Ranns (nranns)
Sent: Friday, March 8, 2019 8:22 PM
To: Lollita Liu ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP crash when deleting route related with GTPU tunnel
endpoint
Hi
13 matches
Mail list logo
