Re: [vpp-dev] Issue while pushing code for gerrit review

[Pei, Yulong]

You need to use git-review version 1.28.0:

$ pip install git-review==1.28.0

Best Regards
Yulong Pei

From: vpp-dev@lists.fd.io  On Behalf Of Chinmaya Aggarwal
Sent: Wednesday, June 24, 2020 12:55 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Issue while pushing code for gerrit review

Hi,
I have raised an issue on VPP mailing list 
(https://lists.fd.io/g/vpp-dev/topic/74894689). I have done the fix for this 
issue and want to submit the fix for gerrit review. I followed the steps 
described in 
https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code#Pushing_Code_with_git_review
But, on executing the command "git review" we get the below error : -
root@ggnlabvm-hnsnfvsdn03:~/vpp# git review
remote: error: branch refs/publish/master/fix/vpp_topic_74477804:
remote: You need 'Create' rights to create new references.
remote: User: ChinmayaAgarwal
remote: Contact an administrator to fix the permissions
remote:
remote: Processing changes: refs: 1
remote: Processing changes: refs: 1, done
To ssh://gerrit.fd.io:29418/vpp
 ! [remote rejected] HEAD -> refs/publish/master/fix/vpp_topic_74477804 
(prohibited by Gerrit: not permitted: create)
error: failed to push some refs to 
'ssh://chinmayaagar...@gerrit.fd.io:29418/vpp'
Can anyone please suggest what is wrong here?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Issue while pushing code for gerrit review

[Chinmaya Aggarwal]

Hi,
I have raised an issue on VPP mailing list ( 
https://lists.fd.io/g/vpp-dev/topic/74894689 ). I have done the fix for this 
issue and want to submit the fix for gerrit review. I followed the steps 
described in 
https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code#Pushing_Code_with_git_review

But, on executing the command "git review" we get the below error : -
root@ggnlabvm-hnsnfvsdn03:~/vpp# git review
remote: error: branch refs/publish/master/fix/vpp_topic_74477804:
remote: You need 'Create' rights to create new references.
remote: User: ChinmayaAgarwal
remote: Contact an administrator to fix the permissions
remote:
remote: Processing changes: refs: 1
remote: Processing changes: refs: 1, done
To ssh://gerrit.fd.io:29418/vpp
! [remote rejected]     HEAD -> refs/publish/master/fix/vpp_topic_74477804 
(prohibited by Gerrit: not permitted: create)
error: failed to push some refs to 
'ssh://chinmayaagar...@gerrit.fd.io:29418/vpp'

Can anyone please suggest what is wrong here?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16799): https://lists.fd.io/g/vpp-dev/message/16799
Mute This Topic: https://lists.fd.io/mt/75076228/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] test/requirements-3.txt snnoyance

[Paul Vinciguerra]

Hi Damjan,

My personal solution is 'git-review -X 21208', 'make wipe-test test.
HTH,

On Tue, Jun 23, 2020 at 12:27 PM Damjan Marion via lists.fd.io  wrote:

> Folks,
>
> Every time I run “make test”, i need to deal with modifications in
> test/requirements-3.txt
>
> Even worse, if I do “git checkout -f”, i cannot run “make test” anymore
> until remove build-root/build-test.
>
> Any idea how to get a rid of that?
>
>
> $ git diff
> diff --git a/test/requirements-3.txt b/test/requirements-3.txt
> index a17c49fc3..896480387 100644
> --- a/test/requirements-3.txt
> +++ b/test/requirements-3.txt
> @@ -99,10 +99,6 @@ imagesize==1.2.0 \
>
>  
> --hash=sha256:6965f19a6a2039c7d48bca7dba2473069ff854c36ae6f19d2cde309d998228a1
> \
>
>  
> --hash=sha256:b1f6b5a4eab1f73479a50fb79fcf729514a900c341d8503d62a62dbc4127a2b1
> \
>  # via sphinx
> -importlib-metadata==1.6.0 \
> -
> --hash=sha256:2a688cbaa90e0cc587f1df48bdc97a6eadccdcd9c35fb3f976a09e3b5016d90f
> \
> -
> --hash=sha256:34513a8a0c4962bc66d35b359558fd8a5e10cd472d37aec5f66858addef32c1e
> \
> -# via flake8
>  jinja2==2.11.2 \
>
>  
> --hash=sha256:89aab215427ef59c34ad58735269eb58b1a5808103067f7bb9d5836c651b3bb0
> \
>
>  
> --hash=sha256:f0a4641d3cf955324a89c04f3d94663aa4d638abe8f733ecd3582848e1c37035
> \
> @@ -272,10 +268,6 @@ urllib3==1.25.9 \
>
>  
> --hash=sha256:3018294ebefce6572a474f0604c2021e33b3fd8006ecd11d62107a5d2a963527
> \
>
>  
> --hash=sha256:88206b0eb87e6d677d424843ac5209e3fb9d0190d0ee169599165ec25e9d9115
> \
>  # via requests
> -zipp==3.1.0 \
> -
> --hash=sha256:aa36550ff0c0b7ef7fa639055d797116ee891440eac1a56f378e2d3179e0320b
> \
> -
> --hash=sha256:c599e4d75c98f6798c509911d08a22e6c021d074469042177c8c86fb92eefd96
> \
> -# via importlib-metadata
>
>  # WARNING: The following packages were not pinned, but pip requires them
> to be
>  # pinned when the requirements file includes hashes. Consider using the
> --allow-unsafe flag.
>
>
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16798): https://lists.fd.io/g/vpp-dev/message/16798
Mute This Topic: https://lists.fd.io/mt/75063401/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] Having issues compiling 20.05.1 on Fedora 32

[Burt Silverman]

make build works for me on Fedora 32 and VPP master. I did some cleanup
first, not elegant but it works for me:

rm -rf build-root/*
git checkout .
make build

I think I saw the issue about openssl-devel and compat-openssl10-devel, but
somehow I did something that made the compat versions disappear. Probably
something with dnf, but I'm not sure.

I don't go beyond make build.

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

View/Reply Online (#16797): https://lists.fd.io/g/vpp-dev/message/16797
Mute This Topic: https://lists.fd.io/mt/75056324/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 Client C API

[Prashant Gajarampalli]

Thanks Mahdi for the pointers.

Regards,
Prashant


On Sun, Jun 21, 2020 at 10:28 PM Mahdi Varasteh 
wrote:

> Hi Prashant,
>
> I think a good example of VAPI, is the older sweetcomb[1] source code(
> i.e. the scvpp part of code[2]). It gives you the needed insight and it's a
> good starting point for using VAPI.
>
> Regards,
> Mahdi
>
> [1] https://github.com/FDio/sweetcomb/
> 
> [2] https://github.com/FDio/sweetcomb/tree/stable/1904/src/scvpp
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16796): https://lists.fd.io/g/vpp-dev/message/16796
Mute This Topic: https://lists.fd.io/mt/32808207/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] Having issues compiling 20.05.1 on Fedora 32

[carlito nueno]

just doing the normal calls does not work:
make install-dep
make install-ext-deps
make build
make pkg-rpm

So to get it working I read the Makefile and errors and this is what I am
doing now:

dnf -y update
dnf -y groupinstall 'Development Tools'
dnf -y install gcc gcc-c++ make
dnf -y install redhat-lsb glibc-static
dnf -y install apr-devel
dnf -y install numactl-devel
dnf -y install check check-devel boost boost-devel
dnf -y install selinux-policy selinux-policy-devel
dnf -y install cmake ninja-build libuuid-devel mbedtls-devel
dnf -y install dnf-utils
dnf -y install subunit subunit-devel python3-devel python3-ply
python3-virtualenv
# dnf -y install compat-openssl10-devel --- I am getting conflict between
this lib and openssl-devel
dnf -y install ccache chrpath libffi-devel rpm-build
make install-dep
make install-ext-deps
make build
make pkg-rpm

The Errors I am seeing:

Error:
 Problem: problem with installed package
openssl-devel-1:1.1.1g-1.fc32.x86_64
  - package compat-openssl10-devel-1:1.0.2o-9.fc32.i686 conflicts with
openssl-devel provided by openssl-devel-1:1.1.1g-1.fc32.x86_64
  - package compat-openssl10-devel-1:1.0.2o-9.fc32.i686 conflicts with
openssl-devel provided by openssl-devel-1:1.1.1d-7.fc32.x86_64
  - conflicting requests
  - package compat-openssl10-devel-1:1.0.2o-9.fc32.x86_64 conflicts with
openssl-devel provided by openssl-devel-1:1.1.1g-1.fc32.x86_64
  - package compat-openssl10-devel-1:1.0.2o-9.fc32.x86_64 conflicts with
openssl-devel provided by openssl-devel-1:1.1.1d-7.fc32.x86_64
(try to add '--allowerasing' to command line to replace conflicting
packages or '--skip-broken' to skip uninstallable packages)
make: *** [Makefile:329: install-dep] Error 1




== Build app/test-cmdline
  CC cmdline_test.o
  CC main.o
  CC main.o
  CC commands.o
  CC commands.o
  LD cmdline_test
/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_aesni_mb.a(rte_aesni_mb_pmd_ops.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/aesni_mb/aesni_mb_pmd_private.h:22:
multiple definition of `aesni_mb_logtype_driver';
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_aesni_mb.a(rte_aesni_mb_pmd.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/aesni_mb/aesni_mb_pmd_private.h:22:
first defined here
/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_aesni_gcm.a(aesni_gcm_pmd_ops.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h:23:
multiple definition of `aesni_gcm_logtype_driver';
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_aesni_gcm.a(aesni_gcm_pmd.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h:23:
first defined here
/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev_hw_access.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev_ops.h:19:
multiple definition of `otx2_cpt_ops';
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev_ops.h:19:
first defined here
/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev_hw_access.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev.h:41:
multiple definition of `otx2_cryptodev_driver_id';
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev.h:41:
first defined here
/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev_mbox.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev.h:41:
multiple definition of `otx2_cryptodev_driver_id';
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev.h:41:
first defined here
/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev_ops.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev.h:41:
multiple definition of `otx2_cryptodev_driver_id';
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev.h:41:
first defined here
/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86

[vpp-dev] test/requirements-3.txt snnoyance

[Damjan Marion via lists.fd.io]

Folks,

Every time I run “make test”, i need to deal with modifications in 
test/requirements-3.txt 

Even worse, if I do “git checkout -f”, i cannot run “make test” anymore until 
remove build-root/build-test.

Any idea how to get a rid of that?


$ git diff
diff --git a/test/requirements-3.txt b/test/requirements-3.txt
index a17c49fc3..896480387 100644
--- a/test/requirements-3.txt
+++ b/test/requirements-3.txt
@@ -99,10 +99,6 @@ imagesize==1.2.0 \
 
--hash=sha256:6965f19a6a2039c7d48bca7dba2473069ff854c36ae6f19d2cde309d998228a1 \
 
--hash=sha256:b1f6b5a4eab1f73479a50fb79fcf729514a900c341d8503d62a62dbc4127a2b1 \
 # via sphinx
-importlib-metadata==1.6.0 \
-
--hash=sha256:2a688cbaa90e0cc587f1df48bdc97a6eadccdcd9c35fb3f976a09e3b5016d90f \
-
--hash=sha256:34513a8a0c4962bc66d35b359558fd8a5e10cd472d37aec5f66858addef32c1e \
-# via flake8
 jinja2==2.11.2 \
 
--hash=sha256:89aab215427ef59c34ad58735269eb58b1a5808103067f7bb9d5836c651b3bb0 \
 
--hash=sha256:f0a4641d3cf955324a89c04f3d94663aa4d638abe8f733ecd3582848e1c37035 \
@@ -272,10 +268,6 @@ urllib3==1.25.9 \
 
--hash=sha256:3018294ebefce6572a474f0604c2021e33b3fd8006ecd11d62107a5d2a963527 \
 
--hash=sha256:88206b0eb87e6d677d424843ac5209e3fb9d0190d0ee169599165ec25e9d9115 \
 # via requests
-zipp==3.1.0 \
-
--hash=sha256:aa36550ff0c0b7ef7fa639055d797116ee891440eac1a56f378e2d3179e0320b \
-
--hash=sha256:c599e4d75c98f6798c509911d08a22e6c021d074469042177c8c86fb92eefd96 \
-# via importlib-metadata

 # WARNING: The following packages were not pinned, but pip requires them to be
 # pinned when the requirements file includes hashes. Consider using the 
--allow-unsafe flag.



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

View/Reply Online (#16794): https://lists.fd.io/g/vpp-dev/message/16794
Mute This Topic: https://lists.fd.io/mt/75063401/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 interface revisted.

[Christian Hopps]

Hi Neale,

It's maybe worth pointing this out: using policy based IPsec continues to work 
fine for me. What I had and lost is route based IPsec, i.e., a destination 
interface that directs traffic to an SA *without trying to 
"partially-implement" the tunnel mode SA functionality*.

The new code is making the assumption that a tunnel mode SA's encap function 
can be 1-1 replaced by an upstream IPIP encapsulating function. This assumption 
is what is breaking me b/c my ESP payload is not a simple single IP packet.

Each of my ESP payloads is an aggregate of IP packets sometimes padded 
sometimes fractional. These payloads are emitted on a fixed timed interval 
(which determines if there is padding or not) and encapsulated only upon being 
emitted. *Specifically* this cannot be driven by the users (inner) traffic or 
we've failed -- all of this is the function the IPTFS SA implements. All of 
this is coded and working for policy directed tunnel mode SAs. Having to 
somehow replicate this functionality in two places (one place for policy based, 
and then in some new tightly coupled encapsulating custom interface type) to 
support the vpp post 19.08 optimization couldn't be seen as being "cleaner" by 
any subjective measure I hope.

So, in order to make things work post 19.08 I'm going to have to (re-)introduce 
a new "iptfs" interface type to VPP, so that I can have traffic directed to my 
SA w/o any encapsulation being done beforehand. If the goal was to avoid 
requiring per-use case interface types I don't think it worked for me. 
Basically I'm going to have to put back what was removed, maybe with a few 
refinements since I'm there already. Will that be acceptable when I eventually 
try and upstream the code? There's also the distinct possibility that we can't 
get this extra work funded in which case it would then only be available 
externally based on 19.08 which would be a shame as this work is based on the 
what is being done in ipsecme WG of the IETF. I would guess this would be seen 
as a poor outcome by others too.

FWIW the GRE use-case was, and remains, a transport mode use of IPsec, so no 
extra assumptions are being made for that use case. The new code probably is an 
improvement for GRE with transport mode IPsec, but for the purpose of 
discussing IPsec tunnel mode functionality it's a bit distracting.

Thanks,
Chris.

> On Jun 23, 2020, at 8:51 AM, Neale Ranns (nranns)  wrote:
> 
> 
> Hi Chris,
> 
> On 22/06/2020 13:09, "Christian Hopps"  wrote:
> 
>> 
>> - It operates directly with the IPsec tunnel mode and transport mode SAs 
>> without needing to mangle the internal definition of SA tunnel into 
>> transport mode.
> 
>Do you have any comments on this point? This is what I was talking about 
> when I said a "cleaner abstraction".
> 
> 'cleaner' is a subjective term and subjective analysis is subject to bias; my 
> biases are clear. That's why I tried to frame this discussion with an 
> objective comparison of use case. First in what we can't do with ipip/gre 
> then in what we 'can't' do with xfrms.  More later..
> 
>> - CRITICAL: Its use does not impose any encapsulation on the traffic itself.
>> 
>> Critical implies that without this some use cases are impossible. What is it 
>> that cannot be done with the tunnel model?
> 
>- You can't tunnel non-singular IP traffic with IPIP (my use case requires 
> this) IOW "ipip-only" model assumes the ESP payload is a single IP packet 
> that will be wrapped with an outer IP packet.
> 
> More on this below...
> 
>- You can't do route based transport mode IPsec using ipip (my use case 
> doesn't require this).
> 
> That's true, but is that a use case? Route based VPNs apply to transit 
> traffic, as well as locally generated, and one shouldn't send transit traffic 
> using a transport mode SA, i.e. without encap that ensures it returns.
> 
>Both of these speak to the "more powerful abstraction" point.
> 
>- The xfrm interface allows for route-based selection, but also allows for 
> additional policy restrictions. This might be possible with IPIP model, but 
> again it doesn't seem as clean/obvious.
> 
> VPP supports policy based VPNs using an SPD attached to an interface. Any 
> interface type could be used.
> 
>There's a reason that linux went with this approach as their improvement 
> on the VTI interface, rather than just re-using IPIP tunnel after 
> re-interpreting tunnel mode SAs into transport mode SAs like the new VPP code 
> does. The latter makes assumptions about the IPsec tunnel mode payload and 
> generally feels like a restricted "works for me/good enough" solution, rather 
> than a clean abstraction one can build new use cases on (as I am trying to 
> do).
> 
> I'm sure that had compelling reasons, but do they translate to VPP? Were they 
> for architectural reasons that don't apply. For example, was the choice of a 
> new interface type required to support HW offload? I'll try and find more 
> info. Perhaps yo

Re: [vpp-dev] Sub Interface/VLAN receiving packets directly from the Interface and multi thread approach

[Dave Barach via lists.fd.io]

Configure vlan subif(s), and configure L2 mode.

Attach your feature code to the L2 input feature arc(s), and enable on the 
indicated sw_if_index(es):

 .arc_name  = "l2-input-ip4",
  .arc_name  = "l2-input-ip6",
  .arc_name  = "l2-input-nonip",

Before you mess around spinning up threads, see if the standard (aka zero-work) 
approach provides sufficient performance. Hardware RSS hashing across a set of 
standard worker threads tends to scale linearly with the number of worker 
threads, up to some ridiculous PPS rates.

Note that any specific NIC type may not handle small packets at line rate due 
to PCI-bus limitations. You can’t win at that game.

FWIW... Dave

From: vpp-dev@lists.fd.io  On Behalf Of RaviKiran Veldanda
Sent: Tuesday, June 23, 2020 8:39 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Sub Interface/VLAN receiving packets directly from the 
Interface and multi thread approach

Hi Team,
Any advice or pointer helps us to progress on this issue.
//Ravi
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] virtio interface can't send packet

[Chan Wai]

Dear all,
I tried using testpmd(virio-user) <--> (vhost-user)testpmd, this topology
works well.
these are my test command:
sudo ./testpmd -l 0-1 -n 4 --socket-mem 1024,1024 --no-pci --vdev
'eth_vhost0,iface=/tmp/sock0' --file-prefix=host  --single-file-segments --
-i
sudo ./testpmd -l 6-7 -n 4 --socket-mem 1024,1024 --no-pci
--vdev=virtio_user0,path=/tmp/sock0 --file-prefix=container
--single-file-segments -- -i

Then I changed testpmd(virtio-user) to VPP,  all packets VPP sent out would
be dropped.

By the way, I have tried
1. add single-file-segments for rte_eal_init
2.remove in-memory for rte_eal_init

But none of these 2 changes help.
Is there some wrong config in my test environment? Thanks.

Testing topology:
VPP(virtio-user) <--> (vhost-user) openvswitch/testpmd

startup.conf

heapsize 2G
> unix {
> nodaemon
> interactive
> cli-listen /run/vpp/cli.sock
> exec init.conf
> }
> cpu {
> workers 1
> }
> dpdk {
> no-pci
> vdev virtio_user0,path=/tmp/sock0,mac=00:11:22:33:44:10
> }


init.conf

> set interface ip address VirtioUser0 172.20.224.1/24
> set interface state VirtioUser0 up


The VPP log:

DBGvpp# show version
> vpp v20.05-release built by ubuntu on ubuntu-3 at 2020-06-19T07:16:33
> DBGvpp# show interface addr
> VirtioUser0 (up):
>   L3 172.20.224.1/24
> local0 (dn):
> DBGvpp# show interface
>   Name   IdxState  MTU (L3/IP4/IP6/MPLS)
> Counter  Count
> VirtioUser0   1  up  9000/0/0/0
> local00 down  0/0/0/0
> DBGvpp# show interface addr
> VirtioUser0 (up):
>   L3 172.20.224.1/24
> local0 (dn):
> DBGvpp# ping 172.20.224.10
> Statistics: 5 sent, 0 received, 100% packet loss
> DBGvpp# show interface
>   Name   IdxState  MTU (L3/IP4/IP6/MPLS)
> Counter  Count
> VirtioUser0   1  up  9000/0/0/0 tx
> packets 5
> tx
> bytes 210
> drops
>  5
> local00 down  0/0/0/0
> DBGvpp# show hardware-interfaces
>   NameIdx   Link  Hardware
> 0: format_dpdk_device:588: rte_eth_dev_rss_hash_conf_get returned -95
> VirtioUser01 up   VirtioUser0
>   Link speed: 10 Gbps
>   Ethernet address 00:11:22:33:44:10
>   Virtio User
> carrier up full duplex mtu 9206
> flags: admin-up pmd maybe-multiseg
> Devargs: path=/tmp/sock0,mac=00:11:22:33:44:10
> rx: queues 1 (max 1), desc 1024 (min 0 max 65535 align 1)
> tx: queues 1 (max 1), desc 1024 (min 0 max 65535 align 1)
> max rx packet len: 9728
> promiscuous: unicast off all-multicast off
> vlan offload: strip off filter off qinq off
> rx offload avail:  vlan-strip udp-cksum tcp-cksum tcp-lro jumbo-frame
> rx offload active: jumbo-frame
> tx offload avail:  vlan-insert udp-cksum tcp-cksum tcp-tso multi-segs
> tx offload active: multi-segs
> rss avail: none
> rss active:none
> tx burst function: virtio_xmit_pkts_inorder
> rx burst function: virtio_recv_pkts_inorder
> tx frames ok   5
> tx bytes ok  210
> extended stats:
>   tx good packets  5
>   tx good bytes  210
>   tx q0packets 5
>   tx q0bytes 210
>   tx q0 good packets   5
>   tx q0 good bytes   210
>   tx q0 broadcast packets  5
>   tx q0 undersize packets  5
> local0 0down  local0
>   Link speed: unknown
>   local
> DBGvpp# show physmem
>  used-pages 40 reserved-pages 8192 default-page-size 2MB lookup-page-size
> 2MB
>arena 'buffers-numa-0' pages 20 subpage-size 2MB numa-node 0 shared fd 4
>arena 'buffers-numa-1' pages 20 subpage-size 2MB numa-node 1 shared fd 5
> DBGvpp# show dpdk physmem
> Segment 8-0: IOVA:0x7fc13fe0, len:2097152, virt:0x7fc13fe0,
> socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0 fd:27
> Segment 8-1: IOVA:0x7fc14000, len:2097152, virt:0x7fc14000,
> socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0 fd:28
> Segment 12-0: IOVA:0x7fb13f60, len:2097152, virt:0x7fb13f60,
> socket_id:1, hugepage_sz:2097152, nchannel:0, nrank:0 fd:21
> Segment 12-1: IOVA:0x7fb13f80, len:2097152, virt:0x7fb13f80,
> socket_id:1, hugepage_sz:2097152, nchannel:0, nrank:0 fd:29
> Segment 12-2: IOVA:0x7fb13fa0, len:2097152, virt:0x7fb13fa0,
> socket_id:1, hu

Re: [vpp-dev] ipsec interface revisted.

[Neale Ranns via lists.fd.io]

Hi Chris,

On 22/06/2020 13:09, "Christian Hopps"  wrote:

> 
>  - It operates directly with the IPsec tunnel mode and transport mode SAs 
without needing to mangle the internal definition of SA tunnel into transport 
mode.

Do you have any comments on this point? This is what I was talking about 
when I said a "cleaner abstraction".

'cleaner' is a subjective term and subjective analysis is subject to bias; my 
biases are clear. That's why I tried to frame this discussion with an objective 
comparison of use case. First in what we can't do with ipip/gre then in what we 
'can't' do with xfrms.  More later..

>  - CRITICAL: Its use does not impose any encapsulation on the traffic 
itself.
>  
> Critical implies that without this some use cases are impossible. What is 
it that cannot be done with the tunnel model?

- You can't tunnel non-singular IP traffic with IPIP (my use case requires 
this) IOW "ipip-only" model assumes the ESP payload is a single IP packet that 
will be wrapped with an outer IP packet.

More on this below...

- You can't do route based transport mode IPsec using ipip (my use case 
doesn't require this).

That's true, but is that a use case? Route based VPNs apply to transit traffic, 
as well as locally generated, and one shouldn't send transit traffic using a 
transport mode SA, i.e. without encap that ensures it returns.

Both of these speak to the "more powerful abstraction" point.

- The xfrm interface allows for route-based selection, but also allows for 
additional policy restrictions. This might be possible with IPIP model, but 
again it doesn't seem as clean/obvious.

VPP supports policy based VPNs using an SPD attached to an interface. Any 
interface type could be used.

There's a reason that linux went with this approach as their improvement on 
the VTI interface, rather than just re-using IPIP tunnel after re-interpreting 
tunnel mode SAs into transport mode SAs like the new VPP code does. The latter 
makes assumptions about the IPsec tunnel mode payload and generally feels like 
a restricted "works for me/good enough" solution, rather than a clean 
abstraction one can build new use cases on (as I am trying to do).

I'm sure that had compelling reasons, but do they translate to VPP? Were they 
for architectural reasons that don't apply. For example, was the choice of a 
new interface type required to support HW offload? I'll try and find more info. 
Perhaps you have good source you can share.

In my case I want to insert myself into a place in the graph that appears 
to no longer exist. IPTFS is a tunnel that carriers multiple or fractional 
inner IP packets per outer IP packet -- this simply does not map to an IPIP 
interface, where it would easily map to an XFRM style interface. So it 
definitely is a loss of functionality.

... I don't follow your reasoning. Your feature runs in the ip4-output path of 
an interface. It will therefore, per-buffer, get;
1) an ip4 packet, because that's what the 'contract' of the ip4-output feature 
guarantees.
2) they will all be destined to the [single] peer that is reachable through the 
interface, because that's what routing has decided is the fate of these 
packets. Of course you are free to over-ride the routing decision if you wish, 
but at the end of the feature arc the tunnel's adjacency will ship the packet 
out the phy thru which the peer is reachable.
Now this applies regardless of the interface type. For example, if, and I'm not 
suggesting you do this, but if, you were to protect the tunnel with a tunnel 
mode SA, and in your feature vnet_buffer_advance'd away the first 20 bytes of 
buffer data, then, what you receive, would be functionally equivalent to the 
xfrm model, and what you transmit also the same; a packet to the peer. The 
difference being that in the ipip/gre model your feature is expected to produce 
a packet for the next node with those 20 bytes on the front. But in either case 
the next feature on the arc is expecting an ipv4 packet, because it expects the 
same guarantees your feature benefitted from. Which leads me to think that you 
are not using the existing esp4-encrypt node unmodified? In your current 
implementation, how do you communicate the change in packet type to the next 
node?

You say 'IPTFS is a tunnel', perhaps this is where our view point differs. I 
have a strong routing bias, and we're talking route based VPNs here __ the 
tunnel is used for routing, it is through the tunnel that the routes are 
advertised, and so the FIB chooses these tunnels to [load-balance] the traffic 
to. The fact that they are secured, or have IPTFS, or ACLs, or NAT or whatever 
else enabled on them is value add. The tunnel exists for routing, it is not 
created by one those features.

Additionally I'm worried there may be even newer changes being made in VPP 
that are making further assumptions (restrictions) based on the new "ipip-only" 
model (something to do with 

Re: [vpp-dev] Sub Interface/VLAN receiving packets directly from the Interface and multi thread approach

[RaviKiran Veldanda]

Hi Team,
Any advice or pointer helps us to progress on this issue.
//Ravi
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] problem with select of VPP #vpp

[agrinfeld]

Hi,

We started to work with VCL solution in version 20.05 and we are facing some 
troubles
We are trying to open VCL socket, to accept packets, process them and send the 
result to a third application
We are working with UDP sockets and our sequence is
1. vppcom_app_create()
2. vppcom_session_create(VPPCOM_PROTO_UDP, FALSE)
3. vppcom_session_bind()
4. while loop

a. vppcom_select()

b. vppcom_session_recvfrom()

c. send packet to third app

In that case if I’m sending less than 2000 Packets per second, everything is 
going smooth, if I’m sending 2001 Packets per second My program stuck in select 
and not getting back to work

After analyzing this situation I tried to do it in different way

1. vppcom_app_create()
2. vppcom_session_create(VPPCOM_PROTO_UDP, FALSE)
3. vppcom_session_bind()
4. vppcom_select()
5. while loop

b. vppcom_session_recvfrom()

c. send packet to third app

In that case I’m reaching 120,000 Packets per second, but if I’m trying to pass 
more, the vppcom_session_recvfrom stucks after a minute +- and not getting back

Am I doing something wrong in the procedure?

Can you help with it?

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

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

[vpp-dev] Having issues compiling 20.05.1 on Fedora 32

[carlito nueno]

Hi,

I am receiving the following error when compiling on fedora 32:

compiling using:
make install-dep
make install-ext-deps
make build
make pkg-rpm

/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_aesni_mb.a(rte_aesni_mb_pmd_ops.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/aesni_mb/aesni_mb_pmd_private.h:22:
multiple definition of `aesni_mb_logtype_driver';
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_aesni_mb.a(rte_aesni_mb_pmd.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/aesni_mb/aesni_mb_pmd_private.h:22:
first defined here
/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_aesni_gcm.a(aesni_gcm_pmd_ops.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h:23:
multiple definition of `aesni_gcm_logtype_driver';
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_aesni_gcm.a(aesni_gcm_pmd.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/aesni_gcm/aesni_gcm_pmd_private.h:23:
first defined here
/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev_hw_access.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev_ops.h:19:
multiple definition of `otx2_cpt_ops';
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev_ops.h:19:
first defined here
/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev_hw_access.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev.h:41:
multiple definition of `otx2_cryptodev_driver_id';
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev.h:41:
first defined here
/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev_mbox.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev.h:41:
multiple definition of `otx2_cryptodev_driver_id';
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev.h:41:
first defined here
/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev_ops.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev.h:41:
multiple definition of `otx2_cryptodev_driver_id';
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev.h:41:
first defined here
/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev_ops.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev_ops.h:19:
multiple definition of `otx2_cpt_ops';
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_octeontx2_crypto.a(otx2_cryptodev.o):/root/vpp/build/external/rpm/tmp/dpdk-20.02/drivers/crypto/octeontx2/otx2_cryptodev_ops.h:19:
first defined here
/usr/bin/ld:
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_caam_jr.a(caam_jr.o):(.bss+0x0):
multiple definition of `rta_sec_era';
/root/vpp/build/external/rpm/tmp/dpdk-20.02/x86_64-native-linuxapp-gcc/lib/librte_pmd_dpaa2_sec.a(dpaa2_sec_dpseci.o):(.data+0x0):
first defined here
collect2: error: ld returned 1 exit status
make[9]: *** [/root/vpp/build/external/rpm/tmp/dpdk-20.02/mk/rte.app.mk:446:
dpdk-pdump] Error 1
make[8]: *** [/root/vpp/build/external/rpm/tmp/dpdk-20.02/mk/
rte.subdir.mk:37: pdump] Error 2
make[8]: *** Waiting for unfinished jobs
collect2: error: ld returned 1 exit status
make[9]: *** [/root/vpp/build/external/rpm/tmp/dpdk-20.02/mk/rte.app.mk:446:
dpdk-procinfo] Error 1
make[8]: *** [/root/vpp/build/external/rpm/tmp/dpdk-20.02/mk/
rte.subdir.mk:37: proc-info] Error 2
collect2: error: ld returned 1 exit status
make[9]: *** [/root/vpp/build/external/rpm/tmp/dpdk-20.02/mk/rte.app.mk:446:
cmdline_test] Error 1
make[8]: *** [/root/vpp/build/external/rpm/tmp/dpdk-20.02/mk/
rte.subdir.mk:37: test-cmdline] Error 2
collect2: error: ld returned 1 exit status
make[9]: *** [/root/vpp/build/external/rpm/tmp/dpdk-20.02/mk/rte.app.mk:446:
test] Error 1
make[8]: *** [/root/vpp/build/externa