Re: [vpp-dev] VPP Hardware Interface Output show Carrier Down
you can use vppctl show log to display more startup meesage. VMXNET3 need load vmxnet3_plugin.so. zhangguangm...@baicells.com From: sunil kumar Date: 2023-02-17 21:46 To: vpp-dev Subject: [vpp-dev] VPP Hardware Interface Output show Carrier Down Hi, We are observing the state of the vpp interface as carrier down in command vppctl show hardware output. This is observed while starting the vpp: vppctl show hardware output: == device_c/0/0 2down device_c/0/0 Link speed: 10 Gbps Ethernet address 00:50:56:01:5c:63 VMware VMXNET3 carrier down flags: admin-up pmd rx-ip4-cksum rx: queues 2 (max 16), desc 4096 (min 128 max 4096 align 1) tx: queues 2 (max 8), desc 4096 (min 512 max 4096 align 1) pci: device 15ad:07b0 subsystem 15ad:07b0 address :0c:00.00 numa 0 max rx packet len: 16384 promiscuous: unicast off all-multicast off vlan offload: strip off filter off qinq off rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro vlan-filter jumbo-frame scatter rx offload active: ipv4-cksum tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum tcp-tso multi-segs tx offload active: multi-segs rss avail: ipv4-tcp ipv4 ipv6-tcp ipv6 rss active:none tx burst function: vmxnet3_xmit_pkts rx burst function: vmxnet3_recv_pkts Errors: rte_eth_dev_start[port:1, errno:-22]: Unknown error -22 We are suspecting the following reasons: 1) Any issue with vfio-pci driver while unloading and loading again? 2) Any corruption is happening during initialization? I am attaching the startup.conf and vppctl command output files with this mail: Can anybody suggest a way to resolve this issue? Thanks, Sunil Kumar -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22598): https://lists.fd.io/g/vpp-dev/message/22598 Mute This Topic: https://lists.fd.io/mt/97027473/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] One question about fast path ipv4 inbound
Hi, Piotr
The follow is example fixed code.
ipsec_fp_get_policy_5tuple (ipsec_policy_t *policy, ipsec_fp_5tuple_t *tuple,
bool inbound)
{
memset (tuple, 0, sizeof (*tuple));
tuple->is_ipv6 = policy->is_ipv6;
if (tuple->is_ipv6)
{
tuple->ip6_laddr = policy->laddr.start.ip6;
tuple->ip6_raddr = policy->raddr.start.ip6;
}
else
{
tuple->laddr = policy->laddr.start.ip4;
tuple->raddr = policy->raddr.start.ip4;
}
if (inbound)
{
if ((policy->type == IPSEC_SPD_POLICY_IP4_INBOUND_PROTECT ||
policy->type == IPSEC_SPD_POLICY_IP6_INBOUND_PROTECT) &&
policy->sa_index != INDEX_INVALID)
{
ipsec_sa_t *s = ipsec_sa_get (policy->sa_index);
tuple->spi = s->spi;
if (ipsec_sa_is_set_IS_TUNNEL (s))
{
if (tuple->is_ipv6)
{
tuple->ip6_laddr = s->tunnel.t_src.ip.ip6;
tuple->ip6_raddr = s->tunnel.t_dst.ip.ip6;
}
else
{
tuple->laddr = s->tunnel.t_src.ip.ip4;
tuple->raddr = s->tunnel.t_dst.ip.ip4;
}
}
}
else
tuple->spi = INDEX_INVALID;
Guangming
zhangguangm...@baicells.com
From: Bronowski, PiotrX
Date: 2023-02-13 05:13
To: zhang, Guangming; vpp-dev
Subject: RE: One question about fast path ipv4 inbound
Hi Guangming
I am not sure if I understand your question. There was a bug, in implementation
of fast path for inbound traffic, where I’ve messed up translation of src and
dst to the local and remote address, but it has been fixed with
commit 1d9780a43fe54a55c7540f3528b8703ede0a5871
Author: Piotr Bronowski piotrx.bronow...@intel.com
Date: Fri Oct 21 15:48:55 2022 +
BR,
Piotr
From: zhangguangm...@baicells.com
Sent: Saturday, February 11, 2023 11:04 AM
To: Bronowski, PiotrX ; vpp-dev
Subject: One question about fast path ipv4 inbound
Hi Piotr,
I found you work on the ipsec policy mode optiimization, introduced a
fast path about ipsec policy match .
In the fast path ipv4 inbound , add item into hash, you used traffic
selector src and dst address, but search item from hash
you used esp packetr src and dst address( tunne out header address). Is this
is bug or you have some speical code that i did not find
Thansk
Guangming
zhangguangm...@baicells.com
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22581): https://lists.fd.io/g/vpp-dev/message/22581
Mute This Topic: https://lists.fd.io/mt/96894359/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] One question about fast path ipv4 inbound
Hi, Piotr My question is that the src and dst entry in fp_5tuple in function ipsec_fp_ip4_add_policy are diffrent from src and dst entry in fp_5tuple in function ipsec4_input_node. So inboud match will be not match failed. You see in IKE code kernel_vpp_ipsec.c , the mp->entry.local_address and mp->entry.remote_address are got from traffic selector address, not ipsec tunnmel local and remote address. So in VPP code ,vl_api_ipsec_spd_entry_add_del_t_handler-> ipsec_add_del_policy -> ipsec_fp_add_del_policy, all src and dst address in ipsec_policy_t is traffic selector address (ipsec tunnnel inner address) In ipsec4_input_node, the src and dst in ipsec_fp_in_5tuple_from_ip4_range are the ipsec tunmle local and remore adddress(ipsec tunnel out header address). This is right for ipsec outbound direction , but for inbound direction, add policy into fpd table shoud use ipsec tunnel src and dst address not use traffic selector address . Guangming zhangguangm...@baicells.com From: Bronowski, PiotrX Date: 2023-02-13 05:13 To: zhang, Guangming; vpp-dev Subject: Re: [vpp-dev] One question about fast path ipv4 inbound Hi Guangming I am not sure if I understand your question. There was a bug, in implementation of fast path for inbound traffic, where I’ve messed up translation of src and dst to the local and remote address, but it has been fixed with commit 1d9780a43fe54a55c7540f3528b8703ede0a5871 Author: Piotr Bronowski piotrx.bronow...@intel.com Date: Fri Oct 21 15:48:55 2022 + BR, Piotr From: zhangguangm...@baicells.com Sent: Saturday, February 11, 2023 11:04 AM To: Bronowski, PiotrX ; vpp-dev Subject: One question about fast path ipv4 inbound Hi Piotr, I found you work on the ipsec policy mode optiimization, introduced a fast path about ipsec policy match . In the fast path ipv4 inbound , add item into hash, you used traffic selector src and dst address, but search item from hash you used esp packetr src and dst address( tunne out header address). Is this is bug or you have some speical code that i did not find Thansk Guangming zhangguangm...@baicells.com -- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22580): https://lists.fd.io/g/vpp-dev/message/22580 Mute This Topic: https://lists.fd.io/mt/96894359/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] One question about fast path ipv4 inbound
Hi Piotr, I found you work on the ipsec policy mode optiimization, introduced a fast path about ipsec policy match . In the fast path ipv4 inbound , add item into hash, you used traffic selector src and dst address, but search item from hash you used esp packetr src and dst address( tunne out header address). Is this is bug or you have some speical code that i did not find Thansk Guangming zhangguangm...@baicells.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22578): https://lists.fd.io/g/vpp-dev/message/22578 Mute This Topic: https://lists.fd.io/mt/96894359/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] sigsegv and its handler
Hi ， Stanislav Zaikin May be memroy overwrite issue, especial vlib buffer. Becasue VPP use vector packet processing, not scalar packet processing, so you can see a unexpected nodes even if not a stack corrupted . You can use debug version with CLIB_DEBUG>0 to location the root cause. zhangguangm...@baicells.com From: Stanislav Zaikine Date: 2023-02-01 19:17 To: vpp-dev Subject: [vpp-dev] sigsegv and its handler Hello folks, I've been experiencing rare crashes (one crash in 3 months or so), it looks like the heap is corrupted somehow. Sometimes, the trace shows very unexpected nodes (like ip6-map-t although I don't configure any ipv6 map) or sometimes it's just a crash inside ip4-rewrite-node. After a look I found that last 2 crashes occured in the same way: 1. vnet_feature_arc_start_w_cfg_index or vnet_feature_arc_start call 2. vnet_get_config_data call But then VPP received and handled a SIGSEGV signal. It completely broke the stack trace in the core dump (for the corresponding worker): #0 0x7f44fa0812c6 in __GI_epoll_pwait (epfd=8, events=0x7f44babe52d8, maxevents=, timeout=9, set=0x7f44fa5c66f8 ) at ../sysdeps/unix/sysv/linux/epoll_pwait.c:42 #1 0x00089f6fab2b in ?? () #2 0x7f44babe52d8 in ?? () #3 0x00090100 in ?? () #4 0x7f44fa5c66f8 in _vlib_init_function_init_linux_epoll_input_init () from /lib/x86_64-linux-gnu/libvlib.so.22.10.0 #5 0x in ?? () So, I can't analyze the core dump. Any ideas on how to catch this crash correctly? Disable receiving SIGSEGV? Or is there a way to restore the original stack trace of the worker? For the reference, stack traces from syslog: vnet[2856086]: received signal SIGSEGV, PC 0x7f44b76dbee3, faulting address 0xb0040114 vnet[2856086]: #0 0x7f44fa43885b 0x7f44fa43885b (unix_signal_handler+379) vnet[2856086]: #1 0x7f44fa34f3c0 0x7f44fa34f3c0 (__funlockfile) vnet[2856086]: #2 0x7f44b76dbee3 0x7f44b76dbee3 (ip6_map_t+675) vnet[2856086]: #3 0x7f44fa3c86fb vlib_worker_loop + 0x1b3b vnet[2856086]: #4 0x7f44fa41aafa vlib_worker_thread_fn + 0xaa vnet[2856086]: #5 0x7f44fa414e01 vlib_worker_thread_bootstrap_fn + 0x51 vnet[2856086]: #6 0x7f44fa343609 start_thread + 0xd9 vnet[2856086]: #7 0x7f44fa081163 clone + 0x43 vnet[944491]: received signal SIGSEGV, PC 0x7faf922ca6ae, faulting address 0x7fb3519530fc vnet[944491]: #0 0x7faf9102785b 0x7faf9102785b vnet[944491]: #1 0x7faf90f3e3c0 0x7faf90f3e3c0 vnet[944491]: #2 0x7faf922ca6ae ip4_rewrite_node_fn_skx + 0x149e vnet[944491]: #3 0x7faf90fb76fb vlib_worker_loop + 0x1b3b vnet[944491]: #4 0x7faf91009afa vlib_worker_thread_fn + 0xaa vnet[944491]: #5 0x7faf91003e01 vlib_worker_thread_bootstrap_fn + 0x51 vnet[944491]: #6 0x7faf90f32609 start_thread + 0xd9 vnet[944491]: #7 0x7faf90c70163 clone + 0x43 Line information: Line 135 of "/home/runner/work/vpp/vpp/src/vnet/config.h" starts at address 0x7f44b76dbee3 and ends at 0x7f44b76dbee7 . Line 135 of "/home/runner/work/vpp/vpp/src/vnet/config.h" starts at address 0x7f44fb6db6ae and ends at 0x7f44fb6db6b1 . -- Best regards Stanislav Zaikin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22532): https://lists.fd.io/g/vpp-dev/message/22532 Mute This Topic: https://lists.fd.io/mt/96673497/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] The tap one tx vring used buffer is full
Hi I used interface tap v2 as chanel between vpp and linux kernel. On some unkown conditions, I found one tx ring dose not work. The cause is the tx vring buff is full, desc_in_use is equal to qsz . I do not know the trigger, maybe the kick message was missed or the other errror . But from linux kernel code, there are some comment for VRING_USED_F_NO_NOTIFY. For system robust, is the method that kick off unconditionally when buffer is full reasonable? /* The Host uses this in used->flags to advise the Guest: don't kick me when * you add a buffer. It's unreliable, so it's simply an optimization. Guest * will still kick if it's out of buffers. */ #define VRING_USED_F_NO_NOTIFY 1 The current code , check VRING_USED_F_NO_NOTIFY if ((clib_atomic_load_seq_cst (>used->flags) & VRING_USED_F_NO_NOTIFY) == 0) virtio_kick (vm, vring, vif); The error output : Virtqueue (TX) 7 qsz 4096, last_used_idx 13961, desc_next 1674, desc_in_use 1 avail.flags 0x1 avail.idx 13962 used.flags 0x0 used.idx 13962 kickfd 96, callfd -1 Virtqueue (TX) 9 qsz 4096, last_used_idx 57889, desc_next 545, desc_in_use 4096 avail.flags 0x1 avail.idx 61985 used.flags 0x1 used.idx 57889 kickfd 99, callfd -1 Virtqueue (TX) 11 qsz 4096, last_used_idx 39776, desc_next 2913, desc_in_use 1 avail.flags 0x1 avail.idx 39777 used.flags 0x0 used.idx 39777 kickfd 102, callfd -1 zhangguangm...@baicells.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22486): https://lists.fd.io/g/vpp-dev/message/22486 Mute This Topic: https://lists.fd.io/mt/96396067/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP - 'No debugging symbols found in /usr/lib/vpp plugins/dpdk plugin.so'
Hi ,Gábor Not debug version, but i have installed vpp-debuginfo.x86_64.rpm, my os is centos The rte_eth_tx_prepare in frame 6 is in file dpdk_plugin.so, the diffrence is that rte_eth_tx_prepare is in VPP, the i40e_xmit_pkts is in dpdk . Maybe the dpdk static lib has no symbols. I did not find how to rebuild dpdk static lib with symbol in VPP project. Thanks Guangming zhangguangm...@baicells.com From: Gabor LENCSE Date: 2022-11-29 09:28 To: vpp-dev Subject: Re: [vpp-dev] VPP - 'No debugging symbols found in /usr/lib/vpp plugins/dpdk plugin.so' Hi Guangming, Do you use the debug version of the plugins, too? Gábor On 11/29/2022 10:11 AM, Guangming wrote: Hi , Ben Do you know how to let gdb to show the dpdk file number ? In frame 5 , i can only see the address and assembly code that the vpp-dbg package was already installed. how to show the src code file and line number #0 0x7f2e0a1ac387 in raise () from /lib64/libc.so.6 #1 0x7f2e0a1ada78 in abort () from /lib64/libc.so.6 be#3 0x7f2e0c297ac7 in unix_signal_handler (signurm=7, si=, uc=) at /usr/src/debug/vpp-1.0.0/src/vlib/unix/main.c:187 #4 #5 0x7f2d05cb06fb in i40e_xmit_pkts () from /usr/lib/vpp_plugins/dpdk_plugin.so #6 0x7f2d0619f69a in rte_eth_tx_prepare (nb_pkts=, tx_pkts=, queue_id=, port_id=) at /usr/src/debug/vpp-1.0.0/src/plugins/dpdk/device/device.c:170 #7 tx_burst_vector_internal (n_left=, mb=, xd=0x7f2d, vm=) at /usr/src/debug/vpp-1.0.0/src/plugins/dpdk/device/device.c:179 #8 dpdk_device_class_tx_fn_skx () at /usr/src/debug/vpp-1.0.0/src/plugins/dpdk/device/device.c:453 #9 0x7f2e0c243a15 in dispatch_pending_node (vm=, pending_frame_index=, last_time_stamp=) at /usr/src/debug/vpp-1.0.0/src/vlib/main.c:1024 #10 0x7f2e0c2454ff in vlib_worker_loop (vm=vm@entry=0x7f2d0edc1fc0) Thanks Guangming zhangguangm...@baicells.com From: Benoit Ganne (bganne) via lists.fd.io Date: 2022-11-28 21:18 To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] VPP - 'No debugging symbols found in /usr/lib/vpp plugins/dpdk plugin.so' Did you installed vpp from packages? If so, you'll need the vpp-dbg package. Best ben > -Original Message- > From: vpp-dev@lists.fd.io On Behalf Of Venkataraju, > Raghu via lists.fd.io > Sent: Monday, November 28, 2022 14:03 > To: vpp-dev@lists.fd.io > Subject: [vpp-dev] VPP - 'No debugging symbols found in /usr/lib/vpp > plugins/dpdk plugin.so' > > Hi, > > > In FDIO vpp 21.01, while testing TCP traffic observing a seg fault > resulting in vpp abort. Generated the core dump and ran gdb on it. > bt was pointing to 'dpdk_plugin' in vpp > > $ gdb vpp > > warning: Unable to find matching inferior's thread library, thread > debugging will not be available. > Core was generated by `vpp -c /etc/vpp/startup.conf'. > Program terminated with signal SIGABRT, Aborted.#0 0x007faf663280 in > raise () from /lib/libc.so.6 > [Current thread is 1 (LWP 383)] > > > (gdb) bt > #0 0x007faf663280 in raise () from /lib/libc.so.6 > #1 0x007faf652dcc in abort () from /lib/libc.so.6 > #2 0x005573b84124 in os_exit () > #3 0x007faf8b7ed0 in ?? () from /usr/lib/libvlib.so.21.01.1 > #4 > #5 0x007faf663280 in raise () from /lib/libc.so.6 > #6 0x007faf652dcc in abort () from /lib/libc.so.6 > #7 0x007fa97df8b4 in __rte_panic () from > /usr/lib/vpp_plugins/dpdk_plugin.so > #8 0x007fa9960b58 in ?? () from /usr/lib/vpp_plugins/dpdk_plugin.so > #9 0x007fa99599b8 in ?? () from /usr/lib/vpp_plugins/dpdk_plugin.so > #10 0x007fa99463f4 in ?? () from /usr/lib/vpp_plugins/dpdk_plugin.so > #11 0x007faf7e4224 in ?? () from /lib/libpthread.so.0 > #12 0x007faf6e5d1c in ?? () from /lib/libc.so.6 > > (gdb) file /usr/lib/vpp_plugins/dpdk_plugin.so > warning: core file may not match specified executable file. > Reading symbols from /usr/lib/vpp_plugins/dpdk_plugin.so...(No debugging > symbols found in /usr/lib/vpp_plugins/dpdk_plugin.so) > warning: File "/lib/libthread_db-1.0.so" auto-loading has been declined by > your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > warning: Unable to find libthread_db matching inferior's thread library, > thread debugging will not be available. > > > From bt, function name not displayed for dpdk_plugin because of 'No > debugging symbols found in /usr/lib/vpp_plugins/dpdk_plugin.so' > We had built the dpdk_plugin in debug mode with -g option. But still we > are getting above warning. > > In FDIO vpp 21.01 version, can dpdk_plugin be built with debug symbols ? > Any flag or additional code changes needed ? > > > > Can you please help on this regard. > > Regards, > Raghu > This message contains information that may be privilege
Re: [vpp-dev] VPP - 'No debugging symbols found in /usr/lib/vpp plugins/dpdk plugin.so'
Hi , Ben Do you know how to let gdb to show the dpdk file number ? In frame 5 , i can only see the address and assembly code that the vpp-dbg package was already installed. how to show the src code file and line number #0 0x7f2e0a1ac387 in raise () from /lib64/libc.so.6 #1 0x7f2e0a1ada78 in abort () from /lib64/libc.so.6 be#3 0x7f2e0c297ac7 in unix_signal_handler (signurm=7, si=, uc=) at /usr/src/debug/vpp-1.0.0/src/vlib/unix/main.c:187 #4 #5 0x7f2d05cb06fb in i40e_xmit_pkts () from /usr/lib/vpp_plugins/dpdk_plugin.so #6 0x7f2d0619f69a in rte_eth_tx_prepare (nb_pkts=, tx_pkts=, queue_id=, port_id=) at /usr/src/debug/vpp-1.0.0/src/plugins/dpdk/device/device.c:170 #7 tx_burst_vector_internal (n_left=, mb=, xd=0x7f2d, vm=) at /usr/src/debug/vpp-1.0.0/src/plugins/dpdk/device/device.c:179 #8 dpdk_device_class_tx_fn_skx () at /usr/src/debug/vpp-1.0.0/src/plugins/dpdk/device/device.c:453 #9 0x7f2e0c243a15 in dispatch_pending_node (vm=, pending_frame_index=, last_time_stamp=) at /usr/src/debug/vpp-1.0.0/src/vlib/main.c:1024 #10 0x7f2e0c2454ff in vlib_worker_loop (vm=vm@entry=0x7f2d0edc1fc0) Thanks Guangming zhangguangm...@baicells.com From: Benoit Ganne (bganne) via lists.fd.io Date: 2022-11-28 21:18 To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] VPP - 'No debugging symbols found in /usr/lib/vpp plugins/dpdk plugin.so' Did you installed vpp from packages? If so, you'll need the vpp-dbg package. Best ben > -Original Message- > From: vpp-dev@lists.fd.io On Behalf Of Venkataraju, > Raghu via lists.fd.io > Sent: Monday, November 28, 2022 14:03 > To: vpp-dev@lists.fd.io > Subject: [vpp-dev] VPP - 'No debugging symbols found in /usr/lib/vpp > plugins/dpdk plugin.so' > > Hi, > > > In FDIO vpp 21.01, while testing TCP traffic observing a seg fault > resulting in vpp abort. Generated the core dump and ran gdb on it. > bt was pointing to 'dpdk_plugin' in vpp > > $ gdb vpp > > warning: Unable to find matching inferior's thread library, thread > debugging will not be available. > Core was generated by `vpp -c /etc/vpp/startup.conf'. > Program terminated with signal SIGABRT, Aborted.#0 0x007faf663280 in > raise () from /lib/libc.so.6 > [Current thread is 1 (LWP 383)] > > > (gdb) bt > #0 0x007faf663280 in raise () from /lib/libc.so.6 > #1 0x007faf652dcc in abort () from /lib/libc.so.6 > #2 0x005573b84124 in os_exit () > #3 0x007faf8b7ed0 in ?? () from /usr/lib/libvlib.so.21.01.1 > #4 > #5 0x007faf663280 in raise () from /lib/libc.so.6 > #6 0x007faf652dcc in abort () from /lib/libc.so.6 > #7 0x007fa97df8b4 in __rte_panic () from > /usr/lib/vpp_plugins/dpdk_plugin.so > #8 0x007fa9960b58 in ?? () from /usr/lib/vpp_plugins/dpdk_plugin.so > #9 0x007fa99599b8 in ?? () from /usr/lib/vpp_plugins/dpdk_plugin.so > #10 0x007fa99463f4 in ?? () from /usr/lib/vpp_plugins/dpdk_plugin.so > #11 0x007faf7e4224 in ?? () from /lib/libpthread.so.0 > #12 0x007faf6e5d1c in ?? () from /lib/libc.so.6 > > (gdb) file /usr/lib/vpp_plugins/dpdk_plugin.so > warning: core file may not match specified executable file. > Reading symbols from /usr/lib/vpp_plugins/dpdk_plugin.so...(No debugging > symbols found in /usr/lib/vpp_plugins/dpdk_plugin.so) > warning: File "/lib/libthread_db-1.0.so" auto-loading has been declined by > your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". > warning: Unable to find libthread_db matching inferior's thread library, > thread debugging will not be available. > > > From bt, function name not displayed for dpdk_plugin because of 'No > debugging symbols found in /usr/lib/vpp_plugins/dpdk_plugin.so' > We had built the dpdk_plugin in debug mode with -g option. But still we > are getting above warning. > > In FDIO vpp 21.01 version, can dpdk_plugin be built with debug symbols ? > Any flag or additional code changes needed ? > > > > Can you please help on this regard. > > Regards, > Raghu > This message contains information that may be privileged or confidential > and is the property of the Capgemini Group. It is intended only for the > person to whom it is addressed. If you are not the intended recipient, you > are not authorized to read, print, retain, copy, disseminate, distribute, > or use this message or any part thereof. If you receive this message in > error, please notify the sender immediately and delete all copies of this > message. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22248): https://lists.fd.io/g/vpp-dev/message/22248 Mute This Topic: https://lists.fd.io/mt/95309032/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] "tx frame not ready " error in host-vpp1out tx
Hi Mohsin I have find the root cause of this issue. VPP send a huge malform packet to linux kernel, the memcpy in VNET_DEVICE_CLASS_TX_FN (af_packet_device_class) overwrite the tx_ring Thanks Guangming zhangguangm...@baicells.com From: Mohsin Kazmi via lists.fd.io Date: 2022-11-21 19:00 To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] "tx frame not ready " error in host-vpp1out tx Hi Guangming, What is the VPP version are you using? -br Mohsin From: on behalf of Guangming Reply-To: "vpp-dev@lists.fd.io" Date: Tuesday, November 8, 2022 at 8:01 AM To: "Mohsin Kazmi (sykazmi)" , vpp-dev Subject: [vpp-dev] "tx frame not ready " error in host-vpp1out tx Hi,Mohsin I used linux veth pari interface as af-packet interfeace in vpp. When the vpp run for some time, there are many "tx frame not ready " error in host-vpp1out-tx. If there is error, we can not ping from linux side to vpp side. Must need restart vpp to restore. From old mail. you say "tx frame not ready" means VPP didn't find empty queue at linux side. But in my envirment ,the trafiic is not big .Could give me some clues? vvp# monitor interface host-vpp1out interval 1 count 10 rx: 34.74Kpps 294.82Mbps tx: 17.68Kpps 32.39Mbps rx: 42.78Kpps 372.72Mbps tx: 19.97Kpps 37.45Mbps rx: 38.29Kpps 322.97Mbps tx: 18.50Kpps 33.34Mbps rx: 33.73Kpps 273.07Mbps tx: 16.19Kpps 35.59Mbps rx: 37.39Kpps 317.19Mbps tx: 15.38Kpps 33.30Mbps rx: 33.81Kpps 274.42Mbps tx: 16.21Kpps 34.01Mbps rx: 39.40Kpps 339.30Mbps tx: 16.12Kpps 33.15Mbps rx: 37.98Kpps 330.83Mbps tx: 15.55Kpps 31.44Mbps rx: 39.59Kpps 340.14Mbps tx: 16.37Kpps 36.92Mbps rx: 39.44Kpps 340.84Mbps tx: 15.48Kpps 35.64Mbps linux side vpp1host: flags=4163 mtu 1600 inet 10.155.32.76 netmask 255.0.0.0 broadcast 10.255.255.255 ether e2:27:5e:cb:38:6b txqueuelen 1000 (Ethernet) RX packets 375729479 bytes 105801826082 (98.5 GiB) RX errors 0 dropped 21875 overruns 0 frame 0 TX packets 829224788 bytes 867242223136 (807.6 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vpp1out: flags=4163 mtu 1600 ether 2e:1d:20:a2:bd:9c txqueuelen 1000 (Ethernet) RX packets 829224804 bytes 867242242079 (807.6 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 375729488 bytes 105801827209 (98.5 GiB) TX errors 0 dropped 10937 overruns 0 carrier 0 collisions 0 VPP side vpp# show interface addr TenGigabitEthernet19/0/0 (up): L3 10.155.32.6/27 TenGigabitEthernet19/0/2 (up): L3 10.155.32.68/29 host-vpp1out (up): L3 10.155.32.75/29 local0 (dn): host-vpp1out 3 up host-vpp1out Link speed: unknown RX Queues: queue thread mode 0 vpp_wk_0 (1) interrupt Ethernet address 02:fe:06:f0:ef:d6 Linux PACKET socket interface block:10485760 frame:10240 next frame:867 available:0 request:0 sending:0 wrong:1024 total:1024 Thanks Guangming zhangguangm...@baicells.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22212): https://lists.fd.io/g/vpp-dev/message/22212 Mute This Topic: https://lists.fd.io/mt/94886139/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] There is bug in esp decrypt
I got the same issue when use cli "ipsec sa del id" delete sa that was used by esp encrypt/decrypt zhangguangm...@baicells.com From: jiangxiaoming Date: 2022-11-18 19:13 To: vpp-dev Subject: Re: [vpp-dev] There is bug in esp decrypt Hi neale, The function ipsec_sa_get call in esp_encrypt_inline/esp_decrypt_inline has mem issue. In ipsec4-input-feature node, vnet_buffer (b[0])->ipsec.sad_index was setted by sa, but the sa maybe freed by main thread just after the node dispatch finish, the next dispatch loop the sa referenced by vnet_buffer (b[0])->ipsec.sad_index become invalid and will cause memory issue in esp_encrypt_inline. esp_decrypt/ah_encrypt/ah_decrpty all have same issue. Below is the crash stack I got: 2: /root/code/net-base/.vpp-22.02/src/vnet/ipsec/ipsec_sa.h:649 (ipsec_sa_get) assertion `! pool_is_free (ipsec_sa_pool, _e)' fails Program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffa38472700 (LWP 4067)] 0x735c11f7 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7.x86_64 libgcc-4.8.5-16.el7.x86_64 libpcap-1.5.3-12.el7.x86_64 libstdc++-4.8.5-16.el7.x86_64 libuuid-2.23.2-43.el7.x86_64 (gdb) (gdb) bt #0 0x735c11f7 in raise () from /lib64/libc.so.6 #1 0x735c28e8 in abort () from /lib64/libc.so.6 #2 0x0040b31b in os_panic () at /root/code/net-base/.vpp-22.02/src/vpp/vnet/main.c:413 #3 0x73f081ff in debugger () at /root/code/net-base/.vpp-22.02/src/vppinfra/error.c:84 #4 0x73f088d5 in _clib_error (how_to_die=2, function_name=0x0, line_number=0, fmt=0x76a26380 "%s:%d (%s) assertion `%s' fails") at /root/code/net-base/.vpp-22.02/src/vppinfra/error.c:143 #5 0x75767800 in ipsec_sa_get (sa_index=24723) at /root/code/net-base/.vpp-22.02/src/vnet/ipsec/ipsec_sa.h:649 #6 0x7576f6ed in esp_encrypt_inline (vm=0x7ffefb476380, node=0x7ffefc5f5580, frame=0x7fff1cd85c80, lt=VNET_LINK_IP4, is_tun=0, async_next_node=1) at /root/code/net-base/.vpp-22.02/src/vnet/ipsec/esp_encrypt.c:661 #7 0x75773afe in esp4_encrypt_node_fn (vm=0x7ffefb476380, node=0x7ffefc5f5580, from_frame=0x7fff1cd85c80) at /root/code/net-base/.vpp-22.02/src/vnet/ipsec/esp_encrypt.c:1171 #8 0x7fffefc4f3ad in dispatch_pcap_trace (vm=0x7ffefb476380, node=0x7ffefc5f5580, frame=0x7fff1cd85c80) at /root/code/net-base/.vpp-22.02/src/plugins/dispatch-trace/main.c:210 #9 0x7475bb0d in dispatch_node (vm=0x7ffefb476380, node=0x7ffefc5f5580, type=VLIB_NODE_TYPE_INTERNAL, dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fff1cd85c80, last_time_stamp=3114277064272384) at /root/code/net-base/.vpp-22.02/src/vlib/main.c:977 #10 0x7475cf25 in dispatch_pending_node (vm=0x7ffefb476380, pending_frame_index=0, last_time_stamp=3114277064272384) at /root/code/net-base/.vpp-22.02/src/vlib/main.c:1134 #11 0x74760dcc in vlib_main_or_worker_loop (vm=0x7ffefb476380, is_main=0) at /root/code/net-base/.vpp-22.02/src/vlib/main.c:1600 #12 0x74762594 in vlib_worker_loop (vm=0x7ffefb476380) at /root/code/net-base/.vpp-22.02/src/vlib/main.c:1734 #13 0x747b5e68 in vlib_worker_thread_fn (arg=0x7ffef0b822c0) at /root/code/net-base/.vpp-22.02/src/vlib/threads.c:1533 #14 0x73f32790 in clib_calljmp () at /root/code/net-base/.vpp-22.02/src/vppinfra/longjmp.S:123 #15 0x7ffa38471dd0 in ?? () #16 0x747a9820 in vlib_worker_thread_bootstrap_fn (arg=0x7ffef0b822c0) at /root/code/net-base/.vpp-22.02/src/vlib/threads.c:413 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Xiaoming -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22204): https://lists.fd.io/g/vpp-dev/message/22204 Mute This Topic: https://lists.fd.io/mt/95086868/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] There is bug in esp decrypt
Thanks neale Guangming zhangguangm...@baicells.com From: Neale Ranns Date: 2022-11-18 09:32 To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] There is bug in esp decrypt Hi, I’ll push a patch with UT shortly. Many thanks, neale From: vpp-dev@lists.fd.io on behalf of jiangxiaoming via lists.fd.io Date: Friday, 18 November 2022 at 11:58 To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] There is bug in esp decrypt Hi Guangming, You are right, you can push a patch to https://gerrit.fd.io/r , ipsec maintainers will review it Xiaoming -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22198): https://lists.fd.io/g/vpp-dev/message/22198 Mute This Topic: https://lists.fd.io/mt/95086868/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] There is bug in esp decrypt
Thanks ，Xiaoming Can you give me a guide that how to push a patch to community? zhangguangm...@baicells.com From: jiangxiaoming Date: 2022-11-18 08:58 To: vpp-dev Subject: Re: [vpp-dev] There is bug in esp decrypt Hi Guangming, You are right, you can push a patch to https://gerrit.fd.io/r , ipsec maintainers will review it Xiaoming -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22197): https://lists.fd.io/g/vpp-dev/message/22197 Mute This Topic: https://lists.fd.io/mt/95086868/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] There is bug in esp decrypt
Hi， I think there is bug in esp decrypt function. The right parameter should be n_sync like esp encrypt. The current code may be crash in esp_process_ops becasuse bufs is not sync_bufs. the current code: esp_decrypt_prepare_sync_op ( vm, node, ptd, _ops, _ops, op, sa0, payload, len, cpd.icv_sz, cpd.iv_sz, pd, pd2, b[0], sync_next, b - bufs); /* next */ the right code: esp_decrypt_prepare_sync_op ( vm, node, ptd, _ops, _ops, op, sa0, payload, len, cpd.icv_sz, cpd.iv_sz, pd, pd2, b[0], sync_next, n_sync); /* next */ Guangming zhangguangm...@baicells.com e -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22192): https://lists.fd.io/g/vpp-dev/message/22192 Mute This Topic: https://lists.fd.io/mt/95086868/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] "tx frame not ready " error in host-vpp1out tx
Hi,Mohsin I used linux veth pari interface as af-packet interfeace in vpp. When the vpp run for some time, there are many "tx frame not ready " error in host-vpp1out-tx. If there is error, we can not ping from linux side to vpp side. Must need restart vpp to restore. From old mail. you say "tx frame not ready" means VPP didn't find empty queue at linux side. But in my envirment ,the trafiic is not big .Could give me some clues? vvp# monitor interface host-vpp1out interval 1 count 10 rx: 34.74Kpps 294.82Mbps tx: 17.68Kpps 32.39Mbps rx: 42.78Kpps 372.72Mbps tx: 19.97Kpps 37.45Mbps rx: 38.29Kpps 322.97Mbps tx: 18.50Kpps 33.34Mbps rx: 33.73Kpps 273.07Mbps tx: 16.19Kpps 35.59Mbps rx: 37.39Kpps 317.19Mbps tx: 15.38Kpps 33.30Mbps rx: 33.81Kpps 274.42Mbps tx: 16.21Kpps 34.01Mbps rx: 39.40Kpps 339.30Mbps tx: 16.12Kpps 33.15Mbps rx: 37.98Kpps 330.83Mbps tx: 15.55Kpps 31.44Mbps rx: 39.59Kpps 340.14Mbps tx: 16.37Kpps 36.92Mbps rx: 39.44Kpps 340.84Mbps tx: 15.48Kpps 35.64Mbps linux side vpp1host: flags=4163 mtu 1600 inet 10.155.32.76 netmask 255.0.0.0 broadcast 10.255.255.255 ether e2:27:5e:cb:38:6b txqueuelen 1000 (Ethernet) RX packets 375729479 bytes 105801826082 (98.5 GiB) RX errors 0 dropped 21875 overruns 0 frame 0 TX packets 829224788 bytes 867242223136 (807.6 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vpp1out: flags=4163 mtu 1600 ether 2e:1d:20:a2:bd:9c txqueuelen 1000 (Ethernet) RX packets 829224804 bytes 867242242079 (807.6 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 375729488 bytes 105801827209 (98.5 GiB) TX errors 0 dropped 10937 overruns 0 carrier 0 collisions 0 VPP side vpp# show interface addr TenGigabitEthernet19/0/0 (up): L3 10.155.32.6/27 TenGigabitEthernet19/0/2 (up): L3 10.155.32.68/29 host-vpp1out (up): L3 10.155.32.75/29 local0 (dn): host-vpp1out 3 up host-vpp1out Link speed: unknown RX Queues: queue thread mode 0 vpp_wk_0 (1) interrupt Ethernet address 02:fe:06:f0:ef:d6 Linux PACKET socket interface block:10485760 frame:10240 next frame:867 available:0 request:0 sending:0 wrong:1024 total:1024 Thanks Guangming zhangguangm...@baicells.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22150): https://lists.fd.io/g/vpp-dev/message/22150 Mute This Topic: https://lists.fd.io/mt/94886139/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] A question about last used timestamp in ipsec sa
Hi ben
The firtst reason is the SA bytes/packets only show there is some
trafffic that use this sa , we must record and calculation the last time in
IKE processs,
and this is not accurate that based on the poll frequency. This is the major
reason , we want this timestamp is more accurately in DPD.
The second reason is thar our IKE is strongswan , it expect get that last
use time from query_sa or query_policy directly.
Thanks
Gaungming
zhangguangm...@baicells.com
From: Benoit Ganne (bganne) via lists.fd.io
Date: 2022-10-14 14:44
To: vpp-dev@lists.fd.io; neale; radu.nicolau; roy.fan.zhang
Subject: Re: [vpp-dev] A question about last used timestamp in ipsec sa
As you'd have to poll SA timestamp counters anyway to check the timestamp, why
not just poll existing SA bytes/packets counters instead to see if some traffic
is going through?
Best
ben
> -Original Message-
> From: vpp-dev@lists.fd.io On Behalf Of Guangming
> Sent: Friday, October 14, 2022 8:37
> To: neale ; radu.nicolau ;
> roy.fan.zhang
> Cc: vpp-dev
> Subject: [vpp-dev] A question about last used timestamp in ipsec sa
>
>
>
> Hi，Neale , Radu and Fan
> Now the ipsec in VPP did not record the traffic timestamp in sa and
> spd like linux kernel . So we can not Implement the full DPD function In
> IKE control daemon that only send DPD when no traffic .
> What is the good method to add timestamp . This method should be fit to
> both sync node and async mode.
> Use a new timestamp counter or add timestamp in old couter
> ipsec_sa_counters ?
>
> struct xfrm_lifetime_cur {
> __u64 bytes;
> __u64 packets;
> __u64 add_time;
> __u64 use_time;
> };
>
>
> Thanks
> Guangming
>
>
> zhangguangm...@baicells.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22032): https://lists.fd.io/g/vpp-dev/message/22032
Mute This Topic: https://lists.fd.io/mt/94321862/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] A question about last used timestamp in ipsec sa
Hi，Neale , Radu and Fan
Now the ipsec in VPP did not record the traffic timestamp in sa and spd
like linux kernel . So we can not Implement the full DPD function In IKE
control daemon that only send DPD when no traffic .
What is the good method to add timestamp . This method should be fit to both
sync node and async mode.
Use a new timestamp counter or add timestamp in old couter ipsec_sa_counters ?
struct xfrm_lifetime_cur {
__u64 bytes;
__u64 packets;
__u64 add_time;
__u64 use_time;
};
Thanks
Guangming
zhangguangm...@baicells.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22029): https://lists.fd.io/g/vpp-dev/message/22029
Mute This Topic: https://lists.fd.io/mt/94321862/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Questions about no-multi-seg
Hi , ben From a old message, you saidthat set no-multi-seg will get good performance . https://lists.fd.io/g/vpp-dev/message/18489 My question is when i do not neeed Jumbo MTU in my scenario, is set no-multi-seg and no-tx-checksum-offload in startup.conf a good option ? Thanks Guangming zhangguangm...@baicells.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21981): https://lists.fd.io/g/vpp-dev/message/21981 Mute This Topic: https://lists.fd.io/mt/94231354/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] There is bug in patch
I have some idea that is not good
1, spi should be one key in inbound policy serach
typedef union
{
struct
{
ip4_address_t ip4_src_addr;
ip4_address_t ip4_dest_addr;
U32 spi;
ipsec_spd_policy_type_t policy_type;
}; // 16 bytes total
ipsec4_hash_kv_16_8_t kv_16_8;
} ipsec4_inbound_spd_tuple_t;
2, Maybe we do not need a write a unified method to be fit to both inbound
and outbound.
3, We should use another method (Eg: remove on entry) , not reset cache
entry, when add or del one spd.
In roadwarrior scenario , for server , many client attach and detach is
usaual beviour.
Thanks
Guangming
zhangguangm...@baicells.com
From: Benoit Ganne (bganne) via lists.fd.io
Date: 2022-09-28 16:22
To: vpp-dev@lists.fd.io
CC: Zhang, Roy Fan; Bronowski, PiotrX; Lijian Zhang; Honnappa Nagarahalli
Subject: Re: [vpp-dev] There is bug in patch
Looks like it would be a good time to unify slow-path/fastpath and
inbound/outbound policy matching code
Best
ben
> -Original Message-
> From: vpp-dev@lists.fd.io On Behalf Of Zachary Leaf
> Sent: Wednesday, September 28, 2022 10:10
> To: vpp-dev@lists.fd.io
> Cc: Zhang, Roy Fan ; Bronowski, PiotrX
> ; Lijian Zhang ;
> Honnappa Nagarahalli
> Subject: Re: [vpp-dev] There is bug in patch
>
> Copying in Piotr, Fan and some other folks for awareness/any input.
>
> Best,
> Zach
>
> On 28/09/2022 09:07, Zachary Leaf via lists.fd.io wrote:
> > Hi Guangming,
> >
> > Thanks for the report. I think you may have uncovered some of the bugs
> > in the general inbound matching logic.
> >
> > I think there are 2 problems with the logic for the standard linear
> > search (not flow cache, but impacts flow cache):
> > 1. Only matches source/dest ip, and doesn't match source/dest ports
> > or protocol
> > 2. First looks for a match in a vector of all PROTECT policies, then in
> > BYPASS, then finally in DISCARD if nothing matched above
> >
> > In contrast the way I think the matching logic should work is matching a
> > full 5-tuple of {sip/dip, sp/dp, proto} as per outbound side, with all
> > policies searched in one vector so priorities are respected [1].
> >
> > From what you've said I think what may cause your issue is a
> > combination of the 2 above problems, flow cache activation and the
> > particular policy you included:
> >
> > - First packet enters, does not match any PROTECT rules, so searches and
> > matches BYPASS rule for catch all 0.0.0.0-255.255.255.255 /0 range
> > (inbound logic does not check port ranges or protocol)
> > - Now flow cache has an entry for 0.0.0.0-255.255.255.255 that will
> > match every packet in future
> >
> > Obviously the inbound logic is pretty broken, I think it really needs a
> > full re-write to align with outbound side. In hindsight it would have
> > been better to fix all this before adding flow cache but these issues
> > weren't really clear before.
> >
> > As far as fixing your problem, disabling flow cache would work to match
> > the PROTECT policy because of the ordering of the linear search (see 2
> > above), but doesn't fix any of the other possible issues.
> >
> > Otherwise really any 0.0.0.0-255.255.255.255 range is going to mess up
> > and match everything in flow cache if the first packet that enters
> > matches one of these rules.
> >
> > You can try using the new fast path functionality, but from a quick look
> > this also might only be matching sip/dip and not a full 5-tuple so
> > possibly will have the same issue.
> >
> > Best,
> >
> > Zach
> >
> > 1: https://gerrit.fd.io/r/c/vpp/+/34252/3#message-
> 958bacb4654a030e835502af5e486f614c5a1433
> >
> >
> >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21941): https://lists.fd.io/g/vpp-dev/message/21941
Mute This Topic: https://lists.fd.io/mt/93942743/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] There is bug in patch
Hi, Zach I think there is a bug in patch : perf improvement of ipsec4_input_node using flow cache (https://gerrit.fd.io/r/c/vpp/+/32903). Based on current code , multiple spd rules were created that include some bypass or discard rule . When one ESP packet was received , we expect it match the protect rule, but it is possible that will match the bypass or discard rule by flow cache . For exampl, on NAT-T scene, there is a bypass rule that need forward the IKE packet to IKE daemon , the data packet EPS over UDP that will match this rule. [8] priority 2147483647 action bypass type ip4-inbound-bypass protocol UDP local addr range 0.0.0.0 - 255.255.255.255 port range 4500 - 4500 remote addr range 0.0.0.0 - 255.255.255.255 port range 0 - 65535 packets 0 bytes 0 Thanks Guangming zhangguangm...@baicells.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21931): https://lists.fd.io/g/vpp-dev/message/21931 Mute This Topic: https://lists.fd.io/mt/93942743/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] The position of ipsec4-output-feature in the arc ip4-output
Hi All, When I test VPP ipsec with version 2110, I found the node ipsec4-output-feature is the last node in ARC ip4-output. So when use SPD in ipsec. if there is big packet that was fragment when output . When the fragment packet was input ipsec4-output-feature node. the other packet expect the first fragment packet will not match SPD policy ,so the packet was droped. 00:12:05:665867: ip4-lookup fib 0 dpo-idx 7 flow hash: 0x UDP: 10.10.10.15 -> 10.10.10.2 tos 0x00, ttl 128, length 1548, checksum 0x0cbd dscp CS0 ecn NON_ECN fragment id 0x UDP: 500 -> 500 length 1528, checksum 0x94f4 00:12:05:665868: ip4-rewrite tx_sw_if_index 0 dpo-idx 7 : ipv4 via 10.10.10.2 GigabitEthernet0/13/0: mtu:1500 next:4 flags:[features ] ee9d5c8281695e0001010800 flow hash: 0x05dc : 4500060c80110cbd0a0a0a0f0a0a0a0201f401f405f894f43eb4a54c 0020: 65ce89de80feb8853ee4fe402e20232105f0240005d4 00:12:05:665869: ip4-frag IPv4 mtu: 1500 fragments: 2 next: 0 00:12:05:665878: ip4-rewrite tx_sw_if_index 1 dpo-idx 7 : ipv4 via 10.10.10.2 GigabitEthernet0/13/0: mtu:1500 next:4 flags:[features ] ee9d5c8281695e0001010800 flow hash: 0x : ee9d5c8281695e0001010800450005dc060020007f11e7ec0a0a0a0f0a0a 0020: 0a0201f401f405f894f43eb4a54c65ce89de80feb8853ee4fe402e20 tx_sw_if_index 1 dpo-idx 7 : ipv4 via 10.10.10.2 GigabitEthernet0/13/0: mtu:1500 next:4 flags:[features ] ee9d5c8281695e0001010800 flow hash: 0x : ee9d5c8281695e0001010800454406b97f110ccc0a0a0a0f0a0a 0020: 0a02cb4be59b66a472db88e5a88133f298724b594b7624391727117e 00:12:05:665880: ipsec4-output-feature spd 2 policy 17 spd 2 policy -1 00:12:05:665882: error-drop rx:local0 00:12:05:665883: GigabitEthernet0/13/0-output GigabitEthernet0/13/0 IP4: 00:00:5e:00:01:01 -> ee:9d:5c:82:81:69 UDP: 10.10.10.15 -> 10.10.10.2 tos 0x00, ttl 127, length 1500, checksum 0xe7ec dscp CS0 ecn NON_ECN fragment id 0x0600, flags MORE_FRAGMENTS UDP: 500 -> 500 length 1528, checksum 0x94f4 00:12:05:665884: drop ip4-frag: packet fragmented 00:12:05:665884: GigabitEthernet0/13/0-tx GigabitEthernet0/13/0 tx queue 0 buffer 0x91ca7: current data -14, length 1514, buffer-pool 0, ref-count 1, trace handle 0x6 ip4 l3-hdr-offset 0 PKT MBUF: port 65535, nb_segs 1, pkt_len 1514 buf_len 2176, data_len 1514, ol_flags 0x0, data_off 114, phys_addr 0x62272a40 packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 rss 0x0 fdir.hi 0x0 fdir.lo 0x0 IP4: 00:00:5e:00:01:01 -> ee:9d:5c:82:81:69 UDP: 10.10.10.15 -> 10.10.10.2 tos 0x00, ttl 127, length 1500, checksum 0xe7ec dscp CS0 ecn NON_ECN fragment id 0x0600, flags MORE_FRAGMENTS UDP: 500 -> 500 length 1528, checksum 0x94f4 Can we move the node ipsec4-output-feature to the first node in ARC ip4-output ? And any bad effect when move this node position? Thanks Guangming zhangguangm...@baicells.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21642): https://lists.fd.io/g/vpp-dev/message/21642 Mute This Topic: https://lists.fd.io/mt/92328476/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] VPP v22.02 not coming up
Hi,
I have compiled VPP v22.02 on Centos 8.4. I was able to compile it. But when I
installed it and modified /etc/vpp/startup.conf, vpp service is not able to
come up. I added below sections in /etc/vpp/startup.conf:-
dpdk {
socket-mem 1024 dev :00:08.0 dev :00:09.0 dev :00:0a.0 dev
:00:0b.0
}
plugins {
## Adjusting the plugin path depending on where the VPP plugins are
# path /ws/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins
## Disable all plugins by default and then selectively enable specific plugins
# plugin default { disable }
# plugin dpdk_plugin.so { enable }
# plugin acl_plugin.so { enable }
plugin linux_cp_plugin.so { enable }
plugin linux_nl_plugin.so { enable }
## Enable all plugins by default and then selectively disable specific plugins
# plugin dpdk_plugin.so { disable }
# plugin acl_plugin.so { disable }
}
linux-cp {
default netns dataplane
interface-auto-create
}
VPP service log is showing error for the highlighted sections:-
vlib_call_all_config_functions: unknown input `dpdk socket-mem 1024 dev
:00:08.0 dev :00:09.0 '
vlib_call_all_config_functions: unknown input `linux-cp default netns
dataplane interface-auto-create '
I have compiled VPP with all the plugins mentioned above. In
"/usr/lib/vpp_plugins/" I can see .so files i.e dpdk_plugin.so,
linux_cp_plugin.so, linux_nl_plugin.so
Can you please help us if we are missing out something?
Thanks and Regards,
Chinmaya Agarwal.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21448): https://lists.fd.io/g/vpp-dev/message/21448
Mute This Topic: https://lists.fd.io/mt/91312985/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] how to config vrrp unicast mode
ttl 64, id 18089, offset 0, flags [DF], proto ICMP (1), length 84) 10.10.10.15 > 10.10.10.2: ICMP echo reply, id 2107, seq 2180, length 64 zhangguangm...@baicells.com From: Matthew Smith via lists.fd.io Date: 2022-01-11 01:22 To: Guangming CC: vpp-dev Subject: Re: [vpp-dev] how to config vrrp unicast mode Hi Guangming, I merged https://gerrit.fd.io/r/c/vpp/+/34768. It allows the virtual address to be added when accept mode is enabled on a VR which sends unicast advertisements. Thanks, -Matt On Mon, Jan 3, 2022 at 10:07 PM Guangming wrote: Hi,Matt Thanks for your detail reply. Maybe I was wrong about VRRP in VPP. My expected behavior is that the master and backup have a virtual ip and virtual mac. The virtual ip and mac are used to connected with the other device. They are removed when device switch to backup and are added when switch to master. Or they are always exist on the two device, but only the mater device can send and recieve the packet which destination ip address is the virtual ip. The reason is i want to use unicast is remote disaster recovey scenario , not only cloud. The other is reduce the multicast packet in LAN. From the code , I think the device may drop the packet which dst address is virtual, because the virtual ip is not the second address of the interface with your proposal configure. My vpp version is 2110.1 Now my test environment is not ready because our lab is removal. I will verify your configure when test environment is ready . I aslo found the other issue about VRRP. One is the source ethenet address in gratuitous ARP is not the virtual MAC, so the the virtaul MAC in switch is unkonwn unicast . The other is the MAC is not same that master device used when it handle the send and recieve packet. One is virtual MAC , the other is real MAC. I think both are virtual mac is more friendly to peer device. Thanks Guangming zhangguangm...@baicells.com From: Matthew Smith Date: 2022-01-04 03:02 To: zhangguangm...@baicells.com CC: vpp-dev Subject: Re: how to config vrrp unicast mode Hi Guangming, I think the signaling between unicast peers should work if you do something like this: device A: set int ip address GigabitEthernet0/14/0 10.10.10.10/24 set int state GigabitEthernet0/14/0 up vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 250 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.5 vrrp proto start GigabitEthernet0/14/0 vr_id 1 device B: set int ip address GigabitEthernet0/14/0 10.10.10.5/24 set int state GigabitEthernet0/14/0 up vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 200 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.10 vrrp proto start GigabitEthernet0/14/0 vr_id 1 That ought to cause your two instances to elect device A as the master. It should send advertisements to device B while it's up. It should also reply to ARP requests for 10.10.10.15 if it receives them, but it will reply with a VRRP virtual MAC address, which may not be the correct behavior for a unicast scenario. I originally added the capability to send unicast advertisements because I thought it may be useful for cloud environments which do not support multicast (AWS, Azure). But replying to an ARP request with a VRRP virtual MAC address may not be valid for cloud environments. Or it might not matter because the ARP request may be handled by infrastructure in those cloud environments and never actually delivered to the VM where VPP runs, I'm not sure. Your original commands enabled accept mode on each VR and added the VR virtual IP address (10.10.10.10/24) on the interface where the VR was being configured. In general, when you use accept mode, you don't need to configure the VR virtual IP address on the interface. You should only configure the virtual IP address on an interface of a VR that has priority 255 (the "owner" of the virtual IP address). On VR's with priority lower than 255, the address will automatically be added when the VR transitions into the master state and removed when it transitions from master to backup. I don't recall whether enabling accept mode does anything if you're using unicast advertisements. As I mentioned, the functionality was intended for cloud environments and in those environments, it does not work to just add an IP address on an interface, there needs to be some outside action taken (use AWS/Azure API to remove address from one host/interface and add it on another). I have not tried to use unicast VRRP in production and I have not received any questions about it from users before, so YMMV. If you find something specific that is not working as expected, please let me know. Thanks, -Matt On Tue, Dec 28, 2021 at 3:37 AM zhangguangm...@baicells.com wrote: Hi Matthew I want to use two device that runing VPP as HA cluster. I found the vrrp cli support unicast mode. Can you give me a right vrrp
Re: [vpp-dev] how to config vrrp unicast mode
Thanks Matt. It is a good method. Based on the old version, i use the command "set int ip address" to add the virtual address when accept mode is enabled and vr is unicast as workaround. Eg: set int ip address GigabitEthernet0/14/0 10.10.10.10/24 set int ip address GigabitEthernet0/14/0 10.10.10.15/24 set int state GigabitEthernet0/14/0 up vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 250 accept_mode 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.5 zhangguangm...@baicells.com From: Matthew Smith via lists.fd.io Date: 2022-01-11 01:22 To: Guangming CC: vpp-dev Subject: Re: [vpp-dev] how to config vrrp unicast mode Hi Guangming, I merged https://gerrit.fd.io/r/c/vpp/+/34768. It allows the virtual address to be added when accept mode is enabled on a VR which sends unicast advertisements. Thanks, -Matt On Mon, Jan 3, 2022 at 10:07 PM Guangming wrote: Hi,Matt Thanks for your detail reply. Maybe I was wrong about VRRP in VPP. My expected behavior is that the master and backup have a virtual ip and virtual mac. The virtual ip and mac are used to connected with the other device. They are removed when device switch to backup and are added when switch to master. Or they are always exist on the two device, but only the mater device can send and recieve the packet which destination ip address is the virtual ip. The reason is i want to use unicast is remote disaster recovey scenario , not only cloud. The other is reduce the multicast packet in LAN. From the code , I think the device may drop the packet which dst address is virtual, because the virtual ip is not the second address of the interface with your proposal configure. My vpp version is 2110.1 Now my test environment is not ready because our lab is removal. I will verify your configure when test environment is ready . I aslo found the other issue about VRRP. One is the source ethenet address in gratuitous ARP is not the virtual MAC, so the the virtaul MAC in switch is unkonwn unicast . The other is the MAC is not same that master device used when it handle the send and recieve packet. One is virtual MAC , the other is real MAC. I think both are virtual mac is more friendly to peer device. Thanks Guangming zhangguangm...@baicells.com From: Matthew Smith Date: 2022-01-04 03:02 To: zhangguangm...@baicells.com CC: vpp-dev Subject: Re: how to config vrrp unicast mode Hi Guangming, I think the signaling between unicast peers should work if you do something like this: device A: set int ip address GigabitEthernet0/14/0 10.10.10.10/24 set int state GigabitEthernet0/14/0 up vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 250 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.5 vrrp proto start GigabitEthernet0/14/0 vr_id 1 device B: set int ip address GigabitEthernet0/14/0 10.10.10.5/24 set int state GigabitEthernet0/14/0 up vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 200 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.10 vrrp proto start GigabitEthernet0/14/0 vr_id 1 That ought to cause your two instances to elect device A as the master. It should send advertisements to device B while it's up. It should also reply to ARP requests for 10.10.10.15 if it receives them, but it will reply with a VRRP virtual MAC address, which may not be the correct behavior for a unicast scenario. I originally added the capability to send unicast advertisements because I thought it may be useful for cloud environments which do not support multicast (AWS, Azure). But replying to an ARP request with a VRRP virtual MAC address may not be valid for cloud environments. Or it might not matter because the ARP request may be handled by infrastructure in those cloud environments and never actually delivered to the VM where VPP runs, I'm not sure. Your original commands enabled accept mode on each VR and added the VR virtual IP address (10.10.10.10/24) on the interface where the VR was being configured. In general, when you use accept mode, you don't need to configure the VR virtual IP address on the interface. You should only configure the virtual IP address on an interface of a VR that has priority 255 (the "owner" of the virtual IP address). On VR's with priority lower than 255, the address will automatically be added when the VR transitions into the master state and removed when it transitions from master to backup. I don't recall whether enabling accept mode does anything if you're using unicast advertisements. As I mentioned, the functionality was intended for cloud environments and in those environments, it does not work to just add an IP address on an interface, there needs to be some outside action taken (use AWS/Azure API to remove address from one host/interface and add it on another). I have not tried to use unicast VRRP in production and I have not rec
Re: [vpp-dev] how to config vrrp unicast mode
Hi,Matt Thanks for your detail reply. Maybe I was wrong about VRRP in VPP. My expected behavior is that the master and backup have a virtual ip and virtual mac. The virtual ip and mac are used to connected with the other device. They are removed when device switch to backup and are added when switch to master. Or they are always exist on the two device, but only the mater device can send and recieve the packet which destination ip address is the virtual ip. The reason is i want to use unicast is remote disaster recovey scenario , not only cloud. The other is reduce the multicast packet in LAN. From the code , I think the device may drop the packet which dst address is virtual, because the virtual ip is not the second address of the interface with your proposal configure. My vpp version is 2110.1 Now my test environment is not ready because our lab is removal. I will verify your configure when test environment is ready . I aslo found the other issue about VRRP. One is the source ethenet address in gratuitous ARP is not the virtual MAC, so the the virtaul MAC in switch is unkonwn unicast . The other is the MAC is not same that master device used when it handle the send and recieve packet. One is virtual MAC , the other is real MAC. I think both are virtual mac is more friendly to peer device. Thanks Guangming zhangguangm...@baicells.com From: Matthew Smith Date: 2022-01-04 03:02 To: zhangguangm...@baicells.com CC: vpp-dev Subject: Re: how to config vrrp unicast mode Hi Guangming, I think the signaling between unicast peers should work if you do something like this: device A: set int ip address GigabitEthernet0/14/0 10.10.10.10/24 set int state GigabitEthernet0/14/0 up vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 250 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.5 vrrp proto start GigabitEthernet0/14/0 vr_id 1 device B: set int ip address GigabitEthernet0/14/0 10.10.10.5/24 set int state GigabitEthernet0/14/0 up vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 200 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.10 vrrp proto start GigabitEthernet0/14/0 vr_id 1 That ought to cause your two instances to elect device A as the master. It should send advertisements to device B while it's up. It should also reply to ARP requests for 10.10.10.15 if it receives them, but it will reply with a VRRP virtual MAC address, which may not be the correct behavior for a unicast scenario. I originally added the capability to send unicast advertisements because I thought it may be useful for cloud environments which do not support multicast (AWS, Azure). But replying to an ARP request with a VRRP virtual MAC address may not be valid for cloud environments. Or it might not matter because the ARP request may be handled by infrastructure in those cloud environments and never actually delivered to the VM where VPP runs, I'm not sure. Your original commands enabled accept mode on each VR and added the VR virtual IP address (10.10.10.10/24) on the interface where the VR was being configured. In general, when you use accept mode, you don't need to configure the VR virtual IP address on the interface. You should only configure the virtual IP address on an interface of a VR that has priority 255 (the "owner" of the virtual IP address). On VR's with priority lower than 255, the address will automatically be added when the VR transitions into the master state and removed when it transitions from master to backup. I don't recall whether enabling accept mode does anything if you're using unicast advertisements. As I mentioned, the functionality was intended for cloud environments and in those environments, it does not work to just add an IP address on an interface, there needs to be some outside action taken (use AWS/Azure API to remove address from one host/interface and add it on another). I have not tried to use unicast VRRP in production and I have not received any questions about it from users before, so YMMV. If you find something specific that is not working as expected, please let me know. Thanks, -Matt On Tue, Dec 28, 2021 at 3:37 AM zhangguangm...@baicells.com wrote: Hi Matthew I want to use two device that runing VPP as HA cluster. I found the vrrp cli support unicast mode. Can you give me a right vrrp unicast example ? My configure is as follow, device A : set int ip address GigabitEthernet0/14/0 10.10.10.10/24 set int ip address GigabitEthernet0/14/0 10.10.10.15/24 set int state GigabitEthernet0/14/0 up vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 250 accept_mode 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.5 vrrp proto start GigabitEthernet0/14/0 vr_id 1 device B: set int ip address GigabitEthernet0/14/0 10.10.10.5/24 set int ip address GigabitEthernet0/14/0 10.10.10.15/24 set int state GigabitEthernet0/14/
[vpp-dev] how to config vrrp unicast mode
Hi Matthew I want to use two device that runing VPP as HA cluster. I found the vrrp cli support unicast mode. Can you give me a right vrrp unicast example ? My configure is as follow, device A : set int ip address GigabitEthernet0/14/0 10.10.10.10/24 set int ip address GigabitEthernet0/14/0 10.10.10.15/24 set int state GigabitEthernet0/14/0 up vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 250 accept_mode 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.5 vrrp proto start GigabitEthernet0/14/0 vr_id 1 device B: set int ip address GigabitEthernet0/14/0 10.10.10.5/24 set int ip address GigabitEthernet0/14/0 10.10.10.15/24 set int state GigabitEthernet0/14/0 up vrrp vr add GigabitEthernet0/14/0 vr_id 1 priority 200 accept_mode 10.10.10.15 unicast vrrp peers GigabitEthernet0/14/0 vr_id 1 10.10.10.10 vrrp proto start GigabitEthernet0/14/0 vr_id 1 Thanks Guangming zhangguangm...@baicells.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#20670): https://lists.fd.io/g/vpp-dev/message/20670 Mute This Topic: https://lists.fd.io/mt/87993023/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] Is there a bug in IKEv2 when enable multithread ?
Thanks ben
With software RSS , the test result is OK.
This should be ixgbevf RSS issue .
zhangguangm...@baicells.com
From: Benoit Ganne (bganne) via lists.fd.io
Date: 2021-11-05 16:15
To: zhangguangm...@baicells.com
CC: vpp-dev
Subject: Re: [vpp-dev] Is there a bug in IKEv2 when enable multithread ?
Here is my take: currently in the ike plugin we expect all related ike packets
to arrive on the same NIC queue. I expect all ike packets to use the same UDP
5-tuple, hence I think this assumption is correct.
If you can share a scenario (in the RFC or even better with an existing ike
implementation) where it is not correct, we should probably reconsider this.
If it is a RSS issue, you should fix it. You can use 'vppctl set interface
handoff' for software RSS as a workaround.
Best
ben
> -Original Message-
> From: zhangguangm...@baicells.com
> Sent: vendredi 5 novembre 2021 02:55
> To: Benoit Ganne (bganne)
> Cc: vpp-dev
> Subject: Re: RE: Is there a bug in IKEv2 when enable multithread ?
>
> Yes, the flow with same source/dest ip and ports was assgin to the
> same nic queue is the expected. But the resust is the init and auth
> packet was assign the same queue, but the informatuon reply (infomation
> request was send by vpp) was
> assigned the other queue.
>
> I also make another test , cpature all the IKEv2 packets and relpay
> the packets those dest address is vpp, all the pakcet was assgined to
> the same queue.
>
> I think there are two cause ,the one is NIC rss is not work , the other
> is IKEv2 code . The firt is most possibility , but the first is not
> able to explain the the second test result .
>
> I have reported the first cause through the Intel $(D"n Premier Support
> site.
> My physical NIC is 82599. The VF(SRIOV ) was use by a VM . The question
> about RSS support ixgbevf
>
> root@gmzhang:~/vpn# ethtool -i enp2s13
> driver: ixgbevf
> version: 4.1.0-k
> firmware-version:
> expansion-rom-version:
> bus-info: :02:0d.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: no
> supports-register-dump: yes
> supports-priv-flags: no
>
>
> Guangming
>
> Thanks
>
>
>
> zhangguangm...@baicells.com
>
>
> From: Benoit Ganne (bganne) <mailto:bga...@cisco.com>
> Date: 2021-11-05 01:12
> To: zhangguangm...@baicells.com <mailto:zhangguangm...@baicells.com>
> CC: vpp-dev <mailto:vpp-dev@lists.fd.io>
> Subject: RE: Is there a bug in IKEv2 when enable multithread ?
> Hi,
>
> Why do you receive those packets on different workers? I would
> expect all the IKE packets to use the same source/dest IP and ports hence
> arriving in the same worker. Is it not the case?
>
> Best
> ben
>
> > -Original Message-
> > From: zhangguangm...@baicells.com
> > Sent: mardi 2 novembre 2021 10:15
> > To: Damjan Marion (damarion) ; Filip Tehlar -X
> > (ftehlar - PANTHEON TECH SRO at Cisco) ; nranns
> > ; Benoit Ganne (bganne)
> > Subject: Is there a bug in IKEv2 when enable multithread ?
> >
> >
> >
> >
> >
> >
> > zhangguangm...@baicells.com
> >
> >
> > From: zhangguangm...@baicells.com
> > <mailto:zhangguangm...@baicells.com>
> > Date: 2021-11-02 17:01
> > To: vpp-dev <mailto:vpp-dev@lists.fd.io>
> > CC: ftehlar <mailto:fteh...@cisco.com>
> > Subject: Is there a bug in IKEv2 when enable multithread ?
> > Hi，
> >
> > When I test IKEv2, i found when enable multithread , the
> ike
> > sa will be detelte quickly after IKE negotiation complete.
> > The root casue is the inti and auth packet handle by one worker
> > thread ,but the informational packet was handled by the other
> thread.
> > RSS is enable.
> >
> >
> > The follow is my configuration
> >
> >
> >
> > cpu {
> > ## In the VPP there is one main thread and optionally the user can
> > create worker(s)
> > ## The main thread and worker thread(s) can be pinned to CPU
> core(s)
> > manually or automatically
> >
> >
> > ## Manual pinning of thread(s) to CPU core(s)
> >
> >
> > ## Set logical CPU core where main thread runs, if main core is
> not
> > set
> > ## VPP will use core 1 if available
> > main-core 1
> >
> >
> > ## Set logical CPU core(s) where worker threads are running
> > # corelist-workers 2-3,18-19
> > corelist-workers 2-3,4-5
> >
> >
> > ## Automatic pinning of thread(s) to CPU core(s)
> >
> >
> > ## Set
Re: [vpp-dev] Is there a bug in IKEv2 when enable multithread ?
resend for the last mail send failed to vpp-dev
zhangguangm...@baicells.com
From: zhangguangm...@baicells.com
Date: 2021-11-05 09:54
To: bganne
CC: vpp-dev
Subject: Re: RE: Is there a bug in IKEv2 when enable multithread ?
Yes, the flow with same source/dest ip and ports was assgin to the same
nic queue is the expected. But the resust is the init and auth packet was
assign the same queue, but the informatuon reply (infomation request was send
by vpp) was
assigned the other queue..
I also make another test , cpature all the IKEv2 packets and relpay the
packets those dest address is vpp, all the pakcet was assgined to the same
queue.
I think there are two cause ,the one is NIC rss is not work , the other is
IKEv2 code . The firt is most possibility , but the first is not able to
explain the the second test result .
I have reported the first cause through the Intel $(D"n Premier Support site.
My physical NIC is 82599. The VF(SRIOV ) was use by a VM . The question
about RSS support ixgbevf
root@gmzhang:~/vpn# ethtool -i enp2s13
driver: ixgbevf
version: 4.1.0-k
firmware-version:
expansion-rom-version:
bus-info: :02:0d.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
Guangming
Thanks
zhangguangm...@baicells.com
From: Benoit Ganne (bganne)
Date: 2021-11-05 01:12
To: zhangguangm...@baicells.com
CC: vpp-dev
Subject: RE: Is there a bug in IKEv2 when enable multithread ?
Hi,
Why do you receive those packets on different workers? I would expect all the
IKE packets to use the same source/dest IP and ports hence arriving in the same
worker. Is it not the case?
Best
ben
> -Original Message-
> From: zhangguangm...@baicells.com
> Sent: mardi 2 novembre 2021 10:15
> To: Damjan Marion (damarion) ; Filip Tehlar -X
> (ftehlar - PANTHEON TECH SRO at Cisco) ; nranns
> ; Benoit Ganne (bganne)
> Subject: Is there a bug in IKEv2 when enable multithread ?
>
>
>
>
>
>
> zhangguangm...@baicells.com
>
>
> From: zhangguangm...@baicells.com
> <mailto:zhangguangm...@baicells.com>
> Date: 2021-11-02 17:01
> To: vpp-dev <mailto:vpp-dev@lists.fd.io>
> CC: ftehlar <mailto:fteh...@cisco.com>
> Subject: Is there a bug in IKEv2 when enable multithread ?
> Hi，
>
> When I test IKEv2, i found when enable multithread , the ike
> sa will be detelte quickly after IKE negotiation complete.
> The root casue is the inti and auth packet handle by one worker
> thread ,but the informational packet was handled by the other thread.
> RSS is enable.
>
>
> The follow is my configuration
>
>
>
> cpu {
> ## In the VPP there is one main thread and optionally the user can
> create worker(s)
> ## The main thread and worker thread(s) can be pinned to CPU core(s)
> manually or automatically
>
>
> ## Manual pinning of thread(s) to CPU core(s)
>
>
> ## Set logical CPU core where main thread runs, if main core is not
> set
> ## VPP will use core 1 if available
> main-core 1
>
>
> ## Set logical CPU core(s) where worker threads are running
> # corelist-workers 2-3,18-19
> corelist-workers 2-3,4-5
>
>
> ## Automatic pinning of thread(s) to CPU core(s)
>
>
> ## Sets number of CPU core(s) to be skipped (1 ... N-1)
> ## Skipped CPU core(s) are not used for pinning main thread and
> working thread(s).
> ## The main thread is automatically pinned to the first available
> CPU core and worker(s)
> ## are pinned to next free CPU core(s) after core assigned to main
> thread
> # skip-cores 4
>
>
> ## Specify a number of workers to be created
> ## Workers are pinned to N consecutive CPU cores while skipping
> "skip-cores" CPU core(s)
> ## and main thread's CPU core
> #workers 2
>
>
> ## Set scheduling policy and priority of main and worker threads
>
>
> ## Scheduling policy options are: other (SCHED_OTHER), batch
> (SCHED_BATCH)
> ## idle (SCHED_IDLE), fifo (SCHED_FIFO), rr (SCHED_RR)
> # scheduler-policy fifo
>
>
> ## Scheduling priority is used only for "real-time policies (fifo
> and rr),
> ## and has to be in the range of priorities supported for a
> particular policy
> # scheduler-priority 50
> }
>
>
>
>
> dpdk {
> ## Change default settings for all interfaces
> dev default {
> ## Number of receive queues, enables RSS
> ## Default is 1
> num-rx-queues 4
>
>
> ## Number of transmit queues, Default is equal
> ## to number of worker threads or 1 if no workers treads
>num-tx-queues 4
>
>
> ## Number of descriptors in transmit and receive rings
> ## increasing or reducing num
