Hello again,
Here is another fix to avoid assertion failure due to vlib_time_now()
being called with a vm corresponding to a different thread, in
nat_ipfix_logging.c:
https://gerrit.fd.io/r/c/vpp/+/27281
Please have a look and merge if it seems okay. Maybe it could be done
more elegantly, this
Hello VPP experts,
When testing the current master branch for NAT with ipfix logging
enabled we encountered a problem with a segmentation fault crash. It
seems like this was caused by a bug in set_ipfix_exporter_command_fn()
in vnet/ipfix-export/flow_report.c where the variable collector_port
is
$ lscpu
Architecture: aarch64
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0
Off-line CPU(s) list: 1-7
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s):1
NUMA node(s): 1
Vendor ID:ARM
Model:3
Can you capture:
lscpu
grep . /sys/kernel/mm/hugepages/hugepages-*/*
grep . /sys/devices/system/node/node*/hugepages/hugepages-*/*
—
Damjan
> On 27 May 2020, at 00:50, Manoj Iyer wrote:
>
> But the issue is VPP's dpgk plugin fails and VPP service is not started as a
> result.
> From:
But the issue is VPP's dpgk plugin fails and VPP service is not started as a
result.
From: Damjan Marion
Sent: Tuesday, May 26, 2020 5:44 PM
To: bga...@cisco.com
Cc: Manoj Iyer ; vpp-dev@lists.fd.io ;
Rodney Schmidt ; Kshitij Sudan
Subject: Re: [vpp-dev] VPP
VPP passes --in-memory so there should be no hugepage files created in the
fliesystem.
> On 26 May 2020, at 18:42, Benoit Ganne (bganne) via lists.fd.io
> wrote:
>
> Hi Manoj,
>
> The issue is because of DPDK initialization. In the working conf, you disable
> DPDK plugin so DPDK is not
I used the same arguments that vpp dpdk-config is using, and passed it to the
dpdk-testpmd, with hugepages set to 2M.
$ cat /proc/meminfo | grep -i huge
AnonHugePages: 0 kB
ShmemHugePages:0 kB
FileHugePages: 0 kB
HugePages_Total:1024
HugePages_Free: 1024
I also tried the nuclear options.
Set the kernel command line to
== 1G hugepages ==
default_hugepagesz=1G hugepagesz=1G hugepages=4 hugepagesz=2M hugepages=1024
$ sudo mount -t hugetlbfs -o pagesize=1G nodev /mnt/hugepages1G
$ sudo modprobe igb_uio
$ sudo dpdk-devbind.py --bind=igb_uio
Dear VPP community,
This article may be of interest to you:
https://medium.com/fd-io-vpp/getting-to-40g-encrypted-container-networking-with-calico-vpp-on-commodity-hardware-d7144e52659a
Regards,
Jerome
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online
Hi Govind,
I'm NOT one of the GTPu maintainers, but I do work on a UPF implementation
based on VPP.
The GTPu plugin is IMHO mostly useless and broken by design in its current
state. It assumes that TEIDs are symmetric which they never are in real
3GPP settings.
There is an outdated change in
Shmuel,
When I run that command I got the following:
$ sudo dpdk-testpmd
EAL: Detected 1 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: No available hugepages reported in hugepages-32768kB
EAL: No available hugepages
Strange.
I usually unmount and then mount the hugepages mount point before using it,
just to be sure.
Maybe the two different mount points confuse DPDK somehow.
By the way, if you have dpdk-testpmd, what is its output? Does it return
the same error message?
- Shmuel Hazan
oops I should have mentioned that in my reply.. sorry no did not find any files
in /mnt/huge
:/mnt/huge$ ls -lah
total 4.0K
drwxr-xr-x 2 root root0 May 26 15:57 .
drwxr-xr-x 3 root root 4.0K May 26 15:57 ..
From: vpp-dev@lists.fd.io on behalf of Benoit
> That is exactly the problem now. I need to use DPDK, and how do I get the
> plugin to work? Do we know the root cause of the issue why the plugin
> fails? Any pointers on this would be really appreciated.
As mentioned in my 1st email, can you check whether /mnt/huge is full of
dpdk-created
From: Benoit Ganne (bganne)
Sent: Tuesday, May 26, 2020 12:31 PM
To: Manoj Iyer ; vpp-dev@lists.fd.io
Cc: Rodney Schmidt ; Kshitij Sudan
Subject: RE: [vpp-dev] VPP fails to start - error message EAL: FATAL: Cannot
get hugepage information.
> I removed the
> I removed the plugin and it starts the service!
[...]
> At this point, I think I should be able to use the VPP console to set up
> the interfaces etc. Is there any other gotcha I need to be aware of ?
Which interfaces are you going to use to rx/tx packets? VPP natively supports
some Intel,
Ben,
I removed the plugin and it starts the service!
ubuntu@sst100:~$ sudo systemctl status vpp
? vpp.service - Vector Packet Processing Process
Loaded: loaded (/lib/systemd/system/vpp.service; enabled; vendor preset: enab
led)
Active: active (running) since Tue 2020-05-26 16:45:22 UTC; 4s
Hi Manoj,
The issue is because of DPDK initialization. In the working conf, you disable
DPDK plugin so DPDK is not initialized and everything is fine.
Can you check whether /mnt/huge is full of dpdk-created staled files? I saw
this happen from time to time. The fix is simple, just remove the
Hello,
I am trying to start the VPP (19.04) service on an ARM64 system. VPP fails with
the message:
/usr/bin/vpp[1252]: dpdk: EAL init args: -c 1 -n 4 --in-memory --file-prefix
vpp -w 0008:01:00.0 --master-lcore 0
EAL: FATAL: Cannot get hugepage information.
vpp[1252]: dpdk_config:
Hi,
That might actually be the fix :). It so happens that I was on top of
"stable/2001" which doesn't have this commit, but I see "master" and
"stable/2005" do have it, dammit.
However, I'll give it a try and let u know if you want to.
Thank you
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all
Are you sure this isn't fixed with:
commit b5c0d35f9445d4d99f2c5c7bd3175e68721a8ee5
Author: Neale Ranns
Date: Wed Apr 22 16:06:45 2020 +
vapi: packed enum type generation
Type: fix
if the ,api/.json specifies that a enum should be u8/u16 that the
generated c enum needs to
Hi all,
I don't know if this is the right place to ask and if the "issue" here is
really an expected one, or if I'm just doing something really stupid. So,
someone please do let me know.
I found some inconsistencies in some API header files installed under
"/usr/include/" , in my case
HI,
Thanks for the bug report. Here’s the patch:
https://gerrit.fd.io/r/c/vpp/+/27270
/neale
From: on behalf of "chu.penghong"
Date: Monday 25 May 2020 at 05:06
To: "vpp-dev@lists.fd.io"
Subject: [vpp-dev] vpp crashes on configuring ip6 route
Hello Everyone!
When I add/delete ip6
Hi,
I had more or less the same question something like 2 years ago, and guess
what, to date still no reply whatsoever. I'd think the plugin's developer is
untraceable and/or "out of duty".
Now back to the question, if I didn't misunderstood this GTPU plugin's
semantics (by reading the code),
Actually, I missed one detail, if you tell vppctl to run a command using its
command line arguments, it will always assume non-interactive.
The only way you’ll see the banner, then, is if the 1s session startup timer
expires and it makes assumptions. In those cases that you see the output, does
Hi,
We want to run VPP on both VM and host. For VM, we found a link
https://wiki.fd.io/view/VPP/How_To_Optimize_Performance_(System_Tuning) that
states that recommended system configuration is (In section, In a VM: Configure
KVM Parameters )
RAM = 8 GB
Cores = 4
SMP = 2
Threads = 2
What is
You’ll get the banner if it thinks it’s an interactive session.
Roughly vppctl does this (I am paraphrasing):
is_interactive = isatty(STDIN);
…
if (is_interactive) TERM = “vppctl”;
…
open telnet session to the CLI socket; pass the terminal information
Then in VPP:
is_interactive =
Further adding to observations regarding above issue, we have created a script
that has only vpp commands running sequentially having a constant delay between
the execution of each commands. On running the script, we again see VPP shell
output as shown below :-
___ _ _ _
Thanks! I’ll push a patch.
Regards,
Klement
> On 26 May 2020, at 12:33, Miklos Tirpak wrote:
>
> Yes, it works with ip0:
>
> vnet_buffer (b0)->ip.reass.is_non_first_fragment =
>! !ip4_get_fragment_offset (ip0);
>
> Thanks,
> Miklos
> From: Klement Sekera -X (ksekera - PANTHEON TECH SRO
Yes, it works with ip0:
vnet_buffer (b0)->ip.reass.is_non_first_fragment =
! !ip4_get_fragment_offset (ip0);
Thanks,
Miklos
From: Klement Sekera -X (ksekera - PANTHEON TECH SRO at Cisco)
Sent: Tuesday, May 26, 2020 12:14 PM
To: Miklós Tirpák
Cc:
I think it’s enough if instead of vlib_buffer_get_current(b0) we just use ip0
(that already takes save_rewrite_length into consideration). Can you please
test with this modification?
Thanks,
Klement
> On 26 May 2020, at 11:51, Miklos Tirpak wrote:
>
> Hi,
>
> I think there is a problem in
Hi Klement,
thank you for your response.
ip.reass.is_non_first_fragment is set to 1 also for the first fragment.
(gdb) p ((vnet_buffer_opaque_t *) (b0)->opaque)->ip.reass.is_non_first_fragment
$8 = 1 '\001'
I think the fragment offset is wrongly calculated from the buffer:
(gdb) p
Hi,
I think there is a problem in ip4_sv_reass_inline(), it does not consider
ip.save_rewrite_length when it calculates is_non_first_fragment at line 619
(master):
vnet_buffer (b0)->ip.reass.is_non_first_fragment =
! !ip4_get_fragment_offset
Hi Miklos,
thanks for your message. If is_non_first_fragment is set to true then rewrite
will not happen. Can you take a look at what happens in ip4_sv_reass_inline for
the first packet/fragment?
Setting that flag should be pretty fool-proof
498 const u32 fragment_first =
Hi,
we have a scenario where an ICMP packet arrives fragmented over a GTP-U tunnel.
The outer IP packets are not fragmented, only the inner ones are. After GTP-U
decapsulation, the packets are routed via an interface where NAT44
output-feature is configured.
In the outgoing packets, the
35 matches
Mail list logo
