Re: [vpp-dev] getting a rid of vpe.api

2021-09-09 Thread Edward Warnicke 
+1 :)

>From the 'consumer of api' side... the 'catch all' nature of vpe.api makes
VPP less usable.  Proper modularity would improve that, and be a benefit
beyond the ones Damjan already mentioned.

That said, ccing the some of the GoVPP folks, because there are some
(hopefully quite tractable) issues to consider in downstream generated APIs.

Ed

On Thu, Sep 9, 2021 at 11:18 AM Damjan Marion via lists.fd.io  wrote:

>
> Guys,
>
> Can we get a rid of vpp/api/vpe.api and vpp/api/vpe_types.api by moving
> content to more
> appropriate places. I.e. some basic types and control_ping may be good
> candidate for vlibapi/.
>
> It is quite weird that we have dozens of plugins depending on header files
> autogenerated from the main executable directory….
>
> If we gat a rid of hardcoded dependencies like we have with APIs today, we
> will be able to modularize build. I.e. Florin asking to way to just build
> VCL….
>
>
> Any volunteers?
>
> Thanks,
>
> —
> Damjan
>
>
>
>
> 
>
>

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

[vpp-dev] getting a rid of vpe.api

2021-09-09 Thread Damjan Marion via lists.fd.io 

Guys,

Can we get a rid of vpp/api/vpe.api and vpp/api/vpe_types.api by moving content 
to more 
appropriate places. I.e. some basic types and control_ping may be good 
candidate for vlibapi/.

It is quite weird that we have dozens of plugins depending on header files 
autogenerated from the main executable directory….

If we gat a rid of hardcoded dependencies like we have with APIs today, we will 
be able to modularize build. I.e. Florin asking to way to just build VCL….


Any volunteers?

Thanks,

— 
Damjan




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20110): https://lists.fd.io/g/vpp-dev/message/20110
Mute This Topic: https://lists.fd.io/mt/85488417/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 2106 with Sanitizer enabled

2021-09-09 Thread chetan bhasin 
Hi Benoit,

Thanks a lot!

We are not observing any crash in the VPP TCP host stack after applying the
second patch provided by you with SANITIZER enabled build.

Thanks,
Chetan



On Wed, Sep 8, 2021 at 9:41 PM chetan bhasin via lists.fd.io
 wrote:

> Thanks Benoit.
>
> Actually Same out of tree plugins are working fine with SANITIZER Enabled
> on vpp 2101.
>
> Will update the result with the patch provided by you and test which
> Florin suggested .
>
> Thanks & Regards,
> Chetan
>
> On Wed, Sep 8, 2021 at 8:13 PM Benoit Ganne (bganne) 
> wrote:
>
>> Here is maybe a better fix: https://gerrit.fd.io/r/c/vpp/+/33693
>> My previous changeset was only hiding the underlying issue which is
>> arrays passed to vlib_buffer_enqueue_to_next() must be big enough to allow
>> for some overflow (because of the use of clib_mask_compare_u16() and
>> clib_mask_compare_u32() that overflow for optimization reasons).
>> This is usually fine for your typical VPP node which allocates
>> buffer[VLIB_FRAME_SIZE] and nexts[VLIB_FRAME_SIZE] but not when using
>> vectors.
>> This patch should actually fix the issue (and tests should pass), but
>> there might be better ways.
>> However I do not think the last issue reported by Chetan will be fixed
>> with that one, looks like a new one.
>> Chetan, Florin's request is good: do you reproduce it only with your
>> plugin (in which case that could be an issue in your plugin) or also with
>> stock VPP?
>>
>> ben
>>
>> > -Original Message-
>> > From: Florin Coras 
>> > Sent: mercredi 8 septembre 2021 08:39
>> > To: chetan bhasin 
>> > Cc: Benoit Ganne (bganne) ; vpp-dev > > d...@lists.fd.io>
>> > Subject: Re: [vpp-dev] VPP 2106 with Sanitizer enabled
>> >
>> > Hi Chetan,
>> >
>> > Something like the following should exercise using iperf and homegrown
>> > test apps most of the components of the host stack, i.e., vcl, session
>> > layer and the transports, including tcp:
>> >
>> > make test-debug VPP_EXTRA_CMAKE_ARGS=-DVPP_ENABLE_SANITIZE_ADDR=ON
>> CC=gcc-
>> > 10 TEST=vcl CACHE_OUTPUT=0
>> >
>> > Having said that, it seems some issue has creeped in since last time
>> I’ve
>> > tested (granted it’s been a long time). That is, most of the tests seems
>> > to fail but I’ve only checked without Benoit’s patch.
>> >
>> > Regards,
>> > Florin
>> >
>> >
>> >   On Sep 7, 2021, at 9:57 PM, chetan bhasin
>> > mailto:chetan.bhasin...@gmail.com> >
>> wrote:
>> >
>> >   Hi Florin ,
>> >
>> >   This issue is coming when we are testing with iperf traffic with
>> our
>> > plugins that involve VPP TCP Host stack (VPP 21.06).
>> >
>> >   What's the best way to test VPP TCP host stack with Sanitizer
>> > without involving our out of tree plugins ?
>> >
>> >
>> >   Thanks,
>> >   Chetan
>> >
>> >   On Tue, Sep 7, 2021 at 7:47 PM Florin Coras <
>> fcoras.li...@gmail.com
>> >  > wrote:
>> >
>> >
>> >   Hi Chetan,
>> >
>> >   Out of curiosity, is this while running some make test
>> (like
>> > the iperf3 one) or with actual traffic through vpp?
>> >
>> >   Regards,
>> >   Florin
>> >
>> >
>> >
>> >   On Sep 7, 2021, at 12:17 AM, chetan bhasin
>> > mailto:chetan.bhasin...@gmail.com> >
>> wrote:
>> >
>> >   Hi Ben,
>> >
>> >   After applying the patch , now its crashing at
>> below
>> > place
>> >
>> >
>> > static void
>> >   session_flush_pending_tx_buffers (session_worker_t * wrk,
>> >   vlib_node_runtime_t * node)
>> >   {
>> >   vlib_buffer_enqueue_to_next (wrk->vm, node,
>> wrk->pending_tx_buffers,
>> >
>> >   wrk->pending_tx_nexts,
>> >   vec_len (wrk->pending_tx_nexts));
>> >   vec_reset_length (wrk->pending_tx_buffers);
>> >   vec_reset_length (wrk->pending_tx_nexts);
>> >   }
>> >   Program received signal SIGSEGV, Segmentation
>> fault.
>> >   [Switching to Thread 0x7ffb527f9700 (LWP 27762)]
>> >   0x771db5c1 in
>> > __asan::FakeStack::AddrIsInFakeStack(unsigned long, unsigned long*,
>> > unsigned long*) () from /lib64/libasan.so.5
>> >   (gdb) bt
>> >   #0  0x771db5c1 in
>> > __asan::FakeStack::AddrIsInFakeStack(unsigned long, unsigned long*,
>> > unsigned long*) () from /lib64/libasan.so.5
>> >   #1  0x772c2a11 in
>> > __asan::ThreadStackContainsAddress(__sanitizer::ThreadContextBase*,
>> void*)
>> > () from /lib64/libasan.so.5
>> >   #2  0x772dcdc2 in
>> > __sanitizer::ThreadRegistry::FindThreadContextLocked(bool
>> > (*)(__sanitizer::ThreadContextBase*, void*), void*) () from
>> > /lib64/libasan.so.5
>> >   #3  0x772c3e5a in
>> > __asan::FindThreadByStackAddress(unsigned long) () from
>> > /lib64/libasan.so.5
>> >   #4  0x771d5fb6 in
>> >

Re: [vpp-dev] AVF interface creation fails on VFs with configured VLAN with newer i40e drivers

2021-09-09 Thread Damjan Marion via lists.fd.io 

On 09.09.2021., at 09:14, Juraj Linkeš 
mailto:juraj.lin...@pantheon.tech>> wrote:

Hi Damjan, vpp devs,

Upgrading to 2.15.9 i40e driver in CI (from Ubuntu's 2.8.20-k) makes AVF 
interface creation on VFs with configured VLANs fail:
2021/08/30 09:15:27:343 debug avf :91:04.1: request_queues: num_queue_pairs 
1
2021/08/30 09:15:27:434 debug avf :91:04.1: version: major 1 minor 1
2021/08/30 09:15:27:444 debug avf :91:04.1: get_vf_resources: bitmap 
0x180b80a1 (l2 wb-on-itr adv-link-speed vlan-v2 vlan rx-polling rss-pf 
offload-adv-rss-pf offload-fdir-pf)
2021/08/30 09:15:27:445 debug avf :91:04.1: get_vf_resources: num_vsis 1 
num_queue_pairs 1 max_vectors 5 max_mtu 0 vf_cap_flags 0xb0081 (l2 
adv-link-speed vlan rx-polling rss-pf) rss_key_size 52 rss_lut_size 64
2021/08/30 09:15:27:445 debug avf :91:04.1: get_vf_resources_vsi[0]: vsi_id 
27 num_queue_pairs 1 vsi_type 6 qset_handle 21 default_mac_addr 
ba:dc:0f:fe:02:11
2021/08/30 09:15:27:445 debug avf :91:04.1: disable_vlan_stripping
2021/08/30 09:15:27:559 error avf :00:00.0: error: avf_send_to_pf: error 
[v_opcode = 28, v_retval -5]
from avf_create_if: pci-addr :91:04.1

Syslog reveals a bit more:
Aug 30 09:15:27 s55-t13-sut1 kernel: [352169.781206] vfio-pci :91:04.1: 
enabling device ( -> 0002)
Aug 30 09:15:27 s55-t13-sut1 kernel: [352170.140729] i40e :91:00.0: Cannot 
disable vlan stripping when port VLAN is set
Aug 30 09:15:27 s55-t13-sut1 kernel: [352170.140737] i40e :91:00.0: VF 17 
failed opcode 28, retval: -5

It looks like this feature (vlan stripping on VFs with VLANs) was removed in 
later versions of the driver. I don't know what the proper solution here is, 
but adding a configuration option to not disable vlan stripping when creating 
AVF interface sound good to me.

I've documented this in https://jira.fd.io/browse/VPP-1995.

Can you try with 2.16.11 and report back same outputs?

I just updated https://github.com/dmarion/deb-i40e in case you are using it…

—
Damjan



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20108): https://lists.fd.io/g/vpp-dev/message/20108
Mute This Topic: https://lists.fd.io/mt/85479187/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] linking error in VPP af_xdp_plugin using system libbpf

2021-09-09 Thread Benoit Ganne (bganne) via lists.fd.io 
Yes so that was my thought as well: update the build rules so you can select 
either the libbpf we build or the libbpf from the system.
If you select the libbpf of the system, it makes more sense to use the dynamic 
one because of PIC but also because you'll benefit from security updates.
I think we already support this for DPDK, if you want to propose a patch to do 
the same for libbpf I am all for it 

ben

> -Original Message-
> From: Nicholas Brown 
> Sent: jeudi 9 septembre 2021 11:42
> To: Benoit Ganne (bganne) 
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] linking error in VPP af_xdp_plugin using system
> libbpf
> 
> 
> On Thu, 9 Sept 2021 at 10:26, Nicholas Brown   > wrote:
> 
> 
> 
> 
>   On Thu, 9 Sept 2021 at 08:48, Benoit Ganne (bganne)
> mailto:bga...@cisco.com> > wrote:
> 
> 
>   Hi Nick,
> 
>   > When attempting to build vpp against system libraries (dpdk,
> libbpf, etc)
>   > on Debian Bullseye I get the following error when building
> the
>   > af_xdp_plugin.so
>   > Is the af_xdp plugin doing something unusual with libbpf?
> 
>   Af_xdp_plugin.so is a dynamically loadable object (as all VPP
> plugins), hence libbpf.a must be compiled as PIC which is not the case
> here.
>   When you use VPP default build system, we compile libbpf.a as
> PIC and link against that.
> 
> 
> 
>   Hi Ben,
> 
>   Thanks for the tips.
> 
>   yes, I'd misread the debian build log for libbpf:
> https://buildd.debian.org/status/fetch.php?pkg=libbpf=amd64=0.3-
> 2=1610313206=0
>   Only the shared objects are build with PIC, the static library is
> not.
> 
> 
> 
>   What is the reason to use the system libbpf instead of the one
> we compile? Apart from PIC, libbpf itself is not stable yet so you could
> encounter more subtile incompatibilities down the road.
> 
> 
> 
> 
>   For the system I'm building I need the build to be reproducible and
> buildable in isolate. The layered vpp build system depends on downloading
> things from the internet during the build. The system will also be
> maintained for some time, so getting security updates for the likes of
> dpdk, libbpf, etc from the Debian system packages would also be important.
> 
> 
>   The following change allows me to build:
> 
> 
> 
>   diff --git a/src/plugins/af_xdp/CMakeLists.txt
> b/src/plugins/af_xdp/CMakeLists.txt
>   index cbe96aa59..ee1743bbe 100644
>   --- a/src/plugins/af_xdp/CMakeLists.txt
>   +++ b/src/plugins/af_xdp/CMakeLists.txt
>   @@ -18,7 +18,7 @@ if (NOT BPF_INCLUDE_DIR)
>endif()
> 
>set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS TRUE)
>   -vpp_plugin_find_library(af_xdp BPF_LIB libbpf.a)
>   +vpp_plugin_find_library(af_xdp BPF_LIB libbpf)
>vpp_plugin_find_library(af_xdp BPF_ELF_LIB elf)
>vpp_plugin_find_library(af_xdp BPF_Z_LIB z)
>if (NOT BPF_LIB OR NOT BPF_ELF_LIB OR NOT BPF_Z_LIB)
> 
> 
>   but something that supports both a local or system library build
> would be preferable.
> 
> 
> Actually I spoke too soon. :-) With this change it actually doesn't find
> the library and thus simply doesn't build the plugin.
> 
> -- -- libbpf library not found - af_xdp plugin disabled
> 
> 
> Thanks,
> Nick
> 
> 
>   Separately, does the VPP cmake definitions allow me to configure
> which plugins are built (perhaps with some -D option), so I disable
> certain ones?
> 
>   Thanks,
>   Nick
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20107): https://lists.fd.io/g/vpp-dev/message/20107
Mute This Topic: https://lists.fd.io/mt/85468297/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] linking error in VPP af_xdp_plugin using system libbpf

2021-09-09 Thread Nick Brown 
On Thu, 9 Sept 2021 at 10:26, Nicholas Brown  wrote:

>
>
> On Thu, 9 Sept 2021 at 08:48, Benoit Ganne (bganne) 
> wrote:
>
>> Hi Nick,
>>
>> > When attempting to build vpp against system libraries (dpdk, libbpf,
>> etc)
>> > on Debian Bullseye I get the following error when building the
>> > af_xdp_plugin.so
>> > Is the af_xdp plugin doing something unusual with libbpf?
>>
>> Af_xdp_plugin.so is a dynamically loadable object (as all VPP plugins),
>> hence libbpf.a must be compiled as PIC which is not the case here.
>> When you use VPP default build system, we compile libbpf.a as PIC and
>> link against that.
>>
>
> Hi Ben,
>
> Thanks for the tips.
>
> yes, I'd misread the debian build log for libbpf:
> https://buildd.debian.org/status/fetch.php?pkg=libbpf=amd64=0.3-2=1610313206=0
> Only the shared objects are build with PIC, the static library is not.
>
>
>> What is the reason to use the system libbpf instead of the one we
>> compile? Apart from PIC, libbpf itself is not stable yet so you could
>> encounter more subtile incompatibilities down the road.
>>
>>
> For the system I'm building I need the build to be reproducible and
> buildable in isolate. The layered vpp build system depends on downloading
> things from the internet during the build. The system will also be
> maintained for some time, so getting security updates for the likes of
> dpdk, libbpf, etc from the Debian system packages would also be important.
>
> The following change allows me to build:
>
> diff --git a/src/plugins/af_xdp/CMakeLists.txt
> b/src/plugins/af_xdp/CMakeLists.txt
> index cbe96aa59..ee1743bbe 100644
> --- a/src/plugins/af_xdp/CMakeLists.txt
> +++ b/src/plugins/af_xdp/CMakeLists.txt
> @@ -18,7 +18,7 @@ if (NOT BPF_INCLUDE_DIR)
>  endif()
>
>  set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS TRUE)
> -vpp_plugin_find_library(af_xdp BPF_LIB libbpf.a)
> +vpp_plugin_find_library(af_xdp BPF_LIB libbpf)
>  vpp_plugin_find_library(af_xdp BPF_ELF_LIB elf)
>  vpp_plugin_find_library(af_xdp BPF_Z_LIB z)
>  if (NOT BPF_LIB OR NOT BPF_ELF_LIB OR NOT BPF_Z_LIB)
>
> but something that supports both a local or system library build would be
> preferable.
>

Actually I spoke too soon. :-) With this change it actually doesn't find
the library and thus simply doesn't build the plugin.

-- -- libbpf library not found - af_xdp plugin disabled

Thanks,
Nick

Separately, does the VPP cmake definitions allow me to configure which
> plugins are built (perhaps with some -D option), so I disable certain ones?
>
> Thanks,
> Nick
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20106): https://lists.fd.io/g/vpp-dev/message/20106
Mute This Topic: https://lists.fd.io/mt/85468297/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] linking error in VPP af_xdp_plugin using system libbpf

2021-09-09 Thread Nick Brown 
On Thu, 9 Sept 2021 at 08:48, Benoit Ganne (bganne) 
wrote:

> Hi Nick,
>
> > When attempting to build vpp against system libraries (dpdk, libbpf, etc)
> > on Debian Bullseye I get the following error when building the
> > af_xdp_plugin.so
> > Is the af_xdp plugin doing something unusual with libbpf?
>
> Af_xdp_plugin.so is a dynamically loadable object (as all VPP plugins),
> hence libbpf.a must be compiled as PIC which is not the case here.
> When you use VPP default build system, we compile libbpf.a as PIC and link
> against that.
>

Hi Ben,

Thanks for the tips.

yes, I'd misread the debian build log for libbpf:
https://buildd.debian.org/status/fetch.php?pkg=libbpf=amd64=0.3-2=1610313206=0
Only the shared objects are build with PIC, the static library is not.


> What is the reason to use the system libbpf instead of the one we compile?
> Apart from PIC, libbpf itself is not stable yet so you could encounter more
> subtile incompatibilities down the road.
>
>
For the system I'm building I need the build to be reproducible and
buildable in isolate. The layered vpp build system depends on downloading
things from the internet during the build. The system will also be
maintained for some time, so getting security updates for the likes of
dpdk, libbpf, etc from the Debian system packages would also be important.

The following change allows me to build:

diff --git a/src/plugins/af_xdp/CMakeLists.txt
b/src/plugins/af_xdp/CMakeLists.txt
index cbe96aa59..ee1743bbe 100644
--- a/src/plugins/af_xdp/CMakeLists.txt
+++ b/src/plugins/af_xdp/CMakeLists.txt
@@ -18,7 +18,7 @@ if (NOT BPF_INCLUDE_DIR)
 endif()

 set_property(GLOBAL PROPERTY FIND_LIBRARY_USE_LIB64_PATHS TRUE)
-vpp_plugin_find_library(af_xdp BPF_LIB libbpf.a)
+vpp_plugin_find_library(af_xdp BPF_LIB libbpf)
 vpp_plugin_find_library(af_xdp BPF_ELF_LIB elf)
 vpp_plugin_find_library(af_xdp BPF_Z_LIB z)
 if (NOT BPF_LIB OR NOT BPF_ELF_LIB OR NOT BPF_Z_LIB)

but something that supports both a local or system library build would be
preferable.

Separately, does the VPP cmake definitions allow me to configure which
plugins are built (perhaps with some -D option), so I disable certain ones?

Thanks,
Nick

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20105): https://lists.fd.io/g/vpp-dev/message/20105
Mute This Topic: https://lists.fd.io/mt/85468297/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] IPSec input/output: default action for non-matching traffic

2021-09-09 Thread Juraj Linkeš 
A correction, I meant inbound rule, not input rule.

Juraj

From: Juraj Linkeš
Sent: Thursday, September 9, 2021 10:59 AM
To: 'Zachary Leaf' ; 'ne...@graphiant.com' 

Cc: vpp-dev 
Subject: RE: [vpp-dev] IPSec input/output: default action for non-matching 
traffic

Hi Neale,

Did you have a chance to look at this? For my part, I'm trying to figure out 
how to configure VPP with two DPDK interfaces where I would send bidirectional 
traffic (unencrypted, since the traffic generator in question (T-rex) can't 
send encrypted traffic yet) and I'd match an input rule in each direction - is 
this even possible?

Thanks,
Juraj

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Zachary Leaf
Sent: Tuesday, August 17, 2021 10:30 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] IPSec input/output: default action for non-matching traffic

Hi Neale/all,

I've noticed an inconsistency between the default behaviour for non-matching 
packets in the ipsec-input and ipsec-output nodes. I'm not sure if this 
intended or not.

The summary is:
- For ipsec-output, any non-matching packets are dropped by default with the 
same mechanism as per a matching DISCARD rule
- For ipsec-input, any non-matching packets are passed to the next node as if 
they matched a BYPASS rule

Below are some packet traces that show this behaviour. The setup is 2x 
interfaces configured as ip neighbors, with an SPD bound to each. Traffic 
entering an interface is routed through the other interface and vice-versa (see 
attached ipsec-default-drop.txt for full script).

When SPD contains only matching INBOUND BYPASS rules:
00:00:07:340457: dpdk-input
00:00:07:340523: ethernet-input
00:00:07:340566: ip4-input-no-checksum
00:00:07:340601: ipsec4-input-feature
  IPSEC_ESP: sa_id 0 spd 2 policy 1 spi 1000 (0x03e8) seq 3 <- MATCHED 
INBOUND RULE (policy 1)
00:00:07:340642: ip4-lookup
00:00:07:340667: ip4-rewrite
00:00:07:340680: ipsec4-output-feature
  spd 1 policy -1 <- DID NOT MATCH ANY RULES (policy -1)
00:00:07:340693: error-drop <- PACKET DROPPED
00:00:07:340707: drop

When SPD contains only matching OUTBOUND BYPASS rules:
00:00:11:759484: dpdk-input
00:00:11:759570: ethernet-input
00:00:11:759624: ip4-input-no-checksum
00:00:11:759654: ipsec4-input-feature
  UDP: sa_id 4294967295 spd 2 policy -1 spi 612811835 (0x2486c43b) seq 
748568697 < DID NOT MATCH (policy -1)
00:00:11:759689: ip4-lookup <- PACKET *NOT* DROPPED, PASSED ON AS NORMAL
00:00:11:759721: ip4-rewrite
00:00:11:759733: ipsec4-output-feature
  spd 1 policy 1 < MATCHED OUTBOUND RULE
00:00:11:759774: TenGigabitEthernet7/0/0-output
00:00:11:759801: TenGigabitEthernet7/0/0-tx

Looking at the code in ipsec_output.c, we can see that for non-matching 
packets, we call next_node_index = im->error_drop_node_index to drop the 
packet. In ipsec_input.c, we only increment the counter ipsec_unprocessed += 1 
and we move to the next packet as per a matching BYPASS rule. From what I can 
tell, this is the same for both ipv4/ipv6 traffic.

Looking at the IPSec RFC4301 [1], it seems to suggest that the default action 
for both non-matching inbound/output packets should be DISCARD.
e.g.
“Since the SPD-I is just a part of the SPD, if a packet that is looked up in 
the SPD-I cannot be matched to an entry there, then the packet MUST
be discarded” [2]

" ...  the SPD (or associated caches) MUST be consulted during the processing 
of all traffic that crosses the IPsec protection boundary, including IPsec 
management traffic.  If no policy is found in the SPD that matches a packet 
(for either inbound or outbound traffic), the packet MUST be discarded." [3]

"Every SPD SHOULD have a nominal, final entry that catches anything that is 
otherwise unmatched, and discards it.  This ensures that non-IPsec-protected 
traffic that arrives and does not match any SPD-I entry will be discarded." [4]

In the section 5.2.  Processing Inbound IP Traffic (unprotected-to-protected) 
[4], there is also a diagram that seems to support this.

Is there a reason that the input side is setup like this? Unless there is a 
good reason for allowing inbound traffic by default, I would propose to patch 
the ipsec-input node to align with ipsec-output and drop traffic by default.

Best,

Zach

[1]: https://datatracker.ietf.org/doc/html/rfc4301
[2]: https://datatracker.ietf.org/doc/html/rfc4301#section-4.4.1
[3]: https://datatracker.ietf.org/doc/html/rfc4301#section-5
[4]: https://datatracker.ietf.org/doc/html/rfc4301#section-5.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20104): https://lists.fd.io/g/vpp-dev/message/20104
Mute This Topic: https://lists.fd.io/mt/84943480/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] IPSec input/output: default action for non-matching traffic

2021-09-09 Thread Juraj Linkeš 
Hi Neale,

Did you have a chance to look at this? For my part, I'm trying to figure out 
how to configure VPP with two DPDK interfaces where I would send bidirectional 
traffic (unencrypted, since the traffic generator in question (T-rex) can't 
send encrypted traffic yet) and I'd match an input rule in each direction - is 
this even possible?

Thanks,
Juraj

From: vpp-dev@lists.fd.io  On Behalf Of Zachary Leaf
Sent: Tuesday, August 17, 2021 10:30 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] IPSec input/output: default action for non-matching traffic

Hi Neale/all,

I've noticed an inconsistency between the default behaviour for non-matching 
packets in the ipsec-input and ipsec-output nodes. I'm not sure if this 
intended or not.

The summary is:
- For ipsec-output, any non-matching packets are dropped by default with the 
same mechanism as per a matching DISCARD rule
- For ipsec-input, any non-matching packets are passed to the next node as if 
they matched a BYPASS rule

Below are some packet traces that show this behaviour. The setup is 2x 
interfaces configured as ip neighbors, with an SPD bound to each. Traffic 
entering an interface is routed through the other interface and vice-versa (see 
attached ipsec-default-drop.txt for full script).

When SPD contains only matching INBOUND BYPASS rules:
00:00:07:340457: dpdk-input
00:00:07:340523: ethernet-input
00:00:07:340566: ip4-input-no-checksum
00:00:07:340601: ipsec4-input-feature
  IPSEC_ESP: sa_id 0 spd 2 policy 1 spi 1000 (0x03e8) seq 3 <- MATCHED 
INBOUND RULE (policy 1)
00:00:07:340642: ip4-lookup
00:00:07:340667: ip4-rewrite
00:00:07:340680: ipsec4-output-feature
  spd 1 policy -1 <- DID NOT MATCH ANY RULES (policy -1)
00:00:07:340693: error-drop <- PACKET DROPPED
00:00:07:340707: drop

When SPD contains only matching OUTBOUND BYPASS rules:
00:00:11:759484: dpdk-input
00:00:11:759570: ethernet-input
00:00:11:759624: ip4-input-no-checksum
00:00:11:759654: ipsec4-input-feature
  UDP: sa_id 4294967295 spd 2 policy -1 spi 612811835 (0x2486c43b) seq 
748568697 < DID NOT MATCH (policy -1)
00:00:11:759689: ip4-lookup <- PACKET *NOT* DROPPED, PASSED ON AS NORMAL
00:00:11:759721: ip4-rewrite
00:00:11:759733: ipsec4-output-feature
  spd 1 policy 1 < MATCHED OUTBOUND RULE
00:00:11:759774: TenGigabitEthernet7/0/0-output
00:00:11:759801: TenGigabitEthernet7/0/0-tx

Looking at the code in ipsec_output.c, we can see that for non-matching 
packets, we call next_node_index = im->error_drop_node_index to drop the 
packet. In ipsec_input.c, we only increment the counter ipsec_unprocessed += 1 
and we move to the next packet as per a matching BYPASS rule. From what I can 
tell, this is the same for both ipv4/ipv6 traffic.

Looking at the IPSec RFC4301 [1], it seems to suggest that the default action 
for both non-matching inbound/output packets should be DISCARD.
e.g.
“Since the SPD-I is just a part of the SPD, if a packet that is looked up in 
the SPD-I cannot be matched to an entry there, then the packet MUST
be discarded” [2]

" ...  the SPD (or associated caches) MUST be consulted during the processing 
of all traffic that crosses the IPsec protection boundary, including IPsec 
management traffic.  If no policy is found in the SPD that matches a packet 
(for either inbound or outbound traffic), the packet MUST be discarded." [3]

"Every SPD SHOULD have a nominal, final entry that catches anything that is 
otherwise unmatched, and discards it.  This ensures that non-IPsec-protected 
traffic that arrives and does not match any SPD-I entry will be discarded." [4]

In the section 5.2.  Processing Inbound IP Traffic (unprotected-to-protected) 
[4], there is also a diagram that seems to support this.

Is there a reason that the input side is setup like this? Unless there is a 
good reason for allowing inbound traffic by default, I would propose to patch 
the ipsec-input node to align with ipsec-output and drop traffic by default.

Best,

Zach

[1]: https://datatracker.ietf.org/doc/html/rfc4301
[2]: https://datatracker.ietf.org/doc/html/rfc4301#section-4.4.1
[3]: https://datatracker.ietf.org/doc/html/rfc4301#section-5
[4]: https://datatracker.ietf.org/doc/html/rfc4301#section-5.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20103): https://lists.fd.io/g/vpp-dev/message/20103
Mute This Topic: https://lists.fd.io/mt/84943480/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] linking error in VPP af_xdp_plugin using system libbpf

2021-09-09 Thread Benoit Ganne (bganne) via lists.fd.io 
Hi Nick,

> When attempting to build vpp against system libraries (dpdk, libbpf, etc)
> on Debian Bullseye I get the following error when building the
> af_xdp_plugin.so
> Is the af_xdp plugin doing something unusual with libbpf?

Af_xdp_plugin.so is a dynamically loadable object (as all VPP plugins), hence 
libbpf.a must be compiled as PIC which is not the case here.
When you use VPP default build system, we compile libbpf.a as PIC and link 
against that.
What is the reason to use the system libbpf instead of the one we compile? 
Apart from PIC, libbpf itself is not stable yet so you could encounter more 
subtile incompatibilities down the road.

Best
ben

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

[vpp-dev] AVF interface creation fails on VFs with configured VLAN with newer i40e drivers

2021-09-09 Thread Juraj Linkeš 
Hi Damjan, vpp devs,

Upgrading to 2.15.9 i40e driver in CI (from Ubuntu's 2.8.20-k) makes AVF 
interface creation on VFs with configured VLANs fail:
2021/08/30 09:15:27:343 debug avf :91:04.1: request_queues: num_queue_pairs 
1
2021/08/30 09:15:27:434 debug avf :91:04.1: version: major 1 minor 1
2021/08/30 09:15:27:444 debug avf :91:04.1: get_vf_resources: bitmap 
0x180b80a1 (l2 wb-on-itr adv-link-speed vlan-v2 vlan rx-polling rss-pf 
offload-adv-rss-pf offload-fdir-pf)
2021/08/30 09:15:27:445 debug avf :91:04.1: get_vf_resources: num_vsis 1 
num_queue_pairs 1 max_vectors 5 max_mtu 0 vf_cap_flags 0xb0081 (l2 
adv-link-speed vlan rx-polling rss-pf) rss_key_size 52 rss_lut_size 64
2021/08/30 09:15:27:445 debug avf :91:04.1: get_vf_resources_vsi[0]: vsi_id 
27 num_queue_pairs 1 vsi_type 6 qset_handle 21 default_mac_addr 
ba:dc:0f:fe:02:11
2021/08/30 09:15:27:445 debug avf :91:04.1: disable_vlan_stripping
2021/08/30 09:15:27:559 error avf :00:00.0: error: avf_send_to_pf: error 
[v_opcode = 28, v_retval -5]
from avf_create_if: pci-addr :91:04.1

Syslog reveals a bit more:
Aug 30 09:15:27 s55-t13-sut1 kernel: [352169.781206] vfio-pci :91:04.1: 
enabling device ( -> 0002)
Aug 30 09:15:27 s55-t13-sut1 kernel: [352170.140729] i40e :91:00.0: Cannot 
disable vlan stripping when port VLAN is set
Aug 30 09:15:27 s55-t13-sut1 kernel: [352170.140737] i40e :91:00.0: VF 17 
failed opcode 28, retval: -5

It looks like this feature (vlan stripping on VFs with VLANs) was removed in 
later versions of the driver. I don't know what the proper solution here is, 
but adding a configuration option to not disable vlan stripping when creating 
AVF interface sound good to me.

I've documented this in https://jira.fd.io/browse/VPP-1995.

Thanks,
Juraj

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20101): https://lists.fd.io/g/vpp-dev/message/20101
Mute This Topic: https://lists.fd.io/mt/85479187/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] Question regarding ip4/ip6 nexthop load balance flexibility #vnet

2021-09-09 Thread Venky Venkatesh 
Hi Neale,
Thanks for the clarification on the graph node usage (recursive vs
non-recursive routes). Here are some of the characteristics of the
situation we are interested in:

   1. No recursive routes
   2. For some of the schemes we need control on the hash calculation
   (ip_flow_hash_set may not meet our needs in those cases)
   3. The approach #2 that you mention can be an option for some of the
   schemes. However we would need a large number of buckets (anywhere between
   1K-32K depending on the situation). If we go down that path, we would need
   an atomic switch between the old bucket contents to the new bucket contents.
   4. We have multiple VRFs and this scheme can vary depending on the VRF
   5. In addition, even within the same VRF, different prefixes may be
   using different schemes (i.e. hashing and bucket selection). As far as the
   number of prefixes are concerned our use case isn't heavy on the number of
   routes/prefixes


Hope this helps you providing the appropriate guidance on architecturally
right way to make changes
Thanks
-Venky

On Wed, Sep 8, 2021 at 4:55 AM Neale Ranns  wrote:

> Hi Venky,
>
>
>
> Which nodes get called depends on the nature of the route. Take this
> trivial example
>
>
>
> DBGvpp# set int state loop0 up
>
> DBGvpp# set int ip addr loop0 10.0.0.1/24
>
>
>
> This route is non recursive
>
>
>
> DBGvpp# ip route 1.1.1.1/32 via 10.0.0.2 loop0
>
>
>
> This one is recursive
>
>
>
> DBGvpp# ip route 2.2.2.2/32 via 10.0.0.2
>
>
>
> You can see the DPO graph built for them is different.
>
>
>
> DBGvpp# sh ip fib 1.1.1.1
>
> ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ]
> epoch:0 flags:none locks:[recursive-resolution:1, default-route:1, ]
>
> 1.1.1.1/32 fib:0 index:11 locks:2
>
>   CLI refs:1 src-flags:added,contributing,active,
>
> path-list:[16] locks:2 flags:shared, uPRF-list:12 len:1 itfs:[1, ]
>
>   path:[18] pl-index:16 ip4 weight=1 pref=0 attached-nexthop:
> oper-flags:resolved,
>
> 10.0.0.2 loop0
>
>   [@0]: arp-ipv4: via 10.0.0.2 loop0
>
>
>
>  forwarding:   unicast-ip4-chain
>
>   [@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:12 to:[0:0]]
>
> [0] [@3]: arp-ipv4: via 10.0.0.2 loop0
>
>
>
> This recursive prefix has an extra load-balanace object
>
>
>
> DBGvpp# sh ip fib 2.2.2.2
>
> ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ]
> epoch:0 flags:none locks:[recursive-resolution:1, default-route:1, ]
>
> 2.2.2.2/32 fib:0 index:12 locks:2
>
>   CLI refs:1 src-flags:added,contributing,active,
>
> path-list:[18] locks:2 flags:shared, uPRF-list:15 len:1 itfs:[1, ]
>
>   path:[20] pl-index:18 ip4 weight=1 pref=0 recursive:
> oper-flags:resolved,
>
> via 10.0.0.2 in fib:0 via-fib:13 via-dpo:[dpo-load-balance:14]
>
>
>
>  forwarding:   unicast-ip4-chain
>
>   [@0]: dpo-load-balance: [proto:ip4 index:15 buckets:1 uRPF:15 to:[0:0]]
>
> [0] [@12]: dpo-load-balance: [proto:ip4 index:14 buckets:1 uRPF:14
> to:[0:0]].   HERE
>
>   [0] [@3]: arp-ipv4: via 10.0.0.2 loop0
>
>
>
>
>
> The first LB in the DPO graph will be the one used in ip4-lookup the
> second one, when present, will be used in ip4-load-balance.
>
>
>
> The golden rule of forwarding is to do all the heavy lifting in the
> control-plane so you can do the absolute minimum in the DP, because down
> there extra work means worse performance. The load-balance bucket choice is
> basically choice = buckets[flow-hash & n_buckets], which is the minimum we
> can do. I would advise that you try and keep it this way by:
>
> 1 – choosing how the flow hash is calculated (see the list of ‘algorithms’
> available in ip_flow_hash_set)
>
> 2 – choosing in the CP how the buckets are populated.
>
>
>
> If 2. Is an option we can talk more about how you might go about doing
> that 
>
> Are you looking to change the bucket selection for all prefixes or most,
> some or a few?
>
>
>
> /neale
>
>
>
>
>
>
>
> *From: *Venky Venkatesh 
> *Date: *Tuesday, 7 September 2021 at 20:11
> *To: *Neale Ranns 
> *Cc: *vpp-dev@lists.fd.io 
> *Subject: *Re: [vpp-dev] Question regarding ip4/ip6 nexthop load balance
> flexibility #vnet
>
> Hi Neale,
>
> Thanks for getting back. I thought as much that cloning code (even though
> I do a graph node replacement) wouldn't have been the way it would be done
> by someone knowledgeable in the area.
>
>
>
> When I looked again at the code, the area I intended to change seems to be
> a node in itself. *Is this code for ECMP? (appears to be like that)*
>
>  VLIB_REGISTER_NODE
> 
> (ip4_load_balance_node
>