[vpp-dev] Facing Abort in VPP with Sanitizer

[chetan bhasin]

Hello Everyone,

We have back-merged ASAN related changes to vpp_1908 . We are using
devtool-set-9 for our compilation of SANITIZER build. Application is
getting abort in
File : src/vpp/api/api_format.c
Function : void vat_api_hookup (vat_main_t * vam)
Code :
22191   /* API messages we can send */
22192 #define _(n,h) hash_set_mem (vam->function_by_name, #n, api_##n);
*22193   foreach_vpe_api_msg;*
22194 #undef _

 Any help here would be appreciated.


*console logs*

Starting program: /opt/opwv/integra/99.9/tools/vpp_asan/./bin/vpp -c
root_startup.conf
Missing separate debuginfo for
/opt/opwv/integra/99.9/tools/vpp_asan/bin/../lib/libasan.so.5
Try: yum --enablerepo='*debug*' install
/usr/lib/debug/.build-id/1e/00d6f3d73b509f1b159047be658313f3dc681d.debug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
==10089==AddressSanitizer: libc interceptors initialized
|| `[0x10007fff8000, 0x7fff]` || HighMem||
|| `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
|| `[0x8fff7000, 0x02008fff6fff]` || ShadowGap  ||
|| `[0x7fff8000, 0x8fff6fff]` || LowShadow  ||
|| `[0x, 0x7fff7fff]` || LowMem ||
MemToShadow(shadow): 0x8fff7000 0x91ff6dff 0x004091ff6e00
0x02008fff6fff
redzone=16
max_redzone=2048
quarantine_size_mb=256M
thread_local_quarantine_size_kb=1024K
malloc_context_size=30
SHADOW_SCALE: 3
SHADOW_GRANULARITY: 8
SHADOW_OFFSET: 0x7fff8000
==10089==Installed the sigaction for signal 11
==10089==Installed the sigaction for signal 7
==10089==Installed the sigaction for signal 8
==10089==T0: stack [0x7f7ff000,0x7000) size 0x80;
local=0x7fffdee4
AddressSanitizer: reading suppressions file at
/opt/opwv/integra/99.9/tools/vpp_asan/asan-suppression
==10089==AddressSanitizer Init done
==10089==poisoning: 0x7fffce20 1000
vlib_plugin_early_init:361: plugin path
/opt/opwv/integra/SystemActivePath/tools/vpp_asan/lib/vpp_plugins

*GDB back trace*
*#0  0x73bce8c9 in clib_memcpy_fast (dst=0x1881349000d2f00,
src=0x13010b390b3b0b, n=4182438362655424791)*
*at
/vlad/p4/gcc9/ngp/mainline_gcc/third-party/vpp/vpp_1908/src/vppinfra/memcpy_sse3.h:187*
*#1  0x73be0758 in lookup (v=0x7fffae6b2be8, key=6960224, op=SET,
new_value=0x7fffaea3a2d0, old_value=0x0)*
*at
/vlad/p4/gcc9/ngp/mainline_gcc/third-party/vpp/vpp_1908/src/vppinfra/hash.c:622*
*#2  0x73be1a9c in _hash_set3 (v=0x7fffae6b2be8, key=6960224,
value=0x7fffaea3a2d0, old_value=0x0)*
*at
/vlad/p4/gcc9/ngp/mainline_gcc/third-party/vpp/vpp_1908/src/vppinfra/hash.c:851*
*#3  0x00632b86 in vat_api_hookup (vam=0x70c180 )*
*at
/vlad/p4/gcc9/ngp/mainline_gcc/third-party/vpp/vpp_1908/src/vpp/api/api_format.c:22193*
*#4  0x00655e85 in vat_api_hookup_shim (vm=0x748d4640
)*
*at
/vlad/p4/gcc9/ngp/mainline_gcc/third-party/vpp/vpp_1908/src/vpp/api/api_format.c:22217*
*#5  0x744b4ea2 in call_init_exit_functions_internal
(vm=0x748d4640 ,*
*headp=0x7491b0c8 , call_once=1,
do_sort=1)*
*at
/vlad/p4/gcc9/ngp/mainline_gcc/third-party/vpp/vpp_1908/src/vlib/init.c:350*
*#6  0x744b4f1d in vlib_call_init_exit_functions (vm=0x748d4640
,*
*headp=0x7491b0c8 , call_once=1)*
*at
/vlad/p4/gcc9/ngp/mainline_gcc/third-party/vpp/vpp_1908/src/vlib/init.c:364*
*#7  0x77fa1777 in vl_api_clnt_process (vm=0x748d4640
, node=0x7fffaea36000, f=0x0)*
*at
/vlad/p4/gcc9/ngp/mainline_gcc/third-party/vpp/vpp_1908/src/vlibmemory/vlib_api.c:285*
*#8  0x7450c727 in vlib_process_bootstrap (_a=140736129047184)*
*at
/vlad/p4/gcc9/ngp/mainline_gcc/third-party/vpp/vpp_1908/src/vlib/main.c:2911*
*#9  0x73bec458 in clib_calljmp () from
/opt/opwv/integra/99.9/tools/vpp_asan/bin/../lib/libvppinfra.so.19.08.1*
*#10 0x7fffaefa9a40 in ?? ()*


Thanks,
Chetan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19449): https://lists.fd.io/g/vpp-dev/message/19449
Mute This Topic: https://lists.fd.io/mt/83071004/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev]: Unable to run VPP with ASAN enabled

[Rajith PR via lists.fd.io]

Hi All,

I am not able to run VPP with ASAN. Though we have been using VPP for
sometime this is the first time we enabled ASAN in the build.
I have followed the steps as mentioned in the sanitizer doc, can someone
please let me know what is missed here.

*Run Time Error(Missing symbol):*

/usr/local/lib/librtbvpp.so:/home/supervisor/libvpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.1.0.1:
undefined symbol: __asan_option_detect_stack_use_after_return

*VPP Version* : 20.09

*Build Command* : make rebuild VPP_EXTRA_CMAKE_ARGS=
-DVPP_ENABLE_SANITIZE_ADDR=ON

*Build Summary *:

VPP version : 1.0.1-3032~g4b28254fc-dirty
VPP library version : 1.0.1
GIT toplevel dir: /home/supervisor/libvpp
Build type  : debug
C flags : -fsanitize=address -DCLIB_SANITIZE_ADDR
-Wno-address-of-packed-member -g -fPIC -Werror -Wall -march=corei7
-mtune=corei7-avx -O0 -DCLIB_DEBUG -fstack-protector -DFORTIFY_SOURCE=2
-fno-common
Linker flags (apps) : -fsanitize=address
Linker flags (libs) : -fsanitize=address
Host processor  : x86_64
Target processor: x86_64
Prefix path :
/opt/vpp/external/x86_64;/home/supervisor/libvpp/build-root/install-vpp_debug-native/external
Install prefix  :
/home/supervisor/libvpp/build-root/install-vpp_debug-native/vpp

*Reference *: https://fd.io/docs/vpp/master/troubleshooting/sanitizer.html

Thanks,
Rajith

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19450): https://lists.fd.io/g/vpp-dev/message/19450
Mute This Topic: https://lists.fd.io/mt/83071228/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] Facing Abort in VPP with Sanitizer

[Benoit Ganne (bganne) via lists.fd.io]

If your backtrace is to be trusted, your stack is corrupted:

> #0  0x73bce8c9 in clib_memcpy_fast (dst=0x1881349000d2f00,
> src=0x13010b390b3b0b, n=4182438362655424791)

Pointers and size look definitely wrong here.
If the crash always happen at the same place, I'd recommend to break right 
before it and step-by-step to try to figure what is going on.

ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of chetan bhasin
> Sent: mardi 25 mai 2021 09:21
> To: vpp-dev 
> Subject: [vpp-dev] Facing Abort in VPP with Sanitizer
> 
> Hello Everyone,
> 
> 
> We have back-merged ASAN related changes to vpp_1908 . We are using
> devtool-set-9 for our compilation of SANITIZER build. Application is
> getting abort in
> File : src/vpp/api/api_format.c
> Function : void vat_api_hookup (vat_main_t * vam)
> Code :
> 22191   /* API messages we can send */
> 22192 #define _(n,h) hash_set_mem (vam->function_by_name, #n, api_##n);
> 22193   foreach_vpe_api_msg;
> 22194 #undef _
> 
>  Any help here would be appreciated.
> 
> 
> console logs
> 
> Starting program: /opt/opwv/integra/99.9/tools/vpp_asan/./bin/vpp -c
> root_startup.conf
> Missing separate debuginfo for
> /opt/opwv/integra/99.9/tools/vpp_asan/bin/../lib/libasan.so.5
> Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-
> id/1e/00d6f3d73b509f1b159047be658313f3dc681d.debug
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> ==10089==AddressSanitizer: libc interceptors initialized
> || `[0x10007fff8000, 0x7fff]` || HighMem||
> || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
> || `[0x8fff7000, 0x02008fff6fff]` || ShadowGap  ||
> || `[0x7fff8000, 0x8fff6fff]` || LowShadow  ||
> || `[0x, 0x7fff7fff]` || LowMem ||
> MemToShadow(shadow): 0x8fff7000 0x91ff6dff 0x004091ff6e00
> 0x02008fff6fff
> redzone=16
> max_redzone=2048
> quarantine_size_mb=256M
> thread_local_quarantine_size_kb=1024K
> malloc_context_size=30
> SHADOW_SCALE: 3
> SHADOW_GRANULARITY: 8
> SHADOW_OFFSET: 0x7fff8000
> ==10089==Installed the sigaction for signal 11
> ==10089==Installed the sigaction for signal 7
> ==10089==Installed the sigaction for signal 8
> ==10089==T0: stack [0x7f7ff000,0x7000) size 0x80;
> local=0x7fffdee4
> AddressSanitizer: reading suppressions file at
> /opt/opwv/integra/99.9/tools/vpp_asan/asan-suppression
> ==10089==AddressSanitizer Init done
> ==10089==poisoning: 0x7fffce20 1000
> vlib_plugin_early_init:361: plugin path
> /opt/opwv/integra/SystemActivePath/tools/vpp_asan/lib/vpp_plugins
> 
> GDB back trace
> #0  0x73bce8c9 in clib_memcpy_fast (dst=0x1881349000d2f00,
> src=0x13010b390b3b0b, n=4182438362655424791)
> at /vlad/p4/gcc9/ngp/mainline_gcc/third-
> party/vpp/vpp_1908/src/vppinfra/memcpy_sse3.h:187
> #1  0x73be0758 in lookup (v=0x7fffae6b2be8, key=6960224, op=SET,
> new_value=0x7fffaea3a2d0, old_value=0x0)
> at /vlad/p4/gcc9/ngp/mainline_gcc/third-
> party/vpp/vpp_1908/src/vppinfra/hash.c:622
> #2  0x73be1a9c in _hash_set3 (v=0x7fffae6b2be8, key=6960224,
> value=0x7fffaea3a2d0, old_value=0x0)
> at /vlad/p4/gcc9/ngp/mainline_gcc/third-
> party/vpp/vpp_1908/src/vppinfra/hash.c:851
> #3  0x00632b86 in vat_api_hookup (vam=0x70c180 )
> at /vlad/p4/gcc9/ngp/mainline_gcc/third-
> party/vpp/vpp_1908/src/vpp/api/api_format.c:22193
> #4  0x00655e85 in vat_api_hookup_shim (vm=0x748d4640
> )
> at /vlad/p4/gcc9/ngp/mainline_gcc/third-
> party/vpp/vpp_1908/src/vpp/api/api_format.c:22217
> #5  0x744b4ea2 in call_init_exit_functions_internal
> (vm=0x748d4640 ,
> headp=0x7491b0c8 , call_once=1,
> do_sort=1)
> at /vlad/p4/gcc9/ngp/mainline_gcc/third-
> party/vpp/vpp_1908/src/vlib/init.c:350
> #6  0x744b4f1d in vlib_call_init_exit_functions (vm=0x748d4640
> ,
> headp=0x7491b0c8 , call_once=1)
> at /vlad/p4/gcc9/ngp/mainline_gcc/third-
> party/vpp/vpp_1908/src/vlib/init.c:364
> #7  0x77fa1777 in vl_api_clnt_process (vm=0x748d4640
> , node=0x7fffaea36000, f=0x0)
> at /vlad/p4/gcc9/ngp/mainline_gcc/third-
> party/vpp/vpp_1908/src/vlibmemory/vlib_api.c:285
> #8  0x7450c727 in vlib_process_bootstrap (_a=140736129047184)
> at /vlad/p4/gcc9/ngp/mainline_gcc/third-
> party/vpp/vpp_1908/src/vlib/main.c:2911
> #9  0x73bec458 in clib_calljmp () from
> /opt/opwv/integra/99.9/tools/vpp_asan/bin/../lib/libvppinfra.so.19.08.1
> #10 0x7fffaefa9a40 in ?? ()
> 
> 
> Thanks,
> Chetan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19451): https://lists.fd.io/g/vpp-dev/message/19451
Mute This Topic: https://lists.fd.io/mt/83071004/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]: Unable to run VPP with ASAN enabled

[Benoit Ganne (bganne) via lists.fd.io]

How are you starting VPP? If this is through 'make test' then chances are the 
culprit is the interaction of asan, clang and python [1].
The easy way to fix is to rebuild with gcc instead of clang, eg.
~# make rebuild VPP_EXTRA_CMAKE_ARGS=-DVPP_ENABLE_SANITIZE_ADDR=ON CC=gcc-9

Best
ben

[1] 
https://gerrit.fd.io/r/c/vpp/+/27268/3/src/vpp-api/python/vpp_papi/vpp_ffi.py.in#1

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Rajith PR via
> lists.fd.io
> Sent: mardi 25 mai 2021 09:51
> To: vpp-dev 
> Subject: [vpp-dev]: Unable to run VPP with ASAN enabled
> 
> Hi All,
> 
> I am not able to run VPP with ASAN. Though we have been using VPP for
> sometime this is the first time we enabled ASAN in the build.
> I have followed the steps as mentioned in the sanitizer doc, can someone
> please let me know what is missed here.
> 
> Run Time Error(Missing symbol):
> 
> /usr/local/lib/librtbvpp.so:/home/supervisor/libvpp/build-root/install-
> vpp_debug-native/vpp/lib/libvppinfra.so.1.0.1: undefined symbol:
> __asan_option_detect_stack_use_after_return
> 
> 
> VPP Version : 20.09
> 
> 
> Build Command : make rebuild VPP_EXTRA_CMAKE_ARGS=-
> DVPP_ENABLE_SANITIZE_ADDR=ON
> 
> 
> Build Summary :
> 
> VPP version : 1.0.1-3032~g4b28254fc-dirty
> VPP library version : 1.0.1
> GIT toplevel dir: /home/supervisor/libvpp
> Build type  : debug
> C flags : -fsanitize=address -DCLIB_SANITIZE_ADDR -Wno-
> address-of-packed-member -g -fPIC -Werror -Wall -march=corei7 -
> mtune=corei7-avx -O0 -DCLIB_DEBUG -fstack-protector -DFORTIFY_SOURCE=2 -
> fno-common
> Linker flags (apps) : -fsanitize=address
> Linker flags (libs) : -fsanitize=address
> Host processor  : x86_64
> Target processor: x86_64
> Prefix path :
> /opt/vpp/external/x86_64;/home/supervisor/libvpp/build-root/install-
> vpp_debug-native/external
> Install prefix  : /home/supervisor/libvpp/build-root/install-
> vpp_debug-native/vpp
> 
> 
> 
> Reference : https://fd.io/docs/vpp/master/troubleshooting/sanitizer.html
> 
> 
> Thanks,
> Rajith

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19452): https://lists.fd.io/g/vpp-dev/message/19452
Mute This Topic: https://lists.fd.io/mt/83071228/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Regarding vnet/gre

[Vijay Kumar]

Hi,

I have a requirement to add extension fields (like QFI, RQI) into the GRE
packet header leaving the VPP.
Upon analyzing the packet trace, I found that gre4_input graph node is
called whenever GRE packets enter VPP but for outgoing packets, the GRE
header is  added by the tunnel's mid-chain adjacencies. There is no GRE
graph node specifically for adding outgoing GRE header.

Is it a good idea to add code changes in the adj-midchain-tx node for
adding new fields related to outgoing GRE packets?


Pls advise.


Thanks.
Vijay.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19453): https://lists.fd.io/g/vpp-dev/message/19453
Mute This Topic: https://lists.fd.io/mt/83074159/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] AF_XDP usage help in VPP21.01

[Xuekun]

Hi,  Ben. 

I figured out the problem in my setup that on the ixgbe driver. 
1.  ixgbe 5.1.0 (which don't have XDP enabled yet) + VPP master (that have your 
below patch)  : work
2. ixgbe 5.8.1 (which have XDP enabled) + VPP master : doesn't work 

Strange. Have any ideas? 
Thanks. 

Thx, Xuekun

-Original Message-
From: Benoit Ganne (bganne)  
Sent: Thursday, May 20, 2021 12:50 AM
To: Hu, Xuekun ; vpp-dev@lists.fd.io
Subject: RE: AF_XDP usage help in VPP21.01

Hi Xuekun,

> Thanks for reply. However my kernel is 5.7.19, and I checked that only 
> the first patch was included.
> So, any more thoughts?

Can you try https://gerrit.fd.io/r/c/vpp/+/32384 and see if it fixes you issue?

Best
ben


> -Original Message-
> From: Benoit Ganne (bganne) 
> Sent: Monday, May 17, 2021 4:26 PM
> To: Hu, Xuekun ; vpp-dev@lists.fd.io
> Subject: RE: AF_XDP usage help in VPP21.01
> 
> Hi Xuekun,
> 
> I suspect you are using a Linux kernel >= 5.9. There was an ABI change 
> between 5.8 and 5.9, the issue is discussed here:
> https://lore.kernel.org/bpf/BYAPR11MB365382C5DB1E5FCC53242609C1549@BYA
> PR11
> MB3653.namprd11.prod.outlook.com/
> I'd recommend using a Linux kernel between 5.6 and 5.9 for now until 
> those issues are resolved.
> 
> Best
> ben
> 
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of Xuekun
> > Sent: jeudi 13 mai 2021 15:17
> > To: vpp-dev@lists.fd.io
> > Subject: [vpp-dev] AF_XDP usage help in VPP21.01
> >
> > Hi, All
> >
> >
> >
> > I used VPP21.01 and AF_XDP on a physical nic.
> >
> > I followed the guide in
> > https://docs.fd.io/vpp/21.01/d8/d44/af_xdp_doc.html
> >   that
> >
> > 1.  ip link set dev  promisc on
> > 2.  vppctl create int af_xdp host-if ... // load the default
> > one, which I think should forward all received packets from kernel 
> > to
> VPP
> > 3.  vppctl set int mac address  // set to the NIC MAC.
> > 4.  vppctl set int ip addr ...
> >
> >
> >
> > However "vppctl ping" still failed with "l3 mac mismatch".
> >
> >
> >
> > vpp# show errors
> >
> >Count  Node  Reason
> > Severity
> >
> > 20 ip4-glean  ARP requests sent
> > error
> >
> > 20   enp9s0f0/0-tx sendto required
> > error
> >
> > 82   ethernet-inputl3 mac mismatch
> > error
> >
> > From the remote ping target machine, tcpdump did show receiving the 
> > arp request and sending the arp reply with the correct dmac.
> >
> >
> >
> > However in VPP, "trace add af_xdp-input 10", and  "show trace"
> >
> > Packet 1
> >
> >
> >
> > 00:14:16:539735: af_xdp-input
> >
> >   af_xdp: enp9s0f0/0 (2) next-node ethernet-input
> >
> > 00:14:16:539744: ethernet-input
> >
> >   frame: flags 0x1, hw-if-index 2, sw-if-index 2
> >
> >   0x: 00:00:00:00:00:00 -> 00:00:00:00:00:00
> >
> > 00:14:16:539748: error-punt
> >
> >   rx:enp9s0f0/0
> >
> > 00:14:16:539750: punt
> >
> >   ethernet-input: l3 mac mismatch
> >
> >
> >
> > Does anyone have any ideas?
> >
> > Many thanks.
> >
> >
> >
> > Thx, Xuekun
> >
> >


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19454): https://lists.fd.io/g/vpp-dev/message/19454
Mute This Topic: https://lists.fd.io/mt/82798670/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 crash issue with large number of acl session

[Andrew Yourtchenko]

There is no way to gracefully fail an insertion into a bihash - it either 
succeeds or you get a crash.

The max session limit attempts to guard against that, by failing the addition 
using the heuristic number. You dialed this number up to 20 mil, so no more 
safe guard - which is what you observe.

But you are still running at a default heap size. “heapsize” parameter allows 
to change that.

As there is no hard and fast formula how much memory the bihash will consume, 
it’s up to you to tune the above two variables such that there is happiness.

--a

> On 23 May 2021, at 08:14, NetHappy  wrote:
> 
> Hi An drew,
> 
> Myself modified the code to suit some requirement. The plain vpp acl module 
> also crashes in similar situation. 
> I am expecting the vpp should crash while trying to add more sessions. The 
> system has 64 GB RAM and vpp was using  3.44% of the memory while crashing. 
> So the system is not out of memory but its not configured to use the 
> available memory.
> 
> The relevant crash bt is this
> 
> #5  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #6  0x7f2fba309859 in __GI_abort () at abort.c:79
> #7  0x7f2fba4e0bba in os_panic () at 
> /root/code/vpp/src/vppinfra/unix-misc.c:221
> #8  os_out_of_memory () at /root/code/vpp/src/vppinfra/unix-misc.c:221
> #9  0x7f2fba721701 in clib_mem_alloc_aligned_at_offset 
> (os_out_of_memory_on_failure=1, align_offset=0, align=64, size=98368) at 
> /root/code/vpp/src/vppinfra/mem.h:243
> #10 clib_mem_alloc_aligned (align=64, size=98368) at 
> /root/code/vpp/src/vppinfra/mem.h:263
> #11 alloc_aligned_16_8 (nbytes=12288, h=0x7f2f79d59998 ) at 
> /root/code/vpp/src/vppinfra/bihash_template.c:77
> #12 value_alloc_16_8 (h=0x7f2f79d59998 , log2_pages= out>) at /root/code/vpp/src/vppinfra/bihash_template.c:462
> #13 0x7f2fbabdaefd in split_and_rehash_16_8 (h=h@entry=0x7f2f79d59998 
> , old_values=old_values@entry=0x7f2faf1d9a00, 
> old_log2_pages=old_log2_pages@entry=5, 
> new_log2_pages=new_log2_pages@entry=7) at 
> /root/code/vpp/src/vppinfra/bihash_template.c:581
> #14 0x7f2fbabdcbd0 in clib_bihash_add_del_inline_with_hash_16_8 (arg=0x0, 
> is_stale_cb=0x0, is_add=1, hash=, add_v=0x7f19a6991b48, 
> h=0x7f2f79d59998 ) at 
> /root/code/vpp/src/vppinfra/bihash_template.c:901
> #15 clib_bihash_add_del_inline_16_8 (arg=0x0, is_stale_cb=0x0, is_add=1, 
> add_v=0x7f19a6991b48, h=0x7f2f79d59998 )
> at /root/code/vpp/src/vppinfra/bihash_template.c:985
> #16 clib_bihash_add_del_16_8 (h=h@entry=0x7f2f79d59998 , 
> add_v=add_v@entry=0x7f19a6991b48, is_add=is_add@entry=1)
> at /root/code/vpp/src/vppinfra/bihash_template.c:992
> #17 0x7f2f798bc8b5 in acl_fa_add_session (current_policy_epoch= out>, p5tuple=0x7f2f7cd5bc58, now=7927760728493450, sw_if_index= out>, is_ip6=0, 
> is_input=0, am=) at 
> /root/code/vpp/src/plugins/acl/session_inlines.h:577
> #18 acl_fa_inner_node_fn (reclassify_sessions=1, node_trace_on=0, 
> with_stateful_datapath=1, is_l2_path=1, is_input=0, is_ip6=0, 
> frame=0x7f2f8c5f6440, 
> node=0x7f2f8d6de980, vm=0x7f2f8d6f3dc0) at 
> /root/code/vpp/src/plugins/acl/dataplane_node.c:1137
> #19 acl_fa_outer_node_fn (do_stateful_datapath=1, is_l2_path=1, is_input=0, 
> is_ip6=0, frame=0x7f2f8c5f6440, node=0x7f2f8d6de980, vm=0x7f2f8d6f3dc0)
> at /root/code/vpp/src/plugins/acl/dataplane_node.c:1428
> #20 acl_fa_node_fn (is_l2_path=1, is_input=0, is_ip6=0, frame=0x7f2f8c5f6440, 
> node=0x7f2f8d6de980, vm=0x7f2f8d6f3dc0)
> at /root/code/vpp/src/plugins/acl/dataplane_node.c:1456
> #21 acl_out_l2_ip4_node_fn_hsw (vm=0x7f2f8d6f3dc0, node=0x7f2f8d6de980, 
> frame=0x7f2f8c5f6440) at /root/code/vpp/src/plugins/acl/dataplane_node.c:1569
> #22 0x7f2fba595fa6 in dispatch_node (last_time_stamp=, 
> frame=0x7f2f8c5f6440, dispatch_state=VLIB_NODE_STATE_POLLING, 
> type=VLIB_NODE_TYPE_INTERNAL, 
> node=0x7f2f8d6de980, vm=0x7f2f8d6de980) at 
> /root/code/vpp/src/vlib/main.c:1039
> #23 dispatch_pending_node (vm=vm@entry=0x7f2f8d6f3dc0, 
> pending_frame_index=pending_frame_index@entry=7, last_time_stamp= out>)
> at /root/code/vpp/src/vlib/main.c:1198
> #24 0x7f2fba5978ff in vlib_main_or_worker_loop (is_main=0, 
> vm=0x7f2f8d6f3dc0) at /root/code/vpp/src/vlib/main.c:1662
> #25 vlib_worker_loop (vm=vm@entry=0x7f2f8d6f3dc0) at 
> /root/code/vpp/src/vlib/main.c:1796
> #26 0x7f2fba5c4bf8 in vlib_worker_thread_fn (arg=) at 
> /root/code/vpp/src/vlib/threads.c:1872
> #27 0x7f2fba529cb0 in clib_calljmp () from 
> /lib/x86_64-linux-gnu/libvppinfra.so.21.06
> #28 0x7f2f72896d10 in ?? ()
> #29 0x7f2f76976c5d in eal_thread_loop.cold () from 
> /usr/lib/x86_64-linux-gnu/vpp_plugins/dpdk_plugin.so
> #30 0x in ?? ()
>
> In the frame 18 before calling acl_fa_can_add_session, why 
> acl_fa_can_add_session is not failing ? What Is best way to set configuration 
> so that vpp able to use more RAM ? 
> 
> Thanks,
> Mahamuda 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You 

Re: [vpp-dev] vpp crash issue with large number of acl session

[Andrew Yourtchenko]

to be precise: “memory { main-heap-size 16G }” or something along these lines 
is what might be useful for your config.

--a

> On 25 May 2021, at 14:40, Andrew 👽 Yourtchenko  wrote:
> 
> There is no way to gracefully fail an insertion into a bihash - it either 
> succeeds or you get a crash.
> 
> The max session limit attempts to guard against that, by failing the addition 
> using the heuristic number. You dialed this number up to 20 mil, so no more 
> safe guard - which is what you observe.
> 
> But you are still running at a default heap size. “heapsize” parameter allows 
> to change that.
> 
> As there is no hard and fast formula how much memory the bihash will consume, 
> it’s up to you to tune the above two variables such that there is happiness.
> 
> --a
> 
>> On 23 May 2021, at 08:14, NetHappy  wrote:
>> 
>> Hi An drew,
>> 
>> Myself modified the code to suit some requirement. The plain vpp acl module 
>> also crashes in similar situation. 
>> I am expecting the vpp should crash while trying to add more sessions. The 
>> system has 64 GB RAM and vpp was using  3.44% of the memory while crashing. 
>> So the system is not out of memory but its not configured to use the 
>> available memory.
>> 
>> The relevant crash bt is this
>> 
>> #5  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
>> #6  0x7f2fba309859 in __GI_abort () at abort.c:79
>> #7  0x7f2fba4e0bba in os_panic () at 
>> /root/code/vpp/src/vppinfra/unix-misc.c:221
>> #8  os_out_of_memory () at /root/code/vpp/src/vppinfra/unix-misc.c:221
>> #9  0x7f2fba721701 in clib_mem_alloc_aligned_at_offset 
>> (os_out_of_memory_on_failure=1, align_offset=0, align=64, size=98368) at 
>> /root/code/vpp/src/vppinfra/mem.h:243
>> #10 clib_mem_alloc_aligned (align=64, size=98368) at 
>> /root/code/vpp/src/vppinfra/mem.h:263
>> #11 alloc_aligned_16_8 (nbytes=12288, h=0x7f2f79d59998 ) at 
>> /root/code/vpp/src/vppinfra/bihash_template.c:77
>> #12 value_alloc_16_8 (h=0x7f2f79d59998 , log2_pages=> out>) at /root/code/vpp/src/vppinfra/bihash_template.c:462
>> #13 0x7f2fbabdaefd in split_and_rehash_16_8 (h=h@entry=0x7f2f79d59998 
>> , old_values=old_values@entry=0x7f2faf1d9a00, 
>>old_log2_pages=old_log2_pages@entry=5, 
>> new_log2_pages=new_log2_pages@entry=7) at 
>> /root/code/vpp/src/vppinfra/bihash_template.c:581
>> #14 0x7f2fbabdcbd0 in clib_bihash_add_del_inline_with_hash_16_8 
>> (arg=0x0, is_stale_cb=0x0, is_add=1, hash=, 
>> add_v=0x7f19a6991b48, 
>>h=0x7f2f79d59998 ) at 
>> /root/code/vpp/src/vppinfra/bihash_template.c:901
>> #15 clib_bihash_add_del_inline_16_8 (arg=0x0, is_stale_cb=0x0, is_add=1, 
>> add_v=0x7f19a6991b48, h=0x7f2f79d59998 )
>>at /root/code/vpp/src/vppinfra/bihash_template.c:985
>> #16 clib_bihash_add_del_16_8 (h=h@entry=0x7f2f79d59998 , 
>> add_v=add_v@entry=0x7f19a6991b48, is_add=is_add@entry=1)
>>at /root/code/vpp/src/vppinfra/bihash_template.c:992
>> #17 0x7f2f798bc8b5 in acl_fa_add_session 
>> (current_policy_epoch=, p5tuple=0x7f2f7cd5bc58, 
>> now=7927760728493450, sw_if_index=, is_ip6=0, 
>>is_input=0, am=) at 
>> /root/code/vpp/src/plugins/acl/session_inlines.h:577
>> #18 acl_fa_inner_node_fn (reclassify_sessions=1, node_trace_on=0, 
>> with_stateful_datapath=1, is_l2_path=1, is_input=0, is_ip6=0, 
>> frame=0x7f2f8c5f6440, 
>>node=0x7f2f8d6de980, vm=0x7f2f8d6f3dc0) at 
>> /root/code/vpp/src/plugins/acl/dataplane_node.c:1137
>> #19 acl_fa_outer_node_fn (do_stateful_datapath=1, is_l2_path=1, is_input=0, 
>> is_ip6=0, frame=0x7f2f8c5f6440, node=0x7f2f8d6de980, vm=0x7f2f8d6f3dc0)
>>at /root/code/vpp/src/plugins/acl/dataplane_node.c:1428
>> #20 acl_fa_node_fn (is_l2_path=1, is_input=0, is_ip6=0, 
>> frame=0x7f2f8c5f6440, node=0x7f2f8d6de980, vm=0x7f2f8d6f3dc0)
>>at /root/code/vpp/src/plugins/acl/dataplane_node.c:1456
>> #21 acl_out_l2_ip4_node_fn_hsw (vm=0x7f2f8d6f3dc0, node=0x7f2f8d6de980, 
>> frame=0x7f2f8c5f6440) at /root/code/vpp/src/plugins/acl/dataplane_node.c:1569
>> #22 0x7f2fba595fa6 in dispatch_node (last_time_stamp=, 
>> frame=0x7f2f8c5f6440, dispatch_state=VLIB_NODE_STATE_POLLING, 
>> type=VLIB_NODE_TYPE_INTERNAL, 
>>node=0x7f2f8d6de980, vm=0x7f2f8d6de980) at 
>> /root/code/vpp/src/vlib/main.c:1039
>> #23 dispatch_pending_node (vm=vm@entry=0x7f2f8d6f3dc0, 
>> pending_frame_index=pending_frame_index@entry=7, last_time_stamp=> out>)
>>at /root/code/vpp/src/vlib/main.c:1198
>> #24 0x7f2fba5978ff in vlib_main_or_worker_loop (is_main=0, 
>> vm=0x7f2f8d6f3dc0) at /root/code/vpp/src/vlib/main.c:1662
>> #25 vlib_worker_loop (vm=vm@entry=0x7f2f8d6f3dc0) at 
>> /root/code/vpp/src/vlib/main.c:1796
>> #26 0x7f2fba5c4bf8 in vlib_worker_thread_fn (arg=) at 
>> /root/code/vpp/src/vlib/threads.c:1872
>> #27 0x7f2fba529cb0 in clib_calljmp () from 
>> /lib/x86_64-linux-gnu/libvppinfra.so.21.06
>> #28 0x7f2f72896d10 in ?? ()
>> #29 0x7f2f76976c5d in eal_thread_loop.cold () from 
>> /usr/lib/x86_64-linux-gnu/vpp_plugins/dpdk_plugin.

[vpp-dev] REMINDER: VPP 21.06 RC1 in 23 hours!

[Andrew Yourtchenko]

Hi all,

Just a kind reminder that the stable/2106 branch pull will happen in about 23 
hours from now.

--a // your friendly 21.06 release manager
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19457): https://lists.fd.io/g/vpp-dev/message/19457
Mute This Topic: https://lists.fd.io/mt/83074918/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] Regarding vnet/gre

[Neale Ranns]

Hi Vijay,

I’d advise you to create a new fixup function (c.f. gre44_fixup) that deals 
with the extra headers you want.

/neale


From: vpp-dev@lists.fd.io  on behalf of Vijay Kumar via 
lists.fd.io 
Date: Tuesday, 25 May 2021 at 14:07
To: vpp-dev 
Subject: [vpp-dev] Regarding vnet/gre
Hi,

I have a requirement to add extension fields (like QFI, RQI) into the GRE 
packet header leaving the VPP.
Upon analyzing the packet trace, I found that gre4_input graph node is called 
whenever GRE packets enter VPP but for outgoing packets, the GRE header is  
added by the tunnel's mid-chain adjacencies. There is no GRE graph node 
specifically for adding outgoing GRE header.

Is it a good idea to add code changes in the adj-midchain-tx node for adding 
new fields related to outgoing GRE packets?


Pls advise.


Thanks.
Vijay.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19458): https://lists.fd.io/g/vpp-dev/message/19458
Mute This Topic: https://lists.fd.io/mt/83074159/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] AF_XDP usage help in VPP21.01

[Benoit Ganne (bganne) via lists.fd.io]

Hi Xuekun,

Can you try with the latest master which now contains 
https://gerrit.fd.io/r/c/vpp/+/32384 if you did not already tried it?
I suspect that could be an offset issue and this change should be more robust 
for those.

Best
ben

> -Original Message-
> From: Hu, Xuekun 
> Sent: mardi 25 mai 2021 14:21
> To: Benoit Ganne (bganne) ; vpp-dev@lists.fd.io
> Subject: RE: AF_XDP usage help in VPP21.01
> 
> Hi,  Ben.
> 
> I figured out the problem in my setup that on the ixgbe driver.
> 1.  ixgbe 5.1.0 (which don't have XDP enabled yet) + VPP master (that have
> your below patch)  : work
> 2. ixgbe 5.8.1 (which have XDP enabled) + VPP master : doesn't work
> 
> Strange. Have any ideas?
> Thanks.
> 
> Thx, Xuekun
> 
> -Original Message-
> From: Benoit Ganne (bganne) 
> Sent: Thursday, May 20, 2021 12:50 AM
> To: Hu, Xuekun ; vpp-dev@lists.fd.io
> Subject: RE: AF_XDP usage help in VPP21.01
> 
> Hi Xuekun,
> 
> > Thanks for reply. However my kernel is 5.7.19, and I checked that only
> > the first patch was included.
> > So, any more thoughts?
> 
> Can you try https://gerrit.fd.io/r/c/vpp/+/32384 and see if it fixes you
> issue?
> 
> Best
> ben
> 
> 
> > -Original Message-
> > From: Benoit Ganne (bganne) 
> > Sent: Monday, May 17, 2021 4:26 PM
> > To: Hu, Xuekun ; vpp-dev@lists.fd.io
> > Subject: RE: AF_XDP usage help in VPP21.01
> >
> > Hi Xuekun,
> >
> > I suspect you are using a Linux kernel >= 5.9. There was an ABI change
> > between 5.8 and 5.9, the issue is discussed here:
> > https://lore.kernel.org/bpf/BYAPR11MB365382C5DB1E5FCC53242609C1549@BYA
> > PR11
> > MB3653.namprd11.prod.outlook.com/
> > I'd recommend using a Linux kernel between 5.6 and 5.9 for now until
> > those issues are resolved.
> >
> > Best
> > ben
> >
> > > -Original Message-
> > > From: vpp-dev@lists.fd.io  On Behalf Of Xuekun
> > > Sent: jeudi 13 mai 2021 15:17
> > > To: vpp-dev@lists.fd.io
> > > Subject: [vpp-dev] AF_XDP usage help in VPP21.01
> > >
> > > Hi, All
> > >
> > >
> > >
> > > I used VPP21.01 and AF_XDP on a physical nic.
> > >
> > > I followed the guide in
> > > https://docs.fd.io/vpp/21.01/d8/d44/af_xdp_doc.html
> > >   that
> > >
> > > 1.ip link set dev  promisc on
> > > 2.vppctl create int af_xdp host-if ... // load the
> default
> > > one, which I think should forward all received packets from kernel
> > > to
> > VPP
> > > 3.vppctl set int mac address  // set to the NIC
> MAC.
> > > 4.vppctl set int ip addr ...
> > >
> > >
> > >
> > > However "vppctl ping" still failed with "l3 mac mismatch".
> > >
> > >
> > >
> > > vpp# show errors
> > >
> > >Count  Node  Reason
> > > Severity
> > >
> > > 20 ip4-glean  ARP requests
> sent
> > > error
> > >
> > > 20   enp9s0f0/0-tx sendto required
> > > error
> > >
> > > 82   ethernet-inputl3 mac mismatch
> > > error
> > >
> > > From the remote ping target machine, tcpdump did show receiving the
> > > arp request and sending the arp reply with the correct dmac.
> > >
> > >
> > >
> > > However in VPP, "trace add af_xdp-input 10", and  "show trace"
> > >
> > > Packet 1
> > >
> > >
> > >
> > > 00:14:16:539735: af_xdp-input
> > >
> > >   af_xdp: enp9s0f0/0 (2) next-node ethernet-input
> > >
> > > 00:14:16:539744: ethernet-input
> > >
> > >   frame: flags 0x1, hw-if-index 2, sw-if-index 2
> > >
> > >   0x: 00:00:00:00:00:00 -> 00:00:00:00:00:00
> > >
> > > 00:14:16:539748: error-punt
> > >
> > >   rx:enp9s0f0/0
> > >
> > > 00:14:16:539750: punt
> > >
> > >   ethernet-input: l3 mac mismatch
> > >
> > >
> > >
> > > Does anyone have any ideas?
> > >
> > > Many thanks.
> > >
> > >
> > >
> > > Thx, Xuekun
> > >
> > >


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19459): https://lists.fd.io/g/vpp-dev/message/19459
Mute This Topic: https://lists.fd.io/mt/82798670/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] AF_XDP usage help in VPP21.01

[Xuekun]

Hi, Ben

I have used the latest master which includes the patch. 

commit 1a06e53341224bb08cff2fb6d218415c50f947d3
Author: Benoît Ganne 
Date:   Wed May 19 16:41:03 2021 +0200

af_xdp: use desc offset on rx

Instead of pre-programming the data offset on rx, use offset passed in
the descriptor. This is more robust and future-proof.

Type: fix

Change-Id: I2bd910d92b8b03d17be5be85a24108be711dc7b9
Signed-off-by: Benoît Ganne 

Thx, Xuekun

-Original Message-
From: Benoit Ganne (bganne)  
Sent: Tuesday, May 25, 2021 9:18 PM
To: Hu, Xuekun ; vpp-dev@lists.fd.io
Subject: RE: AF_XDP usage help in VPP21.01

Hi Xuekun,

Can you try with the latest master which now contains 
https://gerrit.fd.io/r/c/vpp/+/32384 if you did not already tried it?
I suspect that could be an offset issue and this change should be more robust 
for those.

Best
ben

> -Original Message-
> From: Hu, Xuekun 
> Sent: mardi 25 mai 2021 14:21
> To: Benoit Ganne (bganne) ; vpp-dev@lists.fd.io
> Subject: RE: AF_XDP usage help in VPP21.01
> 
> Hi,  Ben.
> 
> I figured out the problem in my setup that on the ixgbe driver.
> 1.  ixgbe 5.1.0 (which don't have XDP enabled yet) + VPP master (that 
> have your below patch)  : work 2. ixgbe 5.8.1 (which have XDP enabled) 
> + VPP master : doesn't work
> 
> Strange. Have any ideas?
> Thanks.
> 
> Thx, Xuekun
> 
> -Original Message-
> From: Benoit Ganne (bganne) 
> Sent: Thursday, May 20, 2021 12:50 AM
> To: Hu, Xuekun ; vpp-dev@lists.fd.io
> Subject: RE: AF_XDP usage help in VPP21.01
> 
> Hi Xuekun,
> 
> > Thanks for reply. However my kernel is 5.7.19, and I checked that 
> > only the first patch was included.
> > So, any more thoughts?
> 
> Can you try https://gerrit.fd.io/r/c/vpp/+/32384 and see if it fixes 
> you issue?
> 
> Best
> ben
> 
> 
> > -Original Message-
> > From: Benoit Ganne (bganne) 
> > Sent: Monday, May 17, 2021 4:26 PM
> > To: Hu, Xuekun ; vpp-dev@lists.fd.io
> > Subject: RE: AF_XDP usage help in VPP21.01
> >
> > Hi Xuekun,
> >
> > I suspect you are using a Linux kernel >= 5.9. There was an ABI 
> > change between 5.8 and 5.9, the issue is discussed here:
> > https://lore.kernel.org/bpf/BYAPR11MB365382C5DB1E5FCC53242609C1549@B
> > YA
> > PR11
> > MB3653.namprd11.prod.outlook.com/
> > I'd recommend using a Linux kernel between 5.6 and 5.9 for now until 
> > those issues are resolved.
> >
> > Best
> > ben
> >
> > > -Original Message-
> > > From: vpp-dev@lists.fd.io  On Behalf Of 
> > > Xuekun
> > > Sent: jeudi 13 mai 2021 15:17
> > > To: vpp-dev@lists.fd.io
> > > Subject: [vpp-dev] AF_XDP usage help in VPP21.01
> > >
> > > Hi, All
> > >
> > >
> > >
> > > I used VPP21.01 and AF_XDP on a physical nic.
> > >
> > > I followed the guide in
> > > https://docs.fd.io/vpp/21.01/d8/d44/af_xdp_doc.html
> > >   that
> > >
> > > 1.ip link set dev  promisc on
> > > 2.vppctl create int af_xdp host-if ... // load the
> default
> > > one, which I think should forward all received packets from kernel 
> > > to
> > VPP
> > > 3.vppctl set int mac address  // set to the NIC
> MAC.
> > > 4.vppctl set int ip addr ...
> > >
> > >
> > >
> > > However "vppctl ping" still failed with "l3 mac mismatch".
> > >
> > >
> > >
> > > vpp# show errors
> > >
> > >Count  Node  Reason
> > > Severity
> > >
> > > 20 ip4-glean  ARP requests
> sent
> > > error
> > >
> > > 20   enp9s0f0/0-tx sendto required
> > > error
> > >
> > > 82   ethernet-inputl3 mac mismatch
> > > error
> > >
> > > From the remote ping target machine, tcpdump did show receiving 
> > > the arp request and sending the arp reply with the correct dmac.
> > >
> > >
> > >
> > > However in VPP, "trace add af_xdp-input 10", and  "show trace"
> > >
> > > Packet 1
> > >
> > >
> > >
> > > 00:14:16:539735: af_xdp-input
> > >
> > >   af_xdp: enp9s0f0/0 (2) next-node ethernet-input
> > >
> > > 00:14:16:539744: ethernet-input
> > >
> > >   frame: flags 0x1, hw-if-index 2, sw-if-index 2
> > >
> > >   0x: 00:00:00:00:00:00 -> 00:00:00:00:00:00
> > >
> > > 00:14:16:539748: error-punt
> > >
> > >   rx:enp9s0f0/0
> > >
> > > 00:14:16:539750: punt
> > >
> > >   ethernet-input: l3 mac mismatch
> > >
> > >
> > >
> > > Does anyone have any ideas?
> > >
> > > Many thanks.
> > >
> > >
> > >
> > > Thx, Xuekun
> > >
> > >


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19460): https://lists.fd.io/g/vpp-dev/message/19460
Mute This Topic: https://lists.fd.io/mt/82798670/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] AF_XDP usage help in VPP21.01

[Benoit Ganne (bganne) via lists.fd.io]

> I have used the latest master which includes the patch.

Ok thanks. To confirm this is an issue with the zero-copy mode, can you try to 
create the af_xdp interface in copy mode by adding the 'no-zero-copy' keyword 
in the create command, eg.
~# vppctl create int af_xdp host-if  no-zero-copy

If it works in copy mode (as I think it will), it means the zero-copy mode does 
not work correctly for some reason. If it is an offset issue, you can look into 
the incoming data by breaking in af_xdp_device_input_bufs() and see if the 
extracted offset matches the start of the data in the packet.

Best
ben

> commit 1a06e53341224bb08cff2fb6d218415c50f947d3
> Author: Benoît Ganne 
> Date:   Wed May 19 16:41:03 2021 +0200
> 
> af_xdp: use desc offset on rx
> 
> Instead of pre-programming the data offset on rx, use offset passed in
> the descriptor. This is more robust and future-proof.
> 
> Type: fix
> 
> Change-Id: I2bd910d92b8b03d17be5be85a24108be711dc7b9
> Signed-off-by: Benoît Ganne 
> 
> Thx, Xuekun
> 
> -Original Message-
> From: Benoit Ganne (bganne) 
> Sent: Tuesday, May 25, 2021 9:18 PM
> To: Hu, Xuekun ; vpp-dev@lists.fd.io
> Subject: RE: AF_XDP usage help in VPP21.01
> 
> Hi Xuekun,
> 
> Can you try with the latest master which now contains
> https://gerrit.fd.io/r/c/vpp/+/32384 if you did not already tried it?
> I suspect that could be an offset issue and this change should be more
> robust for those.
> 
> Best
> ben
> 
> > -Original Message-
> > From: Hu, Xuekun 
> > Sent: mardi 25 mai 2021 14:21
> > To: Benoit Ganne (bganne) ; vpp-dev@lists.fd.io
> > Subject: RE: AF_XDP usage help in VPP21.01
> >
> > Hi,  Ben.
> >
> > I figured out the problem in my setup that on the ixgbe driver.
> > 1.  ixgbe 5.1.0 (which don't have XDP enabled yet) + VPP master (that
> > have your below patch)  : work 2. ixgbe 5.8.1 (which have XDP enabled)
> > + VPP master : doesn't work
> >
> > Strange. Have any ideas?
> > Thanks.
> >
> > Thx, Xuekun
> >
> > -Original Message-
> > From: Benoit Ganne (bganne) 
> > Sent: Thursday, May 20, 2021 12:50 AM
> > To: Hu, Xuekun ; vpp-dev@lists.fd.io
> > Subject: RE: AF_XDP usage help in VPP21.01
> >
> > Hi Xuekun,
> >
> > > Thanks for reply. However my kernel is 5.7.19, and I checked that
> > > only the first patch was included.
> > > So, any more thoughts?
> >
> > Can you try https://gerrit.fd.io/r/c/vpp/+/32384 and see if it fixes
> > you issue?
> >
> > Best
> > ben
> >
> >
> > > -Original Message-
> > > From: Benoit Ganne (bganne) 
> > > Sent: Monday, May 17, 2021 4:26 PM
> > > To: Hu, Xuekun ; vpp-dev@lists.fd.io
> > > Subject: RE: AF_XDP usage help in VPP21.01
> > >
> > > Hi Xuekun,
> > >
> > > I suspect you are using a Linux kernel >= 5.9. There was an ABI
> > > change between 5.8 and 5.9, the issue is discussed here:
> > > https://lore.kernel.org/bpf/BYAPR11MB365382C5DB1E5FCC53242609C1549@B
> > > YA
> > > PR11
> > > MB3653.namprd11.prod.outlook.com/
> > > I'd recommend using a Linux kernel between 5.6 and 5.9 for now until
> > > those issues are resolved.
> > >
> > > Best
> > > ben
> > >
> > > > -Original Message-
> > > > From: vpp-dev@lists.fd.io  On Behalf Of
> > > > Xuekun
> > > > Sent: jeudi 13 mai 2021 15:17
> > > > To: vpp-dev@lists.fd.io
> > > > Subject: [vpp-dev] AF_XDP usage help in VPP21.01
> > > >
> > > > Hi, All
> > > >
> > > >
> > > >
> > > > I used VPP21.01 and AF_XDP on a physical nic.
> > > >
> > > > I followed the guide in
> > > > https://docs.fd.io/vpp/21.01/d8/d44/af_xdp_doc.html
> > > >   that
> > > >
> > > > 1.  ip link set dev  promisc on
> > > > 2.  vppctl create int af_xdp host-if ... // load the
> > default
> > > > one, which I think should forward all received packets from kernel
> > > > to
> > > VPP
> > > > 3.  vppctl set int mac address  // set to the NIC
> > MAC.
> > > > 4.  vppctl set int ip addr ...
> > > >
> > > >
> > > >
> > > > However "vppctl ping" still failed with "l3 mac mismatch".
> > > >
> > > >
> > > >
> > > > vpp# show errors
> > > >
> > > >Count  Node  Reason
> > > > Severity
> > > >
> > > > 20 ip4-glean  ARP requests
> > sent
> > > > error
> > > >
> > > > 20   enp9s0f0/0-tx sendto
> required
> > > > error
> > > >
> > > > 82   ethernet-inputl3 mac
> mismatch
> > > > error
> > > >
> > > > From the remote ping target machine, tcpdump did show receiving
> > > > the arp request and sending the arp reply with the correct dmac.
> > > >
> > > >
> > > >
> > > > However in VPP, "trace add af_xdp-input 10", and  "show trace"
> > > >
> > > > Packet 1
> > > >
> > > >
> > > >
> > > > 00:14:16:539735: af_xdp-input
> > > >
> > > >   af_xdp: enp9s0f0/0 (2) next-node ethernet-input
> > > >
> > > > 00:14:16:539744: ethernet-input
> > > >
> > > >   frame: 

Re: [vpp-dev]: Unable to run VPP with ASAN enabled

[Rajith PR via lists.fd.io]

HI Ben,

We have linked our shared library that has the main function with VPP's
.so. The main function does few things and falls to the VPP's main function
loop.
After changing the compiler t*o gcc-8 I dont get the unresolved symbol
error*.

However, i get the f*ollowing ASAN error:*

==7111==*ASan runtime does not come first in initial library list; you
should either link runtime to your application or manually preload it with
LD_PRELOAD*.

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) q

I was able to proceed further after *setting LD_PRELOAD to the asan
library.* After this i get *SIGSEGV* crash in asan. These dont seem to be
related to our code, as without ASAN they have been perfectly working.

*set environment LD_PRELOAD /usr/lib/gcc/x86_64-linux-gnu/8/libasan.so*

Program received signal SIGSEGV, Segmentation fault.
0x76e39841 in ?? () from /usr/lib/gcc/x86_64-linux-gnu/8/libasan.so
(gdb) bt
#0  0x76e39841 in ?? () from
/usr/lib/gcc/x86_64-linux-gnu/8/libasan.so
#1  0x76f059b1 in ?? () from
/usr/lib/gcc/x86_64-linux-gnu/8/libasan.so
#2  0x76f1e9d3 in ?? () from
/usr/lib/gcc/x86_64-linux-gnu/8/libasan.so
#3  0x76f06d39 in ?? () from
/usr/lib/gcc/x86_64-linux-gnu/8/libasan.so
#4  0x76e35836 in ?? () from
/usr/lib/gcc/x86_64-linux-gnu/8/libasan.so
#5  0x76e366b9 in ?? () from
/usr/lib/gcc/x86_64-linux-gnu/8/libasan.so
#6  0x76e383a0 in ?? () from
/usr/lib/gcc/x86_64-linux-gnu/8/libasan.so
#7  0x76f00d5b in ?? () from
/usr/lib/gcc/x86_64-linux-gnu/8/libasan.so
#8  0x76eb383c in ?? () from
/usr/lib/gcc/x86_64-linux-gnu/8/libasan.so
#9  0x7fffe823727d in rtb_vpp_ifp_mapping_object_get (key_type=1
'\001', ifp_mapping=0x7fffc69a4680) at
/home/supervisor/libvpp/src/vpp/rtbrick/rtb_vpp_ifp.c:287
#10 0x7fffe823a07c in rtb_vpp_hw_interface_add_delete_cb
(vnm=0x7fffe7c10dc0 , hw_if_index=0, is_create=1) at
/home/supervisor/libvpp/src/vpp/rtbrick/rtb_vpp_ifp.c:888
#11 0x7fffe57eff3a in call_elf_section_interface_callbacks
(vnm=0x7fffe7c10dc0 , if_index=0, flags=1, elts=0x7fffe7c10e60
)
at /home/supervisor/libvpp/src/vnet/interface.c:251
#12 0x7fffe57f0137 in call_hw_interface_add_del_callbacks
(vnm=0x7fffe7c10dc0 , hw_if_index=0, is_create=1) at
/home/supervisor/libvpp/src/vnet/interface.c:282
#13 0x7fffe57f0228 in vnet_hw_interface_set_flags_helper
(vnm=0x7fffe7c10dc0 , hw_if_index=0,
flags=VNET_HW_INTERFACE_FLAG_NONE,
helper_flags=VNET_INTERFACE_SET_FLAGS_HELPER_IS_CREATE)
at /home/supervisor/libvpp/src/vnet/interface.c:316
#14 0x7fffe57f767e in vnet_register_interface (vnm=0x7fffe7c10dc0
, dev_class_index=35, dev_instance=0, hw_class_index=30,
hw_instance=0)
at /home/supervisor/libvpp/src/vnet/interface.c:998
#15 0x7fffe58787c0 in vnet_main_init (vm=0x7fffe484a7c0
) at /home/supervisor/libvpp/src/vnet/misc.c:81
#16 0x7fffe444f659 in call_init_exit_functions_internal
(vm=0x7fffe484a7c0 , headp=0x7fffe484ae18
, call_once=1, do_sort=1)
at /home/supervisor/libvpp/src/vlib/init.c:350
#17 0x7fffe444f6d4 in vlib_call_init_exit_functions (vm=0x7fffe484a7c0
, headp=0x7fffe484ae18 ,
call_once=1) at /home/supervisor/libvpp/src/vlib/init.c:364
#18 0x7fffe444f738 in vlib_call_all_init_functions (vm=0x7fffe484a7c0
) at /home/supervisor/libvpp/src/vlib/init.c:386
#19 0x7fffe44a7966 in vlib_main (vm=0x7fffe484a7c0 ,
input=0x7fffc69a4f60) at /home/supervisor/libvpp/src/vlib/main.c:2183
#20 0x7fffe45a121f in thread0 (arg=140737027286976) at
/home/supervisor/libvpp/src/vlib/unix/main.c:681
#21 0x7fffe3fa5e00 in clib_calljmp () at
/home/supervisor/libvpp/src/vppinfra/longjmp.S:123
#22 0x7fffce50 in ?? ()
#23 0x7fffe45a1cd9 in vlib_unix_main (argc=51, argv=0x61416a40) at
/home/supervisor/libvpp/src/vlib/unix/main.c:754
#24 0x7fffe7fb7a72 in rtb_vpp_core_init (argc=51, argv=0x61416a40)
at /home/supervisor/libvpp/src/vpp/vnet/main.c:496
#25 0x7fffe8214dd0 in rtb_vpp_main () at
/home/supervisor/libvpp/src/vpp/rtbrick/rtb_vpp_main.c:119
#26 0x76ba4902 in bd_load_daemon_lib (dmn_lib_cfg=0x5575b400
) at
/development/rtbrick-infrastructure/code/bd/src/bdinfra/bd.c:611
#27 0x76ba5a34 in bd_load_all_daemon_libs () at
/development/rtbrick-infrastructure/code/bd/src/bdinfra/bd.c:630
#28 0x76ba634c in bd_start_process () at
/development/rtbrick-infrastructure/code/bd/src/bdinfra/bd.c:1097
#29 0x747ea28c in bds_bd_init () at
/development/rtbrick-infrastructure/code/bds/bds_core/src/bds.c:659
#30 0x7485ca22 in pubsub_bd_init_expiry (data=) at
/development/rtbrick-infrastructure/code/bds/pubsub/src/pubsub_helper.c:1452
#31 0x766c178b in timer_dispatch (item=0x61a0001ccf20, p=) at /development/rtbrick-infrastructure/code/qb/lib/loop_timerlist.c:56
#32 0x766bf11f in qb_loop_run_l

Re: [vpp-dev] VCL app with multiple TCP sessions handling in single worker

[Sastry Sista]

Hi Florin,
Thank you.

Let me be very specific and focused topic:

I have just single worker but having multiple TCP sessions. So, I will poll on 
vppcom_mq_epoll_fd() for all notifications. So, notifications are for me to do 
data read/write also? If there is a data on shm for any session, we will get 
notification on mq and I need to check which session_handle I got this event 
for and I need to get data on shm using session_handle ?

My question is, once EPOLLIN happened on mq and we get mq_event but, how do I 
map it to session_handle if I have many session_handles?

anyway vppcom_session_read(session_handle,) === this gives me data for that 
TCP session.

I hope that we do not need epoll_ctl APIs?

With Regards
Sastry

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19463): https://lists.fd.io/g/vpp-dev/message/19463
Mute This Topic: https://lists.fd.io/mt/82992940/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 crash issue with large number of acl session

[NetHappy]

Hi Andrew,

Thanks for your reply. I would modify the configuration as per your suggestions.

Thanks,
Mahamuda

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19464): https://lists.fd.io/g/vpp-dev/message/19464
Mute This Topic: https://lists.fd.io/mt/77321080/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] Regarding vnet/gre

[Vijay Kumar]

Hi Neale,

Thanks for the useful input. I will implement a new fixup function similar
to the one mentioned.
I believe the gre44_fixup function callback is registered via
*adj_nbr_midchain_update_rewrite()*

I saw the code of *adj-midchain-tx* graph node but could not find the fixup
function being called. Could you confirm which is the exact graph node that
calls this fixup callback to process GRE headers?


Regards,
Vijay

On Tue, May 25, 2021 at 6:32 PM Neale Ranns  wrote:

>
>
> Hi Vijay,
>
>
>
> I’d advise you to create a new fixup function (c.f. gre44_fixup) that
> deals with the extra headers you want.
>
>
>
> /neale
>
>
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Vijay
> Kumar via lists.fd.io 
> *Date: *Tuesday, 25 May 2021 at 14:07
> *To: *vpp-dev 
> *Subject: *[vpp-dev] Regarding vnet/gre
>
> Hi,
>
>
>
> I have a requirement to add extension fields (like QFI, RQI) into the GRE
> packet header leaving the VPP.
>
> Upon analyzing the packet trace, I found that gre4_input graph node is
> called whenever GRE packets enter VPP but for outgoing packets, the GRE
> header is  added by the tunnel's mid-chain adjacencies. There is no GRE
> graph node specifically for adding outgoing GRE header.
>
>
>
> Is it a good idea to add code changes in the adj-midchain-tx node for
> adding new fields related to outgoing GRE packets?
>
>
>
>
>
> Pls advise.
>
>
>
>
>
> Thanks.
>
> Vijay.
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19465): https://lists.fd.io/g/vpp-dev/message/19465
Mute This Topic: https://lists.fd.io/mt/83074159/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] VCL app with multiple TCP sessions handling in single worker

[Florin Coras]

Hi Sastry, 

Inline. 


> On May 25, 2021, at 7:44 AM, Sastry Sista  wrote:
> 
> Hi Florin,
>   Thank you.
> 
> Let me be very specific and focused topic:
> 
> I have just single worker but having multiple TCP sessions. So, I will poll 
> on vppcom_mq_epoll_fd() for all notifications. So, notifications are for me 
> to do data read/write also? 

The notification is that the vcl worker got new events. So to grab the events, 
you’ll need to use something like vppcom_epoll_wait() with 0 timeout. 

> If there is a data on shm for any session, we will get notification on mq and 
> I need to check which session_handle I got this event for and I need to get 
> data on shm using session_handle ?

No need to do that manually, instead you use vppcom_epoll_wait to do the 
parsing and matching of events to the session_handles/fds the app tracks. 

> 
> My question is, once EPOLLIN happened on mq and we get mq_event but, how do I 
> map it to session_handle if I have many session_handles? 

The steps would be:
1. create vcl_epoll_sh with vppcom_epoll_create and add all of the worker’s 
fd/sh to it using vpcom_epoll_ctl 
2. grab mqs_epfd using vppcom_mq_epoll_fd and add it to the worker’s linux epfd 
(created using epoll_create)
2. when linux epoll notifies the app that mq_epfds got EPOLLIN call a custom 
handler wherein vppcom_epoll_wait(vcl_epoll_sh, vcl_events, maxevents, 0 /* 
timeout*/) is called and all events are grabbed into vcl_events.

Regards,
Florin

> 
> anyway vppcom_session_read(session_handle,) === this gives me data for 
> that TCP session.
> 
> I hope that we do not need epoll_ctl APIs?
> 
> With Regards
> Sastry 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19467): https://lists.fd.io/g/vpp-dev/message/19467
Mute This Topic: https://lists.fd.io/mt/82992940/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] VCL app requires source address/interface control due to loopback

[Florin Coras]

Hi Sastry, 

So the source address should be configurable, but for if the app requires a 
certain vrf, you should consider the option of using session layer namespaces. 
See for instance test/test_vcl.py and how we configure those. Note however that 
will restrict the app to use only one vrf. 

Regards, 
Florin

> On May 24, 2021, at 11:27 PM, Sastry Sista  wrote:
> 
> Hi Florin,
> 
> Thank you so much for all your help. We are very happy to use VPP because of 
> support you all are giving us. 
> 
>  I am sorry if I am missing anything. If you look at 21.01 
> version also, We do not have support for both source address/vrf. We just 
> have those variables inside session but not being used at 
> vppcom_session_connect API.
> 
> Anyway I shall have private API passing session with vrf etc. I hope that 
> works?
> 
> With Regards
> Sastry 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19466): https://lists.fd.io/g/vpp-dev/message/19466
Mute This Topic: https://lists.fd.io/mt/83043661/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] IPv6 in IPv6 Encapsulation

[jerome . bayaux]

Hello Ole, 

I implemented the solution you suggested (i.e chaining the buffers) and it 
seems to work correctly now so thank you ! 

However, I had another issue : when some TCP or UDP packets arrive in VPP, the 
latter seems to set their checksum to zero and it also sets the "offload" flag 
of the associated buffer. In the last VPP nodes the packet traverses, the 
checksum is recomputed just before the packet is forwarded and everything is 
fine. 

Firstly, I don't really understand why it does that ? I create a veth interface 
on my ubuntu and then I link this interface to VPP by using an 
"host-interface". Maybe I need to configure something about the interfaces to 
disable this behavior ? 
Secondly, in a "normal" case, as I said here above, VPP is able to recompute 
the checksum at the end of the graph and nothing bad happens. The problem is 
that, in my case, I need to create a buffer chain and when I do so, VPP is not 
able to recompute the checksums (probably because some information from the 
buffer metadata it is usually using are invalidated because of the buffer 
chains ?). 

Thanks again for your help, 

Jérôme 


De: "jerome bayaux"  
À: "Ole Troan"  
Cc: vpp-dev@lists.fd.io, "Neale Ranns" , "Justin Iurman" 
 
Envoyé: Vendredi 21 Mai 2021 18:20:31 
Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation 

Changing the PRE_DATA_SIZE value in src/vlib/CMakeLists.txt does not appear to 
be that easy.. 

Indeed, it seems to require several other changes like the value of 
DPDK_RTE_PKTMBUF_HEADROOM that appears in src/plugins/dpdk/CMakeLists.txt, and 
some static assert fail by saying : "save_rewrite_length member must be able to 
hold the max value of rewrite length". 

Thus, the best solution is probably the one given by Ole ? Could you help me 
(guide me) a little bit by pointing me files of interest or by redirecting me 
towards some examples if some exist ? For instance, I'm not sure to see which 
functions I should use to create a new buffer and then to chain it to the 
"main" one. 

Jérôme 


De: "Ole Troan"  
À: "jerome bayaux"  
Cc: vpp-dev@lists.fd.io, "Neale Ranns" , "Justin Iurman" 
 
Envoyé: Vendredi 21 Mai 2021 17:21:32 
Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation 





On 21 May 2021, at 17:15, Neale Ranns  wrote: 





BQ_BEGIN



Right, there’s only so much space available. You’ll need to recompile VPP to 
get more space. 

Change the PRE_DATA_SIZE value in src/vlib/CMakeLists.txt. 

BQ_END

Alternatively use a new buffer for the new IPv6 header and extension header 
chain and chain the buffers together. 
You might want to look at the ioam plugin too btw. 

Cheers 
Ole 



BQ_BEGIN





/neale 






From: jerome.bay...@student.uliege.be  
Date: Friday, 21 May 2021 at 17:06 
To: Neale Ranns  
Cc: vpp-dev@lists.fd.io , Justin Iurman 
 
Subject: Re: [vpp-dev] IPv6 in IPv6 Encapsulation 


I've just run few tests to be sure : 





It's exactly that ! As long as the extension header is smaller or exactly equal 
to 128 bytes, everything is fine. 





Once it gets bigger than 128 bytes, it starts to go wrong and funky. 





Jérôme 






De: "Neale Ranns"  
À: "jerome bayaux"  
Cc: vpp-dev@lists.fd.io, "Justin Iurman"  
Envoyé: Vendredi 21 Mai 2021 16:38:02 
Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation 







Does it all start to go wrong when the extension header gets to about 128 
bytes? 



/neale 






From: jerome.bay...@student.uliege.be  
Date: Friday, 21 May 2021 at 16:04 
To: Neale Ranns  
Cc: vpp-dev@lists.fd.io , Justin Iurman 
 
Subject: Re: [vpp-dev] IPv6 in IPv6 Encapsulation 


Hi again Neale, 





Here are some additional observations I've noticed and that could be useful for 
you to help me : 





1) The error only shows up when the Hop-by-Hop extension header I add is big 
enough (I can give you a more accurate definition of "enough" if you need). 
When it is quite small, everything seems fine. 





2) The faulty MAC address seems to follow a "pattern" : it is always of the 
form " X:00:00:00:e3:6e ", where byte X is a number that increases for the 
following packets. Moreover, the bytes " e3:6e " (i.e last 16 bytes of MAC 
address) are correct and correspond to the last 16 bytes of the expected and 
thus correct destination MAC address. 





Thank you for the help, 





Jérôme 






De: "jerome bayaux"  
À: "Neale Ranns"  
Cc: vpp-dev@lists.fd.io, "Justin Iurman"  
Envoyé: Vendredi 21 Mai 2021 14:36:43 
Objet: Re: [vpp-dev] IPv6 in IPv6 Encapsulation 





Hi Neale, 





Here is a trace of a simple ping packet entering into VPP (let me know if you 
need more information about the topology I used) : 





Packet 8 

00:00:38:194824: af-packet-input 
af_packet: hw_if_index 1 next-index 4 
tpacket2_hdr: 
status 0x2001 len 118 snaplen 118 mac 66 net 80 
sec 0x60a7a2bd nsec 0x35392422 vlan 0 vlan_tpid 0 
00:00:38:194826: ethernet-input 
IP6: 8a:f6:cc:53:06:db -> 02:fe:6b:c4:db:06 
00:00:38:194848: ip6-input 
ICMP6: db00::2 -> db03::2 
tos 0x00, flow label 0x

Re: [vpp-dev] Regarding vnet/gre

[Neale Ranns]

Hi Vijay,

It is called from ipX-midchain.

/neale

From: Vijay Kumar 
Date: Tuesday, 25 May 2021 at 17:08
To: Neale Ranns 
Cc: vpp-dev 
Subject: Re: [vpp-dev] Regarding vnet/gre
Hi Neale,

Thanks for the useful input. I will implement a new fixup function similar to 
the one mentioned.
I believe the gre44_fixup function callback is registered via 
adj_nbr_midchain_update_rewrite()

I saw the code of adj-midchain-tx graph node but could not find the fixup 
function being called. Could you confirm which is the exact graph node that 
calls this fixup callback to process GRE headers?


Regards,
Vijay

On Tue, May 25, 2021 at 6:32 PM Neale Ranns 
mailto:ne...@graphiant.com>> wrote:

Hi Vijay,

I’d advise you to create a new fixup function (c.f. gre44_fixup) that deals 
with the extra headers you want.

/neale


From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> on behalf of Vijay Kumar via 
lists.fd.io 
mailto:gmail@lists.fd.io>>
Date: Tuesday, 25 May 2021 at 14:07
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Regarding vnet/gre
Hi,

I have a requirement to add extension fields (like QFI, RQI) into the GRE 
packet header leaving the VPP.
Upon analyzing the packet trace, I found that gre4_input graph node is called 
whenever GRE packets enter VPP but for outgoing packets, the GRE header is  
added by the tunnel's mid-chain adjacencies. There is no GRE graph node 
specifically for adding outgoing GRE header.

Is it a good idea to add code changes in the adj-midchain-tx node for adding 
new fields related to outgoing GRE packets?


Pls advise.


Thanks.
Vijay.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19469): https://lists.fd.io/g/vpp-dev/message/19469
Mute This Topic: https://lists.fd.io/mt/83074159/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] Regarding vnet/gre

[Vijay Kumar]

Thank you much Neale.

Your inputs really helped.





On Tue, May 25, 2021, 23:57 Neale Ranns  wrote:

>
>
> Hi Vijay,
>
>
>
> It is called from ipX-midchain.
>
>
>
> /neale
>
>
>
> *From: *Vijay Kumar 
> *Date: *Tuesday, 25 May 2021 at 17:08
> *To: *Neale Ranns 
> *Cc: *vpp-dev 
> *Subject: *Re: [vpp-dev] Regarding vnet/gre
>
> Hi Neale,
>
>
>
> Thanks for the useful input. I will implement a new fixup function similar
> to the one mentioned.
>
> I believe the gre44_fixup function callback is registered via
> *adj_nbr_midchain_update_rewrite()*
>
>
>
> I saw the code of *adj-midchain-tx* graph node but could not find the
> fixup function being called. Could you confirm which is the exact graph
> node that calls this fixup callback to process GRE headers?
>
>
>
>
>
> Regards,
>
> Vijay
>
>
>
> On Tue, May 25, 2021 at 6:32 PM Neale Ranns  wrote:
>
>
>
> Hi Vijay,
>
>
>
> I’d advise you to create a new fixup function (c.f. gre44_fixup) that
> deals with the extra headers you want.
>
>
>
> /neale
>
>
>
>
>
> *From: *vpp-dev@lists.fd.io  on behalf of Vijay
> Kumar via lists.fd.io 
> *Date: *Tuesday, 25 May 2021 at 14:07
> *To: *vpp-dev 
> *Subject: *[vpp-dev] Regarding vnet/gre
>
> Hi,
>
>
>
> I have a requirement to add extension fields (like QFI, RQI) into the GRE
> packet header leaving the VPP.
>
> Upon analyzing the packet trace, I found that gre4_input graph node is
> called whenever GRE packets enter VPP but for outgoing packets, the GRE
> header is  added by the tunnel's mid-chain adjacencies. There is no GRE
> graph node specifically for adding outgoing GRE header.
>
>
>
> Is it a good idea to add code changes in the adj-midchain-tx node for
> adding new fields related to outgoing GRE packets?
>
>
>
>
>
> Pls advise.
>
>
>
>
>
> Thanks.
>
> Vijay.
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19470): https://lists.fd.io/g/vpp-dev/message/19470
Mute This Topic: https://lists.fd.io/mt/83074159/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-