Hi Brayan,
I am having the same issue as well. Unfortunately, I am not familiar with
NAT code, so am not able to fix the issue.
My previous threads:
https://lists.fd.io/g/vpp-dev/message/14353
https://lists.fd.io/g/vpp-dev/message/14055
Hope we can consolidate all those into one thread.
Thank you very much, Dave! Appreciate your quick action. -John
From: vpp-dev@lists.fd.io On Behalf Of Dave Wallace
Sent: Tuesday, October 29, 2019 2:02 PM
To: vpp-dev@lists.fd.io; csit-...@lists.fd.io
Subject: [vpp-dev] VPP 19.04.3 Maintenance Release is complete!
Folks,
The VPP 19.04.3
Folks,
The VPP 19.04.3 Maintenance Release is complete and artifacts are
available on packagecloud.io [0].
Have a great day!
-daw-
"Your Friendly VPP 19.04 Release Manager"
[0] https://packagecloud.io/fdio/release
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
Guys,
Let's fix the test framework. It's reasonable for the pg to inject fewer than
60 bytes into nodes other than ethernet input. 42 would make sense in
arp-input, and so on.
FWIW... Dave
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Benoit Ganne
(bganne) via
> Unless there are real world scenarios where the device pg is emulating
> returns < 60b frames I think it would be good just to fix pg to pad. If
> code breaks based on this, wouldn't that code also break when used in
> production? :)
Packet recirculating from a tunnel (eg. ethernet inner of a
FWIW, I recently hit a bug during a demo that I would have caught but for lack
of padding by pg in UT. In my case I had tested full spread of packet sizes
using the UT framework, but hadn't done it thoroughly enough with real
interfaces and so got bit by b->current_length > iplen with small ip
Hi Ben.
Isn't it amazing how timing is everything. Would you believe this issue
came up in discussion yesterday? I was suggesting the use of alternate
interfaces, such as over tap/veth/af_packet over pg in tests.
If the behavior is changed, it should probably be done in a backward
compatible
Hi all,
While working on Address Sanitizer, I realized pg pcap replay was not padding
runt frames to 60-bytes before handing them to ethernet-input. With a real NIC,
we should never get packets smaller than 60-bytes.
This means we process very short Ethernet frames in make test. It is very
Thanks Damjon for the suggestion.
As suggested, I have tried processing the buffers and send to another thread
and another node-in same thread in the same function using two apis you
mentioned.
Though it is surely achievable, the code looks lot cluttery and non-uniform now.
Hence, I am thinking
Thanks Ping. Already Florin suggested to try out master code, I will try
that out and update. Somehow this mail was sent twice to mailing list by
mistake.
Regards,
Akshaya N
On Tue, Oct 29, 2019 at 12:07 PM Yu, Ping wrote:
> We have some test for VCL based on application too, and it looks
We have some test for VCL based on application too, and it looks fine. To
understand more, you’d check what line in mspace_malloc trigger the signal.
Attached is our vcl.conf for you to try if it is okay.
vcl {
rx-fifo-size 5000
tx-fifo-size 5000
app-scope-local
app-scope-global
api-socket-name
You can install any OpenSSL version as you wish, and you can use the following
command to tell vpp cmake to get the right OpenSSL
For example:
# export OPENSSL_ROOT_DIR=/usr/local/lib64/
# export LD_LIBRARY_PATH=/usr/local/lib64/
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On
12 matches
Mail list logo
