Re: [vpp-dev] VPP linux-cp plugin with multicast packets
Now I run into another issue when using linux-cp to create pair for ETH0, VPP0 on both VPP0 and VPP1: FRR0VPP 0(192.168.1.6)- (192.168.1.1)R (192.168.2.1)-VPP1 (192.168.2.6)-FRR1 VPP0ETH0 ETH0 VPP0 FRR0 trying to connect to FRR1, the BGP syn packet received in VPP0, but it can't find adjacency and dropped it. Looks to me linux-cp-xc-ip4 it not using the FIB table to route the packets. Is there anything I should configure to make it work? Here is the packet trace: Packet 32 02:28:53:416670: virtio-input virtio: hw_if_index 8 next-index 4 vring 0 len 74 hdr: flags 0x00 gso_type 0x00 hdr_len 0 gso_size 0 csum_start 0 csum_offset 0 num_buffers 1 02:28:53:416678: ethernet-input IP4: fa:16:3f:30:99:2d -> fa:16:3f:dd:32:d9 02:28:53:416683: ip4-input TCP: 192.168.1.6 -> 192.168.2.6 tos 0xc0, ttl 64, length 60, checksum 0xaa00 dscp CS6 ecn NON_ECN fragment id 0x0b9f, flags DONT_FRAGMENT TCP: 35390 -> 179 seq. 0xc9f0d6b6 ack 0x flags 0x02 SYN, tcp header: 40 bytes window 26880, checksum 0x3a9f 02:28:53:416689: linux-cp-xc-ip4 lcp-xc: itf:1 adj:0 02:28:53:416705: ip4-drop MHRP: 8.0.69.192 -> 0.60.11.159 version 15, header length 40 tos 0x16, ttl 63, length 16349, checksum 0x992d (should be 0xfd08) dscp unknown ecn ECT_1 fragment id 0x32d9 offset 53424, flags MORE_FRAGMENTSDONT_FRAGMENTCONGESTION 02:28:53:416708: error-drop rx:tap1 02:28:53:416710: drop ethernet-input: no error vpp# show adj [@0] ipv4-glean: [src:0.0.0.0/0] tn-eth0: mtu:9000 next:1 flags:[] fa163f30992d0806 [@1] ipv4-glean: [src:192.168.1.0/24] tn-eth0: mtu:9000 next:1 flags:[] fa163f30992d0806 [@2] ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:7 flags:[] fa163fdd32d9fa163f30992d0800 [@3] ipv4-glean: [src:0.0.0.0/0] tn-eth1: mtu:9000 next:2 flags:[] fa163f93d4ea0806 [@4] ipv4-glean: [src:192.168.10.0/24] tn-eth1: mtu:9000 next:2 flags:[] fa163f93d4ea0806 [@5] ipv4 via 192.168.10.1 tn-eth1: mtu:9000 next:6 flags:[] fa163f3186d0fa163f93d4ea0800 [@6] ipv4-glean: [src:0.0.0.0/0] tn-eth2: mtu:9000 next:3 flags:[] fa163f3e79000806 [@7] ipv4-glean: [src:192.168.100.0/24] tn-eth2: mtu:9000 next:3 flags:[] fa163f3e79000806 [@8] ipv4-glean: [src:0.0.0.0/0] host-vppeth: mtu:9000 next:4 flags:[] 02fe6fdf582e0806 [@9] ipv4-glean: [src:192.168.11.0/24] host-vppeth: mtu:9000 next:4 flags:[] 02fe6fdf582e0806 [@10] ipv4-mcast: tn-eth2: mtu:9000 next:5 flags:[] 01005e00fa163f3e79000800 [@11] ipv6-mcast: tn-eth2: mtu:9000 next:5 flags:[] fa163f3e790086dd [@12] ipv6-glean: [src:0.0.0.0/0] tn-eth2: mtu:9000 next:2 flags:[] fa163f3e790086dd [@13] ipv4 via 0.0.0.0 ipip0: mtu:9000 next:9 flags:[fixup-ip4o4 ] 45004004f69dc0a80106c0a80206 stacked-on entry:31: [@3]: ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:7 flags:[] fa163fdd32d9fa163f30992d0800 [@14] ipv4 via 192.168.11.2 host-vppeth: mtu:9000 next:10 flags:[] f2b67ee4bb8e02fe6fdf582e0800 [@15] ipv4 via 192.168.100.20 tn-eth2: mtu:9000 next:5 flags:[] fa163fa92cccfa163f3e79000800 [@16] ipv6 via fe80::f816:3fff:fea9:2ccc tn-eth2: mtu:9000 next:5 flags:[] fa163fa92cccfa163f3e790086dd [@17] ipv4-mcast: tn-eth0: mtu:9000 next:7 flags:[] 01005e00fa163f30992d0800 [@18] ipv6-mcast: tn-eth0: mtu:9000 next:6 flags:[] fa163f30992d86dd [@19] ipv6-glean: [src:0.0.0.0/0] tn-eth0: mtu:9000 next:3 flags:[] fa163f30992d86dd vpp# show ip fib 192.168.2.6 ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[adjacency:1, recursive-resolution:2, default-route:1, lcp-rt:1, ] 192.168.2.6/32 fib:0 index:31 locks:3 recursive-resolution refs:1 src-flags:added,contributing,active, cover:11 path-list:[52] locks:4 flags:shared, uPRF-list:47 len:1 itfs:[1, ] path:[72] pl-index:52 ip4 weight=1 pref=0 attached-nexthop: oper-flags:resolved, 192.168.1.1 tn-eth0 [@0]: ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:7 flags:[] fa163fdd32d9fa163f30992d0800 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:32 buckets:1 uRPF:47 to:[592:61840]] [0] [@5]: ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:7 flags:[] fa163fdd32d9fa163f30992d0800 Thanks in advance for any help, Wei From: Wei Huang Sent: Tuesday, November 16, 2021 10:08 PM To: vpp-dev@lists.fd.io Subject: VPP linux-cp plugin with multicast packets I am using the linux-cp plugin in VPP (v21.06) and run into issues with multicast packet from OSPF. I try to make FRR work with VPP. I created a lcp pair (ETH2-VPP2), ETH2 directly connect to router using OSPF. FRR--VPP
Re: [vpp-dev] det44 and map plugins interfere with linux-cp
On 19/11/2021 13:32, Ben McKeegan via lists.fd.io wrote:
Firstly, with the map plugin it appears to break IPv6 connectivity: the
control plane can no longer successfully do NDP to the external gateway
(a layer 3 switch). NDP replies from the gateway to the control plane
do not arrive. There is a very simple workaround: if I put in a static
neighbour entry in Linux (with 'ip neigh replace ...') everything else
works. I have not yet understood why this happens although as I have a
workaround I did not spent too long on investigating it.
It turns out this was fairly straightforward, see patch below which
fixed it for me. Previously, the code checked for ICMP6 echo request
and reply codes and handled these locally, attempting to relay
everything else (and discarding any that are not suitable for relaying).
For now I have added similar exceptions for NDP and RAs, but this
seems a little backward to me. Should we make IP6_MAP_NEXT_IP6_LOCAL
the default and only set IP6_MAP_NEXT_IP6_ICMP_RELAY for one of the four
ICMP6 error codes that ip6_map_icmp_relay() actually checks for? The
comment in the code says:
* ICMP IPv6 packet
* - Error -> Pass to ICMPv6/ICMPv4 relay
* - Info -> Pass to IPv6 local
... which makes sense, but doesn't match what the code was doing.
diff --git a/src/plugins/map/ip6_map.c b/src/plugins/map/ip6_map.c
index 1193dda0a..d400c634c 100644
--- a/src/plugins/map/ip6_map.c
+++ b/src/plugins/map/ip6_map.c
@@ -246,8 +246,11 @@ ip6_map (vlib_main_t * vm, vlib_node_runtime_t *
node, vlib_frame_t * frame)
{
icmp46_header_t *icmp = (void *) (ip60 + 1);
next0 = (icmp->type == ICMP6_echo_request
- || icmp->type ==
- ICMP6_echo_reply) ? IP6_MAP_NEXT_IP6_LOCAL :
+ || icmp->type == ICMP6_echo_reply
+ || icmp->type == ICMP6_neighbor_solicitation
+ || icmp->type == ICMP6_neighbor_advertisement
+ || icmp->type == ICMP6_router_solicitation
+ || icmp->type == ICMP6_router_advertisement) ?
IP6_MAP_NEXT_IP6_LOCAL :
IP6_MAP_NEXT_IP6_ICMP_RELAY;
}
else if (ip60->protocol == IP_PROTOCOL_IPV6_FRAGMENTATION)
@@ -273,8 +276,11 @@ ip6_map (vlib_main_t * vm, vlib_node_runtime_t *
node, vlib_frame_t * frame)
{
icmp46_header_t *icmp = (void *) (ip61 + 1);
next1 = (icmp->type == ICMP6_echo_request
- || icmp->type ==
- ICMP6_echo_reply) ? IP6_MAP_NEXT_IP6_LOCAL :
+ || icmp->type == ICMP6_echo_reply
+ || icmp->type == ICMP6_neighbor_solicitation
+ || icmp->type == ICMP6_neighbor_advertisement
+ || icmp->type == ICMP6_router_solicitation
+ || icmp->type == ICMP6_router_advertisement) ?
IP6_MAP_NEXT_IP6_LOCAL :
IP6_MAP_NEXT_IP6_ICMP_RELAY;
}
else if (ip61->protocol == IP_PROTOCOL_IPV6_FRAGMENTATION)
@@ -451,8 +457,11 @@ ip6_map (vlib_main_t * vm, vlib_node_runtime_t *
node, vlib_frame_t * frame)
{
icmp46_header_t *icmp = (void *) (ip60 + 1);
next0 = (icmp->type == ICMP6_echo_request
- || icmp->type ==
- ICMP6_echo_reply) ? IP6_MAP_NEXT_IP6_LOCAL :
+ || icmp->type == ICMP6_echo_reply
+ || icmp->type == ICMP6_neighbor_solicitation
+ || icmp->type == ICMP6_neighbor_advertisement
+ || icmp->type == ICMP6_router_solicitation
+ || icmp->type == ICMP6_router_advertisement) ?
IP6_MAP_NEXT_IP6_LOCAL :
IP6_MAP_NEXT_IP6_ICMP_RELAY;
}
else if (ip60->protocol == IP_PROTOCOL_IPV6_FRAGMENTATION &&
Regards,
Ben.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20523): https://lists.fd.io/g/vpp-dev/message/20523
Mute This Topic: https://lists.fd.io/mt/87167458/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] About Risc-V Porting
Hi Damjan,
I am using Ubuntu 20.04 image on Qemu.
I had to do following changes to make it work.
diff --git a/src/vppinfra/CMakeLists.txt b/src/vppinfra/CMakeLists.txt
index 58ec32fbf..2168da185 100644
--- a/src/vppinfra/CMakeLists.txt
+++ b/src/vppinfra/CMakeLists.txt
@@ -219,7 +219,7 @@ if(VPP_USE_EXTERNAL_LIBEXECINFO)
endif()
add_vpp_library(vppinfra
SOURCES ${VPPINFRA_SRCS}
- LINK_LIBRARIES m ${EXECINFO_LIB}
+ LINK_LIBRARIES m ${EXECINFO_LIB} atomic
INSTALL_HEADERS ${VPPINFRA_HEADERS}
COMPONENT libvppinfra
LTO
ubuntu@ubuntu:~/work/vpp$
ubuntu@ubuntu:~/work/vpp$
ubuntu@ubuntu:~/work/vpp$
ubuntu@ubuntu:~/work/vpp$
ubuntu@ubuntu:~/work/vpp$ uname -a
Linux ubuntu 5.11.0-1022-generic #23~20.04.1-Ubuntu SMP Thu Oct 21 10:16:27
UTC 2021 riscv64 riscv64 riscv64 GNU/Linux
ubuntu@ubuntu:~/work/vpp$
Thanks,
Hrishikesh
On Fri, Nov 12, 2021 at 6:01 PM Damjan Marion wrote:
>
> Hi,
>
> i tried to repro with gcc-10 on ubuntu 21.10 x86_64 and everything works
> fine.
> Only caveat is that I had to pass -Wno-stringop-overflow in CFLAGS.
>
> —
> Damjan
>
>
>
> On 10.11.2021., at 08:29, Hrishikesh Karanjikar <
> hrishikesh.karanji...@gmail.com> wrote:
>
> Hi Damjan,
>
> I upgraded my Unmatched board to run Ubuntu 21.10 from 21.04.
> I was able to build VPP on Unmatched.
> I am also trying to build it on Qemu with GCC 10.
> I am getting following error,
>
>
>
>
> ubuntu@ubuntu:~/work/vpp$ make build
> make[1]: Entering directory '/home/ubuntu/work/vpp/build-root'
> Arch for platform 'vpp' is native
> Finding source for external
> Makefile fragment found in /home/ubuntu/work/vpp/build-data/packages/
> external.mk
> Source found in /home/ubuntu/work/vpp/build
> Arch for platform 'vpp' is native
> Finding source for vpp
> Makefile fragment found in /home/ubuntu/work/vpp/build-data/packages/
> vpp.mk
> Source found in /home/ubuntu/work/vpp/src
> find: ‘/home/ubuntu/work/vpp/build-root/config.site’: No such file or
> directory
> Configuring external: nothing to do
> Building external: nothing to do
> Installing external: nothing to do
> find: ‘/home/ubuntu/work/vpp/build-root/config.site’: No such file or
> directory
> Configuring vpp: nothing to do
> Building vpp in
> /home/ubuntu/work/vpp/build-root/build-vpp_debug-native/vpp
> [2/1463] Linking C executable bin/svmtool
> FAILED: bin/svmtool
> : && ccache /usr/lib/ccache/gcc-10
> CMakeFiles/svm/CMakeFiles/svmtool.dir/svmtool.c.o -o bin/svmtool
>
> -Wl,-rpath,/home/ubuntu/work/vpp/build-root/build-vpp_debug-native/vpp/lib/riscv64-linux-gnu::
> lib/riscv64-linux-gnu/libsvm.so.22.02
> lib/riscv64-linux-gnu/libvppinfra.so.22.02 -lm -lrt -lpthread && :
> /usr/bin/ld: lib/riscv64-linux-gnu/libvppinfra.so.22.02: undefined
> reference to `__atomic_exchange_1'
> collect2: error: ld returned 1 exit status
> [3/1463] Linking C executable bin/svmdbtool
> FAILED: bin/svmdbtool
> : && ccache /usr/lib/ccache/gcc-10
> CMakeFiles/svm/CMakeFiles/svmdbtool.dir/svmdbtool.c.o -o bin/svmdbtool
>
> -Wl,-rpath,/home/ubuntu/work/vpp/build-root/build-vpp_debug-native/vpp/lib/riscv64-linux-gnu::
> lib/riscv64-linux-gnu/libsvmdb.so.22.02
> lib/riscv64-linux-gnu/libsvm.so.22.02
> lib/riscv64-linux-gnu/libvppinfra.so.22.02 -lm -lrt -lpthread && :
> /usr/bin/ld: lib/riscv64-linux-gnu/libvppinfra.so.22.02: undefined
> reference to `__atomic_exchange_1'
> collect2: error: ld returned 1 exit status
> [5/1463] Building C object
> CMakeFiles/vlib/CMakeFiles/vlib_objs.dir/drop.c.o
> ninja: build stopped: subcommand failed.
> make[1]: *** [Makefile:693: vpp-build] Error 1
> make[1]: Leaving directory '/home/ubuntu/work/vpp/build-root'
> make: *** [Makefile:356: build] Error 2
>
>
>
> Libatomic is present on my machine.
>
> Can you give me some pointers to resolve the same?
>
> Thanks,
> Hrishikesh
>
> On Mon, Nov 8, 2021 at 8:19 PM Hrishikesh Karanjikar <
> hrishikesh.karanji...@gmail.com> wrote:
>
>> Hi,
>>
>> This is great.
>> Thanks a lot.
>> Let me try that.
>>
>> Hrishikesh
>>
>> On Mon, Nov 8, 2021 at 8:00 PM Damjan Marion wrote:
>>
>>> I compiled directly on the Unmatched board. I also submitted series of
>>> patches which are fixing all
>>> issues you are referring to.
>>>
>>> you can use both clang and gcc, problem with clang is that some parts of
>>> VPP unconditionally turn address sanitiser on and there is no ASAN
>>> shared libraries available for risc-v.
>>> You can bypass this temporarely by commenting out test_pnat, test_vat
>>> and test_vat2 targets.
>>>
>>> I also managed to cross-compile vpp on ubuntu system by using debian
>>> multiarch libs.
>>>
>>> # dpkg --add-architecture riscv64
>>>
>>> Update sources.list:
>>>
>>> deb
[vpp-dev] det44 and map plugins interfere with linux-cp
Hi,
I have been experimenting recently with use of the linux-cp plugin to
run BGP, my intention being to implement failover and load-sharing of
various networking functions such as map or det44 among pools of VPP
instances. (The map plugin's protocols are ideally suited to BGP
anycasting, whereas for det44 I am running VRRP on the inside interface
and will be adjusting my BGP advertisements of the outside addresses
based on the inside VRRP status)
linux-cp works a treat on its own (v21.10) and I have no trouble
establishing BGP sessions using FRR, but I've been hitting some issues
when enabling extra plugins on the same interfaces that my BGP control
plane is using.
Firstly, with the map plugin it appears to break IPv6 connectivity: the
control plane can no longer successfully do NDP to the external gateway
(a layer 3 switch). NDP replies from the gateway to the control plane
do not arrive. There is a very simple workaround: if I put in a static
neighbour entry in Linux (with 'ip neigh replace ...') everything else
works. I have not yet understood why this happens although as I have a
workaround I did not spent too long on investigating it.
Secondly, with the det44 plugin enabled (on a different instance) then
all IPv4 connectivity to the control plane was broken. In my case
(running BGP only on the 'outside' interface) this is because the
det44_out2in_node function is rather overzealous: it grabs all IPv4
packets received and attempts to translate them, and if it has no
matching mapping configuration for the destination address it will drop
the packet.
I have come up with a very simple fix which works for me: if the
destination address belongs to the receiving interface, then skip the
TTL check and NAT:
diff --git a/src/plugins/nat/det44/det44_out2in.c
b/src/plugins/nat/det44/det44_out2in.c
index 111bc61c4..e128b794e 100644
--- a/src/plugins/nat/det44/det44_out2in.c
+++ b/src/plugins/nat/det44/det44_out2in.c
@@ -425,6 +425,10 @@ VLIB_NODE_FN (det44_out2in_node) (vlib_main_t * vm,
tcp0 = (tcp_header_t *) udp0;
sw_if_index0 = vnet_buffer (b0)->sw_if_index[VLIB_RX];
+ /* do not interfere with packets to the interface address
(control plane) */
+ if (PREDICT_FALSE (!det44_is_interface_addr (node, sw_if_index0,
+
ip0->dst_address.as_u32)))
+goto trace0;
if (PREDICT_FALSE (ip0->ttl == 1))
{
@@ -543,6 +547,10 @@ VLIB_NODE_FN (det44_out2in_node) (vlib_main_t * vm,
tcp1 = (tcp_header_t *) udp1;
sw_if_index1 = vnet_buffer (b1)->sw_if_index[VLIB_RX];
+ /* do not interfere with packets to the interface address
(control plane) */
+ if (PREDICT_FALSE (!det44_is_interface_addr (node, sw_if_index1,
+
ip1->dst_address.as_u32)))
+goto trace1;
if (PREDICT_FALSE (ip1->ttl == 1))
{
@@ -688,6 +696,10 @@ VLIB_NODE_FN (det44_out2in_node) (vlib_main_t * vm,
tcp0 = (tcp_header_t *) udp0;
sw_if_index0 = vnet_buffer (b0)->sw_if_index[VLIB_RX];
+ /* do not interfere with packets to the interface address
(control plane) */
+ if (PREDICT_FALSE (!det44_is_interface_addr (node, sw_if_index0,
+
ip0->dst_address.as_u32)))
+goto trace00;
if (PREDICT_FALSE (ip0->ttl == 1))
{
This works well for me as I have BGP advertise routes to the outside
prefixes of my det44 mappings, with the non-overlapping interface
address as the next hop.
The downside of this patch is if anyone is relying on being able to NAT
using the first interface address, rather than a routed prefix or
secondary address, then it would break it for them. Is that a use case
we should try to retain support for? (Based on my recent discovery of
the long standing session scavenging bug in this plugin, I suspect there
are few if any other serious users of it.)
My first attempt of the patch put the interface check after the mapping
table lookup, inside the "if (PREDICT_FALSE (!mp0))" clauses, so it
would still be possible to NAT the interface's address if you did not
need to use if for control plane traffic. However, I found my BGP
packets then fell foul of the TTL check in this node. Thus to continue
to support NAT of the first interface address would require additional
refactoring of the code to move the TTL check after the map lookup, and
special handling for the ICMP code path too. I feel this would add too
much complexity to the code for little gain.
What do people think?
Regards,
Ben.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20521): https://lists.fd.io/g/vpp-dev/message/20521
Mute This Topic: https://lists.fd.io/mt/87167458/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Memory leak in map plugin
Hi Ben,
Thank you for the patch, that fixes it!
Regards,
Ben.
On 17/11/2021 08:24, Benoit Ganne (bganne) via lists.fd.io wrote:
Hi Ben,
Thanks for the detailed report, you are correct we are missing a vec_free()
before returning from the function.
Can you give a try to https://gerrit.fd.io/r/c/vpp/+/34536 ?
Best
ben
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Ben McKeegan
Sent: mardi 16 novembre 2021 15:04
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Memory leak in map plugin
Hello,
I have identified a memory leak the ip4_map function of
src/plugins/ip4_map.c. I am using the 21.10 release.
Enabling memory trace of the main-heap via the debug CLI and backtracing
with gdb both point to all the leaked memory being allocated from the
vec_add1(buffer0,pi0) macro at line 293 of ip4_map.c. In tests it is
leaking approximately 50 bytes for every packet passing through this
function (invariant on packet size).
Here is an extract of the relevant code:
exit:
/* Send fragments that were added in the frame */
if (free_original_buffer0)
{
vlib_buffer_free_one (vm, pi0); /* Free original packet */
}
else
{
vec_add1 (buffer0, pi0); leak is here on line 293
}
frag_from0 = buffer0;
frag_left0 = vec_len (buffer0);
while (frag_left0 > 0)
{
while (frag_left0 > 0 && n_left_to_next > 0)
{
u32 i0;
i0 = to_next[0] = frag_from0[0];
frag_from0 += 1;
frag_left0 -= 1;
to_next += 1;
n_left_to_next -= 1;
vlib_get_buffer (vm, i0)->error =
error_node->errors[error0];
vlib_validate_buffer_enqueue_x1 (vm, node, next_index,
to_next, n_left_to_next,
i0, next0);
}
vlib_put_next_frame (vm, node, next_index, n_left_to_next);
vlib_get_next_frame (vm, node, next_index, to_next,
n_left_to_next);
}
vec_reset_length (buffer0);
}
vlib_put_next_frame (vm, node, next_index, n_left_to_next);
I must admit I do not fully understand exactly what this code is doing,
but I am suspicious of the use of 'vec_reset_length' macro. I have
looked at the definition of this and it appears that although this sets
the length of the vector back to zero (if the pointer is non-zero), it
does not release any memory that may have been allocated. Do we not
need a call to 'vec_free' somewhere?
Regards,
Ben.
--
Ben McKeegan
Netservers Limited
01223 446000 ext 8103
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20520): https://lists.fd.io/g/vpp-dev/message/20520
Mute This Topic: https://lists.fd.io/mt/87095064/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] det44 plugin
Hi Filip,
Thank you for providing the patch. To confirm, I have now tested your
patch and it does indeed fix the problem.
Regards,
Ben.
On 02/11/2021 17:46, Filip Varga via lists.fd.io wrote:
Hi Ben,
Thank you for pointing out the issue. Indeed it looks like the node runs just
once. I will provide a patch shortly.
Best regards,
Filip Varga
-Original Message-
From: vpp-dev@lists.fd.io On Behalf Of Ben McKeegan
Sent: Monday, November 1, 2021 7:24 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] det44 plugin
Hello,
I am fairly new to VPP so please bear with me. I am trying to use the
det44 NAT plugin on 21.06 but I am experiencing some difficulties with
running out of ports. It would appear that my det44 sessions are never
removed despite passing the expire time. For example, I have the
following setting:
show det44 timeout
udp timeout: 300sec
tcp established timeout: 7440sec
tcp transitory timeout: 240sec
icmp timeout: 60sec
However, if I generate a series of ICMP pings from my test host and then run 'show
det44 sessions' I have a session listed for every individual ping packet, as
expected, but these remain long after the 60 second timeout configured. For example
on my last test I sent a flood of 100 pings which generated 100 sessions in the
lists, all "state: icmp-active
expire" with expiry times ranging from 171 to 173. I have just sent
another 100 pings and now have another 100 sessions with expiry times ranging
from 2647 to 2650, and the original 100 sessions are still there still with
expiry times from 171 to 173 so these have not been refreshed or expired.
I have taken a look at the source code of the plugin and I can that
det44_create_expire_walk_process() is called from det44_plugin_enable().
This function appears to start a new vlib process with the 'main loop'
function det44_expire_walk_fn().
According to the documentation here
https://docs.fd.io/vpp/21.06/dd/d64/vlib__process__doc_8h.html I understand
these despatch functions should be implemented as a while (1) {} loop that
never ends. However, my reading of the
det44_expire_walk_fn() function code is that it will only perform a single walk
of the det44 data structures before returning to its caller.
Is this a bug in det44_expire_walk_fn(), is the documentation wrong or
am I misreading it? My hypothesis is that det44_expire_walk_fn() runs
just once, when the plugin is first enabled (and the session table is already
empty), and does not get run again thereafter. Therefore, the sessions never
get expired.
Regards,
Ben.
--
Ben McKeegan
Netservers Limited
01223 446000 ext 8103
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20519): https://lists.fd.io/g/vpp-dev/message/20519
Mute This Topic: https://lists.fd.io/mt/86748366/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Struggling with low vector size ( < 5-10) seeking expert advice
Hey, Efficiency increases (a lot) with vector size, so pondering packet rates at low sizes doesn’t make much sense. Looking at vector size, you can tell how loaded VPP is. At your vector size, VPP is slacking off and efficiency is thus low, but it doesn’t matter, because you are not processing enough packets to care (on your particular box). To see real limits, you could increase the packet rate until you start seeing drops, then ease of bit by bit until it’s stable with no drops. You will see vector size being close to or at 255. Note that at these rates, any preemption from OS or other apps will cause packet drops, so it’s best to dedicate cores to VPP exclusively and tune the system for minimum latency. Function of vector size/packet rate is indeed non-linear and I don’t think there is a simple formula to calculate it. Of course don’t forget to do (while under load): clear run show run to see real numbers. HTH, Klement > On 19 Nov 2021, at 02:10, PRANAB DAS wrote: > > Hello all, > > IMHO primary motivation of using VPP as the name suggests is Vector Packet > Processing with the belief that it will maximize i-cache and d-cache hit and > thus will result in much higher pps and throughput than scalar processing. > > Somehow I am finding the application we are running in VPP has very low > vector size < 10 with 40% cpu utilization. Does it mean we are not getting > the benefit of vector processing and we are doing something wrong? In what > conditions, will VPP function poorly meaning instead of vector processing it > ends up doing 2 or 3 packets per graph node - thus as scalar packet > processor? > > Basically the datapath application can be considered as a service chain of 3 > different application datapath services each having a different performance > profile. > > service A --->service B > serviceC > > service A is the fastest, most efficient can do 4Mpps > service B is less can do 2Mpps > service C can do 500Kpps > > service A and service B are running in VPP in different worker threads and > service C (DPDK based) running as another process. > > We scale out service C (add more cpu cores 4 time service B) and service B > has twice the number of VPP worker threads than service A > > Assuming we have 8 cores for service C, 2 VPP workers for service B and 1 for > service A - what kind of vector size do we expect when we try 4Mpps, 2Mpps or > 1Mpps (assuming NIC BW does not matter). > > I am arguing that in VPP performance is not linear, rather it depends on > vector size. Is that true? > Is there any documentation on how to size or tune application > performance/vector size on VPP? > > I really appreciate your help. > > Thank you > > _ Pranab K Das > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20518): https://lists.fd.io/g/vpp-dev/message/20518 Mute This Topic: https://lists.fd.io/mt/87158267/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Reason for removing SUSE packaging support
Hi Laszlo, > Thanks for the feedback. I did the update based on your comments: > https://gerrit.fd.io/r/c/vpp/+/34357 > Can I ask for a review? I did, overall it looks good but see my comments in gerrit. Best ben -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20517): https://lists.fd.io/g/vpp-dev/message/20517 Mute This Topic: https://lists.fd.io/mt/84304700/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP release 21.10.1 artifacts are available on packagecloud.io
Thanks, and great job! Mauro. From: vpp-dev@lists.fd.io on behalf of Andrew Yourtchenko Date: Wednesday, 17 November 2021 at 21:09 To: vpp-dev Subject: [vpp-dev] VPP release 21.10.1 artifacts are available on packagecloud.io Hi all, VPP release 21.10.1 artifacts are available at packagecloud.io/fdio/release. Thanks a lot to Dave Wallace and Vanessa Valderrama for the help! --a -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20516): https://lists.fd.io/g/vpp-dev/message/20516 Mute This Topic: https://lists.fd.io/mt/87128508/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
