Re: [vpp-dev] Envoy transport socket support for vpp.

[Florin Coras]

Hi Rupesh, 

CC’ing Stephen and Ping who are working on this. 

Florin

> On Aug 5, 2019, at 4:36 AM, Rupesh Raghuvaran  
> wrote:
> 
> Hi,
> 
> I would like to know the current state of the support for envoy over vpp host 
> stack. Is there any open source transport socket support for vpp available 
> for envoy.
> 
> Thanks
> Rupesh  -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13661): https://lists.fd.io/g/vpp-dev/message/13661
> Mute This Topic: https://lists.fd.io/mt/32724370/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13674): https://lists.fd.io/g/vpp-dev/message/13674
Mute This Topic: https://lists.fd.io/mt/32724370/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] tracing packets of a specific 5-tuple

[Satya Murthy]

Thanks Dave for the inputs.

--
Thanks & Regards,
Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13673): https://lists.fd.io/g/vpp-dev/message/13673
Mute This Topic: https://lists.fd.io/mt/32744859/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] tracing packets of a specific 5-tuple

[Dave Barach via Lists.Fd.Io]

In your node, call vlib_trace_buffer (...) + vlib_add_trace(...) only if pkts 
match the N-tuple of interest.

VLIB_BUFFER_TRACE_TRAJECTORY_INIT(...) is historical, and is only effective if 
you edit src/vlib/buffer.d and rebuild. No harm in adding the line of code.

Packet tracing is not free.

That should do it.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Satya Murthy
Sent: Tuesday, August 6, 2019 12:38 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] tracing packets of a specific 5-tuple

Hi,

We have a custom graph node that receives packets from udp graph node and we 
would like to trace packets pertaining to a specific 5-tuple flow from our 
custom graph node point onwards.

Does following steps really possible to achieve for this functionality ?
1. Make the custom-graph node to enable tracing by using 
VLIB_BUFFER_TRACE_TRAJECTORY_INIT
2. add CLI option to give the 5-tuple data
3. Based on the give 5-tuple data, store this in the custom graph node
4. compare the packet with the 5-tuple data, and mark the buffer to be traced.
5. now onwards , all the other graph nodes will trace it.

Also, what % of impact on the data throughput with VPP tracing ?

--
Thanks & Regards,
Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13672): https://lists.fd.io/g/vpp-dev/message/13672
Mute This Topic: https://lists.fd.io/mt/32744859/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] tracing packets of a specific 5-tuple

[Satya Murthy]

Hi,

We have a custom graph node that receives packets from udp graph node and we 
would like to trace packets pertaining to a specific 5-tuple flow from our 
custom graph node point onwards.

Does following steps really possible to achieve for this functionality ?
1. Make the custom-graph node to enable tracing by using 
VLIB_BUFFER_TRACE_TRAJECTORY_INIT
2. add CLI option to give the 5-tuple data
3. Based on the give 5-tuple data, store this in the custom graph node
4. compare the packet with the 5-tuple data, and mark the buffer to be traced.
5. now onwards , all the other graph nodes will trace it.

Also, what % of impact on the data throughput with VPP tracing ?

--
Thanks & Regards,
Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13671): https://lists.fd.io/g/vpp-dev/message/13671
Mute This Topic: https://lists.fd.io/mt/32744859/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 Cross compilation (x86_64 -> aarch64)

[Nitin Saxena]

Hi,

  *   I didn't see an option in the root Makefile that would build just VPP 
without DPDK, but we want to support both.
As already described by Damjan in earlier mails, one can compile VPP without 
DPDK like below

  1.  git clone https://gerrit.fd.io/r/vpp;
  2.  Optional: cross compiled DPDK library present in $PWD/dpdk_cross/
  3.  mkdir ./vpp_cross; cd vpp_cross
  4.  cmake  -G Ninja -DCMAKE_PREFIX_PATH:PATH=$PWD/../dpdk_cross/ 
$PWD/../vpp/src/
  5.  ninja

In order to upstream above support for platform one has to add 
build-data/platforms/$(PLATFORM).mk.

However patch https://gerrit.fd.io/r/#/c/vpp/+/21035/ is trying to generate 
cross compiled DPDK through VPP build system which is different way of 
compiling VPP from the one I explained above.

Thanks,
Nitin
From: vpp-dev@lists.fd.io  On Behalf Of Juraj Linkeš
Sent: Friday, August 2, 2019 8:35 PM
To: vpp-dev@lists.fd.io
Subject: [EXT] [vpp-dev] VPP Cross compilation (x86_64 -> aarch64)

External Email

Hi VPP Devs,

I'm trying to understand how to implement support for cross compilation for 
aarch64. I've put together some changes that are finally cross compiling DPDK 
(https://gerrit.fd.io/r/#/c/vpp/+/21035/), but the compilation is failing when 
it doesn't find openssl headers:
In file included from 
/home/jlinkes/vpp/build-root/build-aarch64-aarch64/external/dpdk-19.05/drivers/crypto/qat/qat_sym.c:5:0:
/usr/include/openssl/evp.h:13:11: fatal error: openssl/opensslconf.h: No such 
file or directory
# include 
   ^~~
compilation terminated.

I've added locally cross compiled numalib to cflags and ldflags just to see how 
far I'd go with compilation. It seems that I'll need to do the same for not 
only openssl, but also the other dpdk dependencies (if I understand it 
correctly, I'll need at least ipseb-mb nasm) and possibly VPP dependencies.

I've seen some e-mails suggesting that I should produce my own 
platforms/.mk file, but not much about any other steps. I also see 
the CROSS_TOOLS var in build-root/Makefile (and the corresponding 
$(PLATFORM)_cross_tools), but I wasn't able to figure out how to use those - is 
that something I should look into? What are the actual dependencies that *need* 
to be cross compiled before attempting to cross compile vpp/dpdk? I'd like to 
understand a bit more about this before I attempt to possibly fit a circle into 
a square-shaped hole.

The goal here is to build VPP and DPDK (I didn't see an option in the root 
Makefile that would build just VPP without DPDK, but we want to support both) 
for generic armv8 linux target.

I'd appreciate it if someone looked at my WIP patch and told me what I'm doing 
wrong and what's missing.

Thanks,
Juraj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13670): https://lists.fd.io/g/vpp-dev/message/13670
Mute This Topic: https://lists.fd.io/mt/32691486/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 traffic backend

[Neale Ranns via Lists.Fd.Io]

De :  au nom de "amitmulay...@gmail.com" 

Date : lundi 5 août 2019 à 07:21
À : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev] ipsec traffic backend

Hello Guys
i wanted to ask how can i know if my ipsec is running with QAT (intel quick 
assist) traffic backend (i am sure that i have a cpu that supports it..)?

You need a QAT PCI card….

i'm sure that it is not OPEN SLL becouse i see dpdk on those outputs


 DBGvpp# show ipsec backends
IPsec ESP backends available:
   Name Index Active
 default openssl backend  0 no
   dpdk backend1 yes
DBGvpp# show dpdk crypto devices
crypto_aesni_mb0 crypto_aesni_mb up
  numa_node 0, max_queues 8
  free_resources 3, used_resources 1
  SYMMETRIC_CRYPTO, SYM_OPERATION_CHAINING, CPU_SSE, CPU_AESNI
  Cipher: aes-cbc-128, aes-cbc-192, aes-cbc-256, aes-ctr-128, aes-ctr-192, 
aes-ctr-256, aes-gcm-128, aes-gcm-192, aes-gcm-256
  Auth: md5-96, sha1-96, sha-256-128, sha-384-192, sha-512-25

DBGvpp# show dpdk crypto placement
Thread 0 (vpp_main):
  crypto_aesni_mb0 dev-id  0 inbound-queue  0 outbound-queue  1


DBGvpp# show log
2019/ 8/ 1 06:24:20:647 warn   dpdk   EAL init args: -c 2 -n 4 
--in-memory --vdev crypto_aesni_mb0 --file-prefix vpp --master-lcore 1
2019/ 8/ 1 06:24:23:365 notice dpdk   DPDK drivers found 6 ports...
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL: Some devices want iova as va 
but pa will be used because.. EAL: vfio-noiommu mode configured
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL: No free hugepages reported 
in hugepages-1048576kB
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL: No free hugepages reported 
in hugepages-1048576kB
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL: No free hugepages reported 
in hugepages-1048576kB
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL: VFIO support initialized
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL: WARNING! Base virtual 
address hint (0x141000 != 0x144000) not respected!
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL:This may cause issues 
with mapping memory into secondary processes
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL: WARNING! Base virtual 
address hint (0x1c40002000 != 0x1c8000) not respected!
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL:This may cause issues 
with mapping memory into secondary processes
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL: WARNING! Base virtual 
address hint (0x2480003000 != 0x24c000) not respected!
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL:This may cause issues 
with mapping memory into secondary processes
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL: WARNING! Base virtual 
address hint (0x2cc0064000 != 0x2cc020) not respected!
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL:This may cause issues 
with mapping memory into secondary processes
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL: WARNING! Base virtual 
address hint (0x30c02c5000 != 0x30c040) not respected!
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL:This may cause issues 
with mapping memory into secondary processes
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL: WARNING! Base virtual 
address hint (0x34c0526000 != 0x34c060) not respected!
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL:This may cause issues 
with mapping memory into secondary processes
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL: WARNING! Base virtual 
address hint (0x38c0787000 != 0x38c080) not respected!
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL:This may cause issues 
with mapping memory into secondary processes
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL:   Invalid NUMA socket, 
default to 0
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL:   using IOMMU type 1 (Type 1)
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL:   Invalid NUMA socket, 
default to 0
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL:   Invalid NUMA socket, 
default to 0
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL:   Invalid NUMA socket, 
default to 0
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL:   Invalid NUMA socket, 
default to 0
2019/ 8/ 1 06:24:23:378 notice dpdk   EAL:   Invalid NUMA socket, 
default to 0
2019/ 8/ 1 06:24:23:378 notice dpdk   Invalid port_id=6

cat /etc/vpp/startup.conf:
dpdk {
vdev crypto_aesni_mb0

… whose PCI address you specify here.

#vdev crypto_aesni_gcm_mb1
dev default {
 num-rx-desc 512
 num-tx-desc 512
}
num-mbufs 2
socket-mem 1024
}

DBGvpp# show version
vpp v19.01.2-release
does this all mean that im using QAT? or "regular" dpdk ?
this config uses a SW/virtual device
/neale


if not how can i make sure im using it?
thanks all !!

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all 

Re: [vpp-dev] Feature: Update of nat44 addresses VRF after changing VRF on interfaces #vpp #nat44

[Neale Ranns via Lists.Fd.Io]

Hi Dmitry,

It’s definitely a good idea to add changes that prevent things breaking  The 
question is how do you do it?
You’ll have noticed in your testing that the following sequence is disallowed:


DBGvpp# loop cre

DBGvpp# ip table add 2

DBGvpp# set int ip addr loop0 10.10.10.10/24

DBGvpp# set int ip table loop0 2

set interface ip table: IP addresses are still present on loop0

If you want to change the table bound to an interface first you have to remove 
all the addresses it has, i.e. we block the requested change – there are many 
use cases in VPP were it is implicit that a config must be fully undone before 
it can be redone. The alternative approach would be to internally remove the 
addresses, rebind the table, then reapply the addresses, i.e. we undo and redo 
existing config upon the change. (this doesn’t work for addresses since they 
might clash with other interfaces in the new VRF).

Which of these two approaches would you take?

Regards,
neale


De :  au nom de "Dmitry Vakhrushev via Lists.Fd.Io" 

Répondre à : "dmi...@netgate.com" 
Date : vendredi 2 août 2019 à 11:53
À : "vpp-dev@lists.fd.io" 
Cc : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev] Feature: Update of nat44 addresses VRF after changing VRF on 
interfaces #vpp #nat44

Hello!

I have a suggestion to add a feature to update NAT addresses VRF location when 
the VRF on the interface has been changed.
I've prepared a patch with a test which does it and checks this behavior.
I want to push these changes, but want to ask first of your opinion.
Is it a good point to add this change to VPP?

Test network map:
PC1 <--->  PC(VPP) <---> PC2

Used test sequence:
sw_interface_set_flags sw_if_index 2 admin-up
sw_interface_set_flags sw_if_index 3 admin-up
sw_interface_add_del_address sw_if_index 2 192.168.1.1/24
sw_interface_add_del_address sw_if_index 3 10.10.10.1/24
nat44_interface_add_del_feature sw_if_index 2 in
nat44_interface_add_del_feature sw_if_index 3 out
nat44_add_del_address_range 10.100.200.33

>> nat44_add_del_address_range 10.100.200.33 - this command add fib record to 
>> default VRF (0)

-> Now we change VRF tables on interfaces:
ip_table_add_del table 1 add
sw_interface_add_del_address sw_if_index 2 0.0.0.0/0 del del-all
sw_interface_set_table sw_if_index 2 vrf 1
sw_interface_add_del_address sw_if_index 2 10.10.10.1/24

sw_interface_add_del_address sw_if_index 3 0.0.0.0/0 del del-all
sw_interface_set_table sw_if_index 3 vrf 1
sw_interface_add_del_address sw_if_index 3 10.10.30.1/24

-> Now NAT address is left in VRF-0, but interfaces in other VRF and now NAT 
isn't working.

sw_interface_add_del_address sw_if_index 2 0.0.0.0/0 del del-all
sw_interface_set_table sw_if_index 2 vrf 0
sw_interface_add_del_address sw_if_index 2 10.10.10.1/24

sw_interface_add_del_address sw_if_index 3 0.0.0.0/0 del del-all
sw_interface_set_table sw_if_index 3 vrf 0
sw_interface_add_del_address sw_if_index 3 10.10.30.1/24

-> now NAT is working again.

P.S
NAT can be VRF independent (VRF = ~0) but the suggested case is possible too.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13668): https://lists.fd.io/g/vpp-dev/message/13668
Mute This Topic: https://lists.fd.io/mt/32688963/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Mute #nat44: https://lists.fd.io/mk?hashtag=nat44=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] flag day to enable API flag day process

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io]

Yesterday I forgot to notify

that the job [8] is fixed [9] now.


It will be kept non-voting for a week or so

to make sure no CRC surprises are about to get merged

just before the voting is enabled again.


Vratko.


[8] https://jenkins.fd.io/job/vpp-csit-verify-api-crc-master/

[9] https://gerrit.fd.io/r/c/csit/+/21060



From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
Sent: Thursday, August 1, 2019 16:35
To: vpp-api-...@lists.fd.io; vpp-dev@lists.fd.io; csit-dev
Cc: Dave Wallace (dwallac...@gmail.com); Ed Kern (ejk)
Subject: RE: flag day to enable API flag day process


> job is created

... but it quickly turned to non-voting,
because a recent merge [4] changed CRCs.
It has been reverted [5] since then,
but verifying everything is fixed [6] on CSIT side
is delayed [7].

Vratko.

[4] https://gerrit.fd.io/r/c/vpp/+/20946
[5] https://gerrit.fd.io/r/c/vpp/+/20997
[6] https://gerrit.fd.io/r/c/csit/+/21002
[7] https://lists.fd.io/g/vpp-dev/message/13642

From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
Sent: Wednesday, July 31, 2019 6:38 PM
To: 'vpp-api-...@lists.fd.io' ; 'vpp-dev@lists.fd.io' 
; 'csit-dev' 
Cc: 'Dave Wallace (dwallac...@gmail.com)' ; Ed Kern (ejk) 

Subject: RE: flag day to enable API flag day process

[1] is now merged, job is created, and I see [3] it passing.
Vratko.
[3] https://jenkins.fd.io/job/vpp-csit-verify-api-crc-master/2/console

From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
Sent: Wednesday, July 31, 2019 10:41 AM
To: 'vpp-api-...@lists.fd.io' 
mailto:vpp-api-...@lists.fd.io>>; 
'vpp-dev@lists.fd.io' mailto:vpp-dev@lists.fd.io>>; 
'csit-dev' mailto:csit-...@lists.fd.io>>
Cc: 'Dave Wallace (dwallac...@gmail.com)' 
mailto:dwallac...@gmail.com>>; Ed Kern (ejk) 
mailto:e...@cisco.com>>
Subject: RE: flag day to enable API flag day process

[0] is merged, but [1] is stuck due to [2].
Vratko.
[2] https://lists.fd.io/g/vpp-dev/message/13627

From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
Sent: Monday, July 22, 2019 7:14 PM
To: vpp-api-...@lists.fd.io; 
vpp-dev@lists.fd.io; csit-dev 
mailto:csit-...@lists.fd.io>>
Cc: Dave Wallace (dwallac...@gmail.com) 
mailto:dwallac...@gmail.com>>; Ed Kern (ejk) 
mailto:e...@cisco.com>>
Subject: flag day to enable API flag day process

The main API flag document: [0].

I have most of implementation ready,
see [1] and comments there.

The missing parts is e-mail alerting
and postponing main vpp verify jobs
until API check passes (older stable/ VPP branches
are tricky to support in that way).

Please review, I would like to merge very soon.

Keeping CSIT list updated without automated
verify jobs takes some effort,
and it is pointless to add CRC checking only into CSIT
if VPP is not gated against API changes.
That is why both CSIT and ci-management parts
have to be merged together.

I will add the missing features
once the new verification is enabled.

Vratko.

[0] https://gerrit.fd.io/r/18356
[1] https://gerrit.fd.io/r/20708
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13667): https://lists.fd.io/g/vpp-dev/message/13667
Mute This Topic: https://lists.fd.io/mt/32561359/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-