Re: [vpp-dev] Issues building latest master

[Sergio Gonzalez Monroy]

Hi,

So I gather that:
1. DPDK and the SW crypto libraries are building without errors
2. Only OpenSUSE displays this behavior.

Only thing I can think of is that configure has different default libdir 
directory in OpenSUSE?


Could you show the output of the following command:
grep "libdir:" 
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log


Regarding the option vpp_uses_dpdk_cryptodev_sw=yes, it is indeed not 
used anymore but I obviously missed some cleanup.


Thanks,
Sergio


On 11/08/2017 20:25, Burt Silverman wrote:
After updating my nasm, I am seeing the very same problem Marco is 
seeing. On openSUSE 42.3. Not seen on CentOS 7. Not seen on my VyOS 
system.


Burt

On Fri, Aug 11, 2017 at 10:36 AM, Marco Varlese 
mailto:marco.varl...@suse.com>> wrote:


Hi,

I am having troubles building the latest code off the master branch.

The commands I always use are:
> make bootstrap
> make build

I get this error:
cp: cannot stat
'/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-
l_crypto-2.18.0/install/lib/libisal_crypto.a': No such file or
directory

I noticed that once the compilation of DPDK completes the
libraries - as
suggested by the build process itself - are placed at:
/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-l_crypto-
2.18.0/install/lib64

So it looks like somewhere the build system is using "lib64" and
in another
place just "lib".

I wonder if something has changed and - in that case - what shall
I do?

Also, I noticed that setting the vpp_uses_dpdk_cryptodev_sw = no
in build-
date/platforms/vpp.mk  has no effect (e.g. whether
yes or no the build process
still builds the crypto stuff from DPDK). Is this a known behaviour?


Cheers,
Marco
___
vpp-dev mailing list
vpp-dev@lists.fd.io 
https://lists.fd.io/mailman/listinfo/vpp-dev





___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev



___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP compile error building vpp ipsec on Fed 26

[Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)]

Same happens on arch. At some point of time, openssl dropped the
definitions of some structures which vpp uses directly and made them
opaque to user, so instead of embedding them, application has to
hold pointers and use the suplied XXX_Init-like functions...

Regards,
Klement

Quoting Thomas F Herbert (2017-08-13 23:45:05)
>I am getting a compile error when building on Fedora 26.
> 
>I am building master commit 3f6ff19a30e9fbe5befb4cc3521d1812e5612197
> 
>With openssl-devel-1.1.0f-7.fc26.x86_64 installed.
> 
>  CC   vnet/ipsec/ipsec.lo
>In file included from
>
> /home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/ipsec.c:25:0:
>
> /home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:63:18:
>error: field ‘encrypt_ctx’ has incomplete type
>   EVP_CIPHER_CTX encrypt_ctx;
>  ^~~
>
> /home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:65:18:
>error: field ‘decrypt_ctx’ has incomplete type
>   EVP_CIPHER_CTX decrypt_ctx;
>  ^~~
>
> /home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:67:12:
>error: field ‘hmac_ctx’ has incomplete type
>   HMAC_CTX hmac_ctx;
>    ^~~~
>
> /home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:
>In function ‘esp_init’:
>
> /home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:274:7:
>error: implicit declaration of function ‘HMAC_CTX_init’; did you mean
>‘HMAC_CTX_new’? [-Werror=implicit-function-declaration]
>   HMAC_CTX_init (&(em->per_thread_data[thread_id].hmac_ctx));
>   ^
>   HMAC_CTX_new
>
> /home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:
>In function ‘hmac_calc’:
>
> /home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:301:3:
>error: ‘HMAC_Init’ is deprecated [-Werror=deprecated-declarations]
>   HMAC_Init (ctx, key, key_len, md);
>   ^
>In file included from /usr/include/openssl/opensslconf.h:42:0,
> from /usr/include/openssl/bn.h:31,
> from /usr/include/openssl/asn1.h:24,
> from /usr/include/openssl/objects.h:916,
> from /usr/include/openssl/evp.h:27,
> from /usr/include/openssl/hmac.h:15,
> from
>
> /home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:18,
> from
>
> /home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/ipsec.c:25:
>/usr/include/openssl/hmac.h:28:1: note: declared here
> DEPRECATEDIN_1_1_0(__owur int HMAC_Init(HMAC_CTX *ctx, const void *key,
>int len,
> ^
>cc1: all warnings being treated as errors
>make[6]: *** [Makefile:6098: vnet/ipsec/ipsec.lo] Error 1
>make[6]: *** Waiting for unfinished jobs
>make[6]: Leaving directory
>
> '/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root/build-vpp-native/vpp'
>make[5]: *** [Makefile:6979: all-recursive] Error 1
>make[5]: Leaving directory
>
> '/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root/build-vpp-native/vpp'
>make[4]: *** [Makefile:3562: all] Error 2
>make[4]: Leaving directory
>
> '/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root/build-vpp-native/vpp'
>make[3]: *** [Makefile:697: vpp-build] Error 2
>make[3]: Leaving directory
>'/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root'
>make[2]: *** [Makefile:933: install-packages] Error 1
>make[2]: Leaving directory
>'/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root'
>error: Bad exit status from /var/tmp/rpm-tmp.kz3qOs (%build)
> 
>...
> 
>--
>Thomas F Herbert
>NFV and Fast Data Planes
>Office of Technology
>Red Hat
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP compile error building vpp ipsec on Fed 26

[Sergio Gonzalez Monroy]

Hi Tom,

Some APIs currently used in VPP have been deprecated in OpenSSL 1.1, it 
would require some rework .


It seems there is already a Jira ticket for it VPP-569 



Thanks,
Sergio


On 13/08/2017 22:45, Thomas F Herbert wrote:


I am getting a compile error when building on Fedora 26.

I am building master commit 3f6ff19a30e9fbe5befb4cc3521d1812e5612197

With openssl-devel-1.1.0f-7.fc26.x86_64 installed.

  CC   vnet/ipsec/ipsec.lo
In file included from 
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/ipsec.c:25:0:
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:63:18: 
error: field ‘encrypt_ctx’ has incomplete type

   EVP_CIPHER_CTX encrypt_ctx;
  ^~~
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:65:18: 
error: field ‘decrypt_ctx’ has incomplete type

   EVP_CIPHER_CTX decrypt_ctx;
  ^~~
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:67:12: 
error: field ‘hmac_ctx’ has incomplete type

   HMAC_CTX hmac_ctx;
^~~~
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h: 
In function ‘esp_init’:
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:274:7: 
error: implicit declaration of function ‘HMAC_CTX_init’; did you mean 
‘HMAC_CTX_new’? [-Werror=implicit-function-declaration]

   HMAC_CTX_init (&(em->per_thread_data[thread_id].hmac_ctx));
   ^
   HMAC_CTX_new
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h: 
In function ‘hmac_calc’:
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:301:3: 
error: ‘HMAC_Init’ is deprecated [-Werror=deprecated-declarations]

   HMAC_Init (ctx, key, key_len, md);
   ^
In file included from /usr/include/openssl/opensslconf.h:42:0,
 from /usr/include/openssl/bn.h:31,
 from /usr/include/openssl/asn1.h:24,
 from /usr/include/openssl/objects.h:916,
 from /usr/include/openssl/evp.h:27,
 from /usr/include/openssl/hmac.h:15,
 from 
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:18,
 from 
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/ipsec.c:25:

/usr/include/openssl/hmac.h:28:1: note: declared here
 DEPRECATEDIN_1_1_0(__owur int HMAC_Init(HMAC_CTX *ctx, const void 
*key, int len,

 ^
cc1: all warnings being treated as errors
make[6]: *** [Makefile:6098: vnet/ipsec/ipsec.lo] Error 1
make[6]: *** Waiting for unfinished jobs
make[6]: Leaving directory 
'/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root/build-vpp-native/vpp'

make[5]: *** [Makefile:6979: all-recursive] Error 1
make[5]: Leaving directory 
'/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root/build-vpp-native/vpp'

make[4]: *** [Makefile:3562: all] Error 2
make[4]: Leaving directory 
'/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root/build-vpp-native/vpp'

make[3]: *** [Makefile:697: vpp-build] Error 2
make[3]: Leaving directory 
'/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root'

make[2]: *** [Makefile:933: install-packages] Error 1
make[2]: Leaving directory 
'/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root'

error: Bad exit status from /var/tmp/rpm-tmp.kz3qOs (%build)

...


--
*Thomas F Herbert*
NFV and Fast Data Planes
Office of Technology
*Red Hat*


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev



___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issues building latest master

[Marco Varlese]

>>> Sergio Gonzalez Monroy  08/14/17 9:17 AM 
>>> >>>
> Hi,
>
> So I gather that:
> 1. DPDK and the SW crypto libraries are building without errors
> 2. Only OpenSUSE displays this behavior.
> 
> Only thing I can think of is that configure has different default libdir 
> directory in OpenSUSE?
> 
> Could you show the output of the following command:
> grep "libdir:" 
> build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
>
mvarlese@linux-yk3w:~/repos/vpp> grep "libdir:"  
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
grep: build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log: No 
such file or directory

> Regarding the option vpp_uses_dpdk_cryptodev_sw=yes, it is indeed not 
> used anymore but I obviously missed some cleanup.
> 
> Thanks,
> Sergio


On 11/08/2017 20:25, Burt Silverman wrote:
> After updating my nasm, I am seeing the very same problem Marco is 
> seeing. On openSUSE 42.3. Not seen on CentOS 7. Not seen on my VyOS 
> system.
>
> Burt
>
> On Fri, Aug 11, 2017 at 10:36 AM, Marco Varlese 
> mailto:marco.varl...@suse.com>> wrote:
>
> Hi,
>
> I am having troubles building the latest code off the master branch.
>
> The commands I always use are:
> > make bootstrap
> > make build
>
> I get this error:
> cp: cannot stat
> '/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-
> l_crypto-2.18.0/install/lib/libisal_crypto.a': No such file or
> directory
>
> I noticed that once the compilation of DPDK completes the
> libraries - as
> suggested by the build process itself - are placed at:
> /home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-l_crypto-
> 2.18.0/install/lib64
>
> So it looks like somewhere the build system is using "lib64" and
> in another
> place just "lib".
>
> I wonder if something has changed and - in that case - what shall
> I do?
>
> Also, I noticed that setting the vpp_uses_dpdk_cryptodev_sw = no
> in build-
> date/platforms/vpp.mk  has no effect (e.g. whether
> yes or no the build process
> still builds the crypto stuff from DPDK). Is this a known behaviour?
>
>
> Cheers,
> Marco
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io 
> https://lists.fd.io/mailman/listinfo/vpp-dev
> 
>
>
>
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev





___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issues building latest master

[Marco Varlese]

Hi Sergio,

I tried on a different machine and I got this:

libdir: ${exec_prefix}/lib64

Thanks,
Marco


>>> Marco Varlese 08/14/17 10:04 AM >>>



>>> Sergio Gonzalez Monroy  08/14/17 9:17 AM 
>>> >>>
> Hi,
>
> So I gather that:
> 1. DPDK and the SW crypto libraries are building without errors
> 2. Only OpenSUSE displays this behavior.
> 
> Only thing I can think of is that configure has different default libdir 
> directory in OpenSUSE?
> 
> Could you show the output of the following command:
> grep "libdir:" 
> build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
>
mvarlese@linux-yk3w:~/repos/vpp> grep "libdir:"  
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
grep: build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log: No 
such file or directory

> Regarding the option vpp_uses_dpdk_cryptodev_sw=yes, it is indeed not 
> used anymore but I obviously missed some cleanup.
> 
> Thanks,
> Sergio


On 11/08/2017 20:25, Burt Silverman wrote:
> After updating my nasm, I am seeing the very same problem Marco is 
> seeing. On openSUSE 42.3. Not seen on CentOS 7. Not seen on my VyOS 
> system.
>
> Burt
>
> On Fri, Aug 11, 2017 at 10:36 AM, Marco Varlese 
> mailto:marco.varl...@suse.com>> wrote:
>
> Hi,
>
> I am having troubles building the latest code off the master branch.
>
> The commands I always use are:
> > make bootstrap
> > make build
>
> I get this error:
> cp: cannot stat
> '/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-
> l_crypto-2.18.0/install/lib/libisal_crypto.a': No such file or
> directory
>
> I noticed that once the compilation of DPDK completes the
> libraries - as
> suggested by the build process itself - are placed at:
> /home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-l_crypto-
> 2.18.0/install/lib64
>
> So it looks like somewhere the build system is using "lib64" and
> in another
> place just "lib".
>
> I wonder if something has changed and - in that case - what shall
> I do?
>
> Also, I noticed that setting the vpp_uses_dpdk_cryptodev_sw = no
> in build-
> date/platforms/vpp.mk  has no effect (e.g. whether
> yes or no the build process
> still builds the crypto stuff from DPDK). Is this a known behaviour?
>
>
> Cheers,
> Marco
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io 
> https://lists.fd.io/mailman/listinfo/vpp-dev
> 
>
>
>
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev




marco@linux-3s68:~/vpp> grep "libdir:"  
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
libdir: ${exec_prefix}/lib64


marco@linux-3s68:~/vpp> grep "libdir:"  
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
libdir: ${exec_prefix}/lib64






___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issues building latest master

[Sergio Gonzalez Monroy]

On 14/08/2017 09:04, Marco Varlese wrote:




Sergio Gonzalez Monroy  08/14/17 9:17 AM >>>

Hi,

So I gather that:
1. DPDK and the SW crypto libraries are building without errors
2. Only OpenSUSE displays this behavior.

Only thing I can think of is that configure has different default libdir
directory in OpenSUSE?

Could you show the output of the following command:
grep "libdir:"
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log


mvarlese@linux-yk3w:~/repos/vpp> grep "libdir:"  
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
grep: build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log: No 
such file or directory


Are you getting any errors before the missing library?
That file should exists after doing ./configure (part of building DPDK 
in VPP) for isa-l_crypto library.


Thanks,
Sergio


Regarding the option vpp_uses_dpdk_cryptodev_sw=yes, it is indeed not
used anymore but I obviously missed some cleanup.

Thanks,
Sergio


On 11/08/2017 20:25, Burt Silverman wrote:

After updating my nasm, I am seeing the very same problem Marco is
seeing. On openSUSE 42.3. Not seen on CentOS 7. Not seen on my VyOS
system.

Burt

On Fri, Aug 11, 2017 at 10:36 AM, Marco Varlese
mailto:marco.varl...@suse.com>> wrote:

 Hi,

 I am having troubles building the latest code off the master branch.

 The commands I always use are:
 > make bootstrap
 > make build

 I get this error:
 cp: cannot stat
 '/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-
 l_crypto-2.18.0/install/lib/libisal_crypto.a': No such file or
 directory

 I noticed that once the compilation of DPDK completes the
 libraries - as
 suggested by the build process itself - are placed at:
 /home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-l_crypto-
 2.18.0/install/lib64

 So it looks like somewhere the build system is using "lib64" and
 in another
 place just "lib".

 I wonder if something has changed and - in that case - what shall
 I do?

 Also, I noticed that setting the vpp_uses_dpdk_cryptodev_sw = no
 in build-
 date/platforms/vpp.mk  has no effect (e.g. whether
 yes or no the build process
 still builds the crypto stuff from DPDK). Is this a known behaviour?


 Cheers,
 Marco
 ___
 vpp-dev mailing list
 vpp-dev@lists.fd.io 
 https://lists.fd.io/mailman/listinfo/vpp-dev
 




___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev







___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issues building latest master

[Marco Varlese]

Hi Dave,

It is not missing (see my prev email). 
It's being placed in .../lib64 (I suppose correctly) when being built but then 
is looked into .../lib at cp (install?) time. By doing some manual magic I can 
get it to work but I can't find the place to fix this properly 


Regards,
Marco




>>> "Dave Barach (dbarach)"  08/11/17 9:31 PM >>>
  Where is that library located, or is it entirely missing? 
  
 If you find it, how about making a symbolic link?
  
 Thanks… Dave
  
  From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Burt Silverman
 Sent: Friday, August 11, 2017 3:26 PM
 To: Marco Varlese 
 Cc: vpp-dev 
 Subject: Re: [vpp-dev] Issues building latest master
  
  After updating my nasm, I am seeing the very same problem Marco is seeing. On 
openSUSE 42.3. Not seen on CentOS 7. Not seen on my VyOS system.
   
 
  Burt
 
 
   
  On Fri, Aug 11, 2017 at 10:36 AM, Marco Varlese  
wrote:
  Hi,
 
 I am having troubles building the latest code off the master branch.
 
 The commands I always use are:
 > make bootstrap
 > make build
 
 I get this error:
 cp: cannot stat '/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-
 l_crypto-2.18.0/install/lib/libisal_crypto.a': No such file or directory
 
 I noticed that once the compilation of DPDK completes the libraries - as
 suggested by the build process itself - are placed at:
 /home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-l_crypto-
 2.18.0/install/lib64
 
 So it looks like somewhere the build system is using "lib64" and in another
 place just "lib".
 
 I wonder if something has changed and - in that case - what shall I do?
 
 Also, I noticed that setting the vpp_uses_dpdk_cryptodev_sw = no in build-
 date/platforms/vpp.mk has no effect (e.g. whether yes or no the build process
 still builds the crypto stuff from DPDK). Is this a known behaviour?
 
 
 Cheers,
 Marco
 ___
 vpp-dev mailing list
 vpp-dev@lists.fd.io
 https://lists.fd.io/mailman/listinfo/vpp-dev
  
  
 
 
   


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issues building latest master

[Sergio Gonzalez Monroy]

On 14/08/2017 09:11, Marco Varlese wrote:

Hi Sergio,

I tried on a different machine and I got this:

libdir: ${exec_prefix}/lib64


That confirms that ./configure is setting a different libdir in OpenSUSE 
than RHEL/Ubuntu.


I'll fix that by forcing libdir to always be ${exec_prefix}/lib

Thanks,
Sergio


Thanks,
Marco



Marco Varlese 08/14/17 10:04 AM >>>




Sergio Gonzalez Monroy  08/14/17 9:17 AM >>>

Hi,

So I gather that:
1. DPDK and the SW crypto libraries are building without errors
2. Only OpenSUSE displays this behavior.

Only thing I can think of is that configure has different default libdir
directory in OpenSUSE?

Could you show the output of the following command:
grep "libdir:"
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log


mvarlese@linux-yk3w:~/repos/vpp> grep "libdir:"  
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
grep: build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log: No 
such file or directory


Regarding the option vpp_uses_dpdk_cryptodev_sw=yes, it is indeed not
used anymore but I obviously missed some cleanup.

Thanks,
Sergio


On 11/08/2017 20:25, Burt Silverman wrote:

After updating my nasm, I am seeing the very same problem Marco is
seeing. On openSUSE 42.3. Not seen on CentOS 7. Not seen on my VyOS
system.

Burt

On Fri, Aug 11, 2017 at 10:36 AM, Marco Varlese
mailto:marco.varl...@suse.com>> wrote:

 Hi,

 I am having troubles building the latest code off the master branch.

 The commands I always use are:
 > make bootstrap
 > make build

 I get this error:
 cp: cannot stat
 '/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-
 l_crypto-2.18.0/install/lib/libisal_crypto.a': No such file or
 directory

 I noticed that once the compilation of DPDK completes the
 libraries - as
 suggested by the build process itself - are placed at:
 /home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-l_crypto-
 2.18.0/install/lib64

 So it looks like somewhere the build system is using "lib64" and
 in another
 place just "lib".

 I wonder if something has changed and - in that case - what shall
 I do?

 Also, I noticed that setting the vpp_uses_dpdk_cryptodev_sw = no
 in build-
 date/platforms/vpp.mk  has no effect (e.g. whether
 yes or no the build process
 still builds the crypto stuff from DPDK). Is this a known behaviour?


 Cheers,
 Marco
 ___
 vpp-dev mailing list
 vpp-dev@lists.fd.io 
 https://lists.fd.io/mailman/listinfo/vpp-dev
 




___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev




marco@linux-3s68:~/vpp> grep "libdir:"  
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
 libdir: ${exec_prefix}/lib64


marco@linux-3s68:~/vpp> grep "libdir:"  
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
 libdir: ${exec_prefix}/lib64








___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issues building latest master

[Marco Varlese]

On Mon, 2017-08-14 at 08:17 +0100, Sergio Gonzalez Monroy wrote:
> 
> Hi,
> 
>   
> 
>   So I gather that:
> 
>   1. DPDK and the SW crypto libraries are building without errors
> 
>   2. Only OpenSUSE displays this behavior.
> 
>   
> 
>   Only thing I can think of is that configure has different default
>   libdir directory in OpenSUSE?
> 
>   
> 
>   Could you show the output of the following command:
> 
>   grep "libdir:" 
> build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
> 
>   
> 
>   Regarding the option vpp_uses_dpdk_cryptodev_sw=yes, it is indeed
>   not used anymore but I obviously missed some cleanup.

Is the latest code (post 17.05) requiring a specific IA platform to compile (due
to SSE/AVX instructions)?
I noticed that it needs a "Sandybridge" type of architecture. 

Below the error I get on a CORE I7 :

mvarlese@linux-yk3w:~/repos/vpp> make build
make[1]: Entering directory '/home/mvarlese/repos/vpp/build-root'
 Arch for platform 'vpp' is native 
 Finding source for dpdk 
 Makefile fragment found in /home/mvarlese/repos/vpp/build-
data/packages/dpdk.mk 
 Source found in /home/mvarlese/repos/vpp/dpdk 
 Arch for platform 'vpp' is native 
 Finding source for vpp 
 Makefile fragment found in /home/mvarlese/repos/vpp/build-
data/packages/vpp.mk 
 Source found in /home/mvarlese/repos/vpp/src 
 Configuring dpdk: nothing to do 
 Building dpdk: nothing to do 
 Installing dpdk 
make[2]: Entering directory '/home/mvarlese/repos/vpp/dpdk'
make install
make[3]: Entering directory '/home/mvarlese/repos/vpp/dpdk'
mkdir -p /home/mvarlese/repos/vpp/build-root/install-vpp_debug-native/dpdk/lib/
make -C /home/mvarlese/repos/vpp/build-root/build-vpp_debug-native/dpdk/intel-
ipsec-mb-0.45 -j NO_GCM=y
make[4]: Entering directory '/home/mvarlese/repos/vpp/build-root/build-
vpp_debug-native/dpdk/intel-ipsec-mb-0.45'
Making object file obj/mb_mgr_hmac_sha_224_submit_avx512.o 
nasm -o obj/mb_mgr_hmac_sha_224_submit_avx512.o -felf64 -Xgnu -gdwarf -DLINUX
-D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/
avx512/mb_mgr_hmac_sha_224_submit_avx512.asm
Making object file obj/mb_mgr_hmac_sha_256_submit_avx512.o 
nasm -o obj/mb_mgr_hmac_sha_256_submit_avx512.o -felf64 -Xgnu -gdwarf -DLINUX
-D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/
avx512/mb_mgr_hmac_sha_256_submit_avx512.asm
Making object file obj/mb_mgr_hmac_sha_384_submit_avx512.o 
nasm -o obj/mb_mgr_hmac_sha_384_submit_avx512.o -felf64 -Xgnu -gdwarf -DLINUX
-D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/
avx512/mb_mgr_hmac_sha_384_submit_avx512.asm
mb_mgr_hmac_sha_256_submit_avx512.asm:170:
avx512/mb_mgr_hmac_sha_256_submit_avx512.asm:170: error: parser: instruction
expected
error: parser: instruction expected
mb_mgr_hmac_sha_256_submit_avx512.asm:171:
avx512/mb_mgr_hmac_sha_256_submit_avx512.asm:171: error: symbol `vmovdqu32'
redefined
error: symbol `vmovdqu32' redefined
mb_mgr_hmac_sha_256_submit_avx512.asm:171:
avx512/mb_mgr_hmac_sha_256_submit_avx512.asm:171: error: parser: instruction
expected
error: parser: instruction expected
mb_mgr_hmac_sha_512_submit_avx512.asm:165: error: parser: instruction expected
mb_mgr_hmac_sha_512_submit_avx512.asm:166: error: symbol `vmovdqu32' redefined
mb_mgr_hmac_sha_512_submit_avx512.asm:166: error: parser: instruction expected
mb_mgr_hmac_sha_512_submit_avx512.asm:167: error: symbol `vmovdqu32' redefined
mb_mgr_hmac_sha_512_submit_avx512.asm:167: error: parser: instruction expected
mb_mgr_hmac_sha_512_submit_avx512.asm:168: error: symbol `vmovdqu32' redefined
mb_mgr_hmac_sha_512_submit_avx512.asm:168: error: parser: instruction expected
Making object file obj/mb_mgr_hmac_submit_avx512.o 
Making object file obj/mb_mgr_hmac_sha_512_submit_avx512.o 
Making object file obj/sha1_ni_x2_sse.o 
Makefile:273: recipe for target 'obj/mb_mgr_hmac_sha_224_submit_avx512.o' failed
make[4]: *** [obj/mb_mgr_hmac_sha_224_submit_avx512.o] Error 1
make[4]: *** Waiting for unfinished jobs
Makefile:273: recipe for target 'obj/mb_mgr_hmac_sha_256_submit_avx512.o' failed
make[4]: *** [obj/mb_mgr_hmac_sha_256_submit_avx512.o] Error 1
Makefile:273: recipe for target 'obj/mb_mgr_hmac_sha_384_submit_avx512.o' failed
make[4]: *** [obj/mb_mgr_hmac_sha_384_submit_avx512.o] Error 1
nasm -o obj/mb_mgr_hmac_sha_512_submit_avx512.o -felf64 -Xgnu -gdwarf -DLINUX
-D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/
avx512/mb_mgr_hmac_sha_512_submit_avx512.asm
nasm -o obj/mb_mgr_hmac_submit_avx512.o -felf64 -Xgnu -gdwarf -DLINUX
-D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/
avx512/mb_mgr_hmac_submit_avx512.asm
nasm -o obj/sha1_ni_x2_sse.o -felf64 -Xgnu -gdwarf -DLINUX -D__linux__
-Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/ sse/sha1_ni_x2_sse.asm
sse/sha1_ni_x2_sse.asm:167: error: parser: instruction expected
sse/sha1_ni_x2_sse.asm:

Re: [vpp-dev] Issues building latest master

[Sergio Gonzalez Monroy]

On 14/08/2017 09:25, Marco Varlese wrote:

On Mon, 2017-08-14 at 08:17 +0100, Sergio Gonzalez Monroy wrote:

Hi,

So I gather that:
1. DPDK and the SW crypto libraries are building without errors
2. Only OpenSUSE displays this behavior.

Only thing I can think of is that configure has different default 
libdir directory in OpenSUSE?


Could you show the output of the following command:
grep "libdir:" 
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log


Regarding the option vpp_uses_dpdk_cryptodev_sw=yes, it is indeed not 
used anymore but I obviously missed some cleanup.


Is the latest code (post 17.05) requiring a specific IA platform to 
compile (due to SSE/AVX instructions)?

I noticed that it needs a "Sandybridge" type of architecture.



Which nasm version are you using?

Thanks,
Sergio


Below the error I get on a CORE I7 :

mvarlese@linux-yk3w :~/repos/vpp> make build
make[1]: Entering directory '/home/mvarlese/repos/vpp/build-root'
 Arch for platform 'vpp' is native 
 Finding source for dpdk 
 Makefile fragment found in 
/home/mvarlese/repos/vpp/build-data/packages/dpdk.mk 

 Source found in /home/mvarlese/repos/vpp/dpdk 
 Arch for platform 'vpp' is native 
 Finding source for vpp 
 Makefile fragment found in 
/home/mvarlese/repos/vpp/build-data/packages/vpp.mk 

 Source found in /home/mvarlese/repos/vpp/src 
 Configuring dpdk: nothing to do 
 Building dpdk: nothing to do 
 Installing dpdk 
make[2]: Entering directory '/home/mvarlese/repos/vpp/dpdk'
make install
make[3]: Entering directory '/home/mvarlese/repos/vpp/dpdk'
mkdir -p 
/home/mvarlese/repos/vpp/build-root/install-vpp_debug-native/dpdk/lib/
make -C 
/home/mvarlese/repos/vpp/build-root/build-vpp_debug-native/dpdk/intel-ipsec-mb-0.45 
-j NO_GCM=y
make[4]: Entering directory 
'/home/mvarlese/repos/vpp/build-root/build-vpp_debug-native/dpdk/intel-ipsec-mb-0.45'

Making object file obj/mb_mgr_hmac_sha_224_submit_avx512.o
nasm -o obj/mb_mgr_hmac_sha_224_submit_avx512.o -felf64 -Xgnu -gdwarf 
-DLINUX -D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/ 
avx512/mb_mgr_hmac_sha_224_submit_avx512.asm

Making object file obj/mb_mgr_hmac_sha_256_submit_avx512.o
nasm -o obj/mb_mgr_hmac_sha_256_submit_avx512.o -felf64 -Xgnu -gdwarf 
-DLINUX -D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/ 
avx512/mb_mgr_hmac_sha_256_submit_avx512.asm

Making object file obj/mb_mgr_hmac_sha_384_submit_avx512.o
nasm -o obj/mb_mgr_hmac_sha_384_submit_avx512.o -felf64 -Xgnu -gdwarf 
-DLINUX -D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/ 
avx512/mb_mgr_hmac_sha_384_submit_avx512.asm
mb_mgr_hmac_sha_256_submit_avx512.asm:170: 
avx512/mb_mgr_hmac_sha_256_submit_avx512.asm:170: error: parser: 
instruction expected

error: parser: instruction expected
mb_mgr_hmac_sha_256_submit_avx512.asm:171: 
avx512/mb_mgr_hmac_sha_256_submit_avx512.asm:171: error: symbol 
`vmovdqu32' redefined

error: symbol `vmovdqu32' redefined
mb_mgr_hmac_sha_256_submit_avx512.asm:171: 
avx512/mb_mgr_hmac_sha_256_submit_avx512.asm:171: error: parser: 
instruction expected

error: parser: instruction expected
mb_mgr_hmac_sha_512_submit_avx512.asm:165: error: parser: instruction 
expected
mb_mgr_hmac_sha_512_submit_avx512.asm:166: error: symbol `vmovdqu32' 
redefined
mb_mgr_hmac_sha_512_submit_avx512.asm:166: error: parser: instruction 
expected
mb_mgr_hmac_sha_512_submit_avx512.asm:167: error: symbol `vmovdqu32' 
redefined
mb_mgr_hmac_sha_512_submit_avx512.asm:167: error: parser: instruction 
expected
mb_mgr_hmac_sha_512_submit_avx512.asm:168: error: symbol `vmovdqu32' 
redefined
mb_mgr_hmac_sha_512_submit_avx512.asm:168: error: parser: instruction 
expected

Making object file obj/mb_mgr_hmac_submit_avx512.o
Making object file obj/mb_mgr_hmac_sha_512_submit_avx512.o
Making object file obj/sha1_ni_x2_sse.o
Makefile:273: recipe for target 
'obj/mb_mgr_hmac_sha_224_submit_avx512.o' failed

make[4]: *** [obj/mb_mgr_hmac_sha_224_submit_avx512.o] Error 1
make[4]: *** Waiting for unfinished jobs
Makefile:273: recipe for target 
'obj/mb_mgr_hmac_sha_256_submit_avx512.o' failed

make[4]: *** [obj/mb_mgr_hmac_sha_256_submit_avx512.o] Error 1
Makefile:273: recipe for target 
'obj/mb_mgr_hmac_sha_384_submit_avx512.o' failed

make[4]: *** [obj/mb_mgr_hmac_sha_384_submit_avx512.o] Error 1
nasm -o obj/mb_mgr_hmac_sha_512_submit_avx512.o -felf64 -Xgnu -gdwarf 
-DLINUX -D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/ 
avx512/mb_mgr_hmac_sha_512_submit_avx512.asm
nasm -o obj/mb_mgr_hmac_submit_avx512.o -felf64 -Xgnu -gdwarf -DLINUX 
-D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/ 
avx512/mb_mgr_hmac_submit_avx512.asm
nasm -o obj/sha1_ni_x2_sse.o -felf64 -Xgnu -gdwarf -DLINUX -D__linux__ 
-Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/ sse/sha1_ni_x2_sse.asm

sse/sha1_ni_x2_sse.asm:167: error: parser: instruction expected
sse/sha1_

[vpp-dev] Do we have any plan to support DNAT

[Ni, Hongjun]

Hey guys,

Do we have any plan to support DNAT feature?

Thanks,
Hongjun
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issues building latest master

[Marco Varlese]

On Mon, 2017-08-14 at 09:37 +0100, Sergio Gonzalez Monroy wrote:
> 
> On 14/08/2017 09:25, Marco Varlese
>   wrote:
> 
> 
> 
> >   
> >   On Mon, 2017-08-14 at 08:17 +0100, Sergio Gonzalez Monroy
> > wrote:
> > 
> > > Hi,
> > > 
> > >   
> > > 
> > >   So I gather that:
> > > 
> > >   1. DPDK and the SW crypto libraries are building without
> > >   errors
> > > 
> > >   2. Only OpenSUSE displays this behavior.
> > > 
> > >   
> > > 
> > >   Only thing I can think of is that configure has different
> > >   default libdir directory in OpenSUSE?
> > > 
> > >   
> > > 
> > >   Could you show the output of the following command:
> > > 
> > >   grep "libdir:" 
> > > > > > build-root/build-vpp_debug-native/dpdk/isa-l_crypto-
2.18.0/config.log
> > > 
> > >   
> > > 
> > >   Regarding the option vpp_uses_dpdk_cryptodev_sw=yes, it is
> > >   indeed not used anymore but I obviously missed some cleanup.
> > > 
> > > 
> > > 
> >   
> > 
> >   
> > 
> >   Is the latest code (post 17.05) requiring a specific IA
> > platform to compile (due to SSE/AVX instructions)?
> > 
> >   I noticed that it needs a "Sandybridge" type of
> > architecture. 
> > 
> >   
> > 
> >   
> > 
> 
> 
> Which nasm version are you using?

mvarlese@linux-yk3w:~/repos/vpp> nasm -version
NASM version 2.10.09 compiled on Aug  4 2017

> > > > > > > 


Thanks,

Sergio



> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > 
  > > Below the error I get on a CORE I7 :

  > > 

  

  > > mvarlese@linux-yk3w:~/repos/vpp>
make build

  > > make[1]: Entering directory
'/home/mvarlese/repos/vpp/build-root'

  > >  Arch for platform 'vpp' is native 

  > >  Finding source for dpdk 

  > >  Makefile fragment found in
/home/mvarlese/repos/vpp/build-data/packages/dpdk.mk 

  > >  Source found in /home/mvarlese/repos/vpp/dpdk 

  > >  Arch for platform 'vpp' is native 

  > >  Finding source for vpp 

  > >  Makefile fragment found in
/home/mvarlese/repos/vpp/build-data/packages/vpp.mk 

  > >  Source found in /home/mvarlese/repos/vpp/src 

  > >  Configuring dpdk: nothing to do 

  > >  Building dpdk: nothing to do 

  > >  Installing dpdk 

  > > make[2]: Entering directory '/home/mvarlese/repos/vpp/dpdk'

  > > make install

  > > make[3]: Entering directory '/home/mvarlese/repos/vpp/dpdk'

  > > mkdir -p
/home/mvarlese/repos/vpp/build-root/install-vpp_debug-native/dpdk/lib/

  > > make -C
/home/mvarlese/repos/vpp/build-root/build-vpp_debug-native/dpdk/intel-ipsec-mb-0.45
-j NO_GCM=y

  > > make[4]: Entering directory
'/home/mvarlese/repos/vpp/build-root/build-vpp_debug-native/dpdk/intel-ipsec-mb-0.45'

  > > Making object file obj/mb_mgr_hmac_sha_224_submit_avx512.o 

  > > nasm -o obj/mb_mgr_hmac_sha_224_submit_avx512.o -felf64 -Xgnu
-gdwarf -DLINUX -D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/
-Iavx512/ -Isse/ avx512/mb_mgr_hmac_sha_224_submit_avx512.asm

  > > Making object file obj/mb_mgr_hmac_sha_256_submit_avx512.o 

  > > nasm -o obj/mb_mgr_hmac_sha_256_submit_avx512.o -felf64 -Xgnu
-gdwarf -DLINUX -D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/
-Iavx

Re: [vpp-dev] Issues building latest master

[Sergio Gonzalez Monroy]

On 14/08/2017 09:46, Marco Varlese wrote:

On Mon, 2017-08-14 at 09:37 +0100, Sergio Gonzalez Monroy wrote:

On 14/08/2017 09:25, Marco Varlese wrote:

On Mon, 2017-08-14 at 08:17 +0100, Sergio Gonzalez Monroy wrote:

Hi,

So I gather that:
1. DPDK and the SW crypto libraries are building without errors
2. Only OpenSUSE displays this behavior.

Only thing I can think of is that configure has different default 
libdir directory in OpenSUSE?


Could you show the output of the following command:
grep "libdir:" 
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log


Regarding the option vpp_uses_dpdk_cryptodev_sw=yes, it is indeed 
not used anymore but I obviously missed some cleanup.


Is the latest code (post 17.05) requiring a specific IA platform to 
compile (due to SSE/AVX instructions)?

I noticed that it needs a "Sandybridge" type of architecture.



Which nasm version are you using?


mvarlese@linux-yk3w :~/repos/vpp> nasm 
-version

NASM version 2.10.09 compiled on Aug  4 2017



You need at least NASM 2.12.02

Thanks,
Sergio




Thanks,
Sergio


Below the error I get on a CORE I7 :

mvarlese@linux-yk3w :~/repos/vpp> make build
make[1]: Entering directory '/home/mvarlese/repos/vpp/build-root'
 Arch for platform 'vpp' is native 
 Finding source for dpdk 
 Makefile fragment found in 
/home/mvarlese/repos/vpp/build-data/packages/dpdk.mk 

 Source found in /home/mvarlese/repos/vpp/dpdk 
 Arch for platform 'vpp' is native 
 Finding source for vpp 
 Makefile fragment found in 
/home/mvarlese/repos/vpp/build-data/packages/vpp.mk 

 Source found in /home/mvarlese/repos/vpp/src 
 Configuring dpdk: nothing to do 
 Building dpdk: nothing to do 
 Installing dpdk 
make[2]: Entering directory '/home/mvarlese/repos/vpp/dpdk'
make install
make[3]: Entering directory '/home/mvarlese/repos/vpp/dpdk'
mkdir -p 
/home/mvarlese/repos/vpp/build-root/install-vpp_debug-native/dpdk/lib/
make -C 
/home/mvarlese/repos/vpp/build-root/build-vpp_debug-native/dpdk/intel-ipsec-mb-0.45 
-j NO_GCM=y
make[4]: Entering directory 
'/home/mvarlese/repos/vpp/build-root/build-vpp_debug-native/dpdk/intel-ipsec-mb-0.45'

Making object file obj/mb_mgr_hmac_sha_224_submit_avx512.o
nasm -o obj/mb_mgr_hmac_sha_224_submit_avx512.o -felf64 -Xgnu 
-gdwarf -DLINUX -D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ 
-Isse/ avx512/mb_mgr_hmac_sha_224_submit_avx512.asm

Making object file obj/mb_mgr_hmac_sha_256_submit_avx512.o
nasm -o obj/mb_mgr_hmac_sha_256_submit_avx512.o -felf64 -Xgnu 
-gdwarf -DLINUX -D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ 
-Isse/ avx512/mb_mgr_hmac_sha_256_submit_avx512.asm

Making object file obj/mb_mgr_hmac_sha_384_submit_avx512.o
nasm -o obj/mb_mgr_hmac_sha_384_submit_avx512.o -felf64 -Xgnu 
-gdwarf -DLINUX -D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ 
-Isse/ avx512/mb_mgr_hmac_sha_384_submit_avx512.asm
mb_mgr_hmac_sha_256_submit_avx512.asm:170: 
avx512/mb_mgr_hmac_sha_256_submit_avx512.asm:170: error: parser: 
instruction expected

error: parser: instruction expected
mb_mgr_hmac_sha_256_submit_avx512.asm:171: 
avx512/mb_mgr_hmac_sha_256_submit_avx512.asm:171: error: symbol 
`vmovdqu32' redefined

error: symbol `vmovdqu32' redefined
mb_mgr_hmac_sha_256_submit_avx512.asm:171: 
avx512/mb_mgr_hmac_sha_256_submit_avx512.asm:171: error: parser: 
instruction expected

error: parser: instruction expected
mb_mgr_hmac_sha_512_submit_avx512.asm:165: error: parser: 
instruction expected
mb_mgr_hmac_sha_512_submit_avx512.asm:166: error: symbol `vmovdqu32' 
redefined
mb_mgr_hmac_sha_512_submit_avx512.asm:166: error: parser: 
instruction expected
mb_mgr_hmac_sha_512_submit_avx512.asm:167: error: symbol `vmovdqu32' 
redefined
mb_mgr_hmac_sha_512_submit_avx512.asm:167: error: parser: 
instruction expected
mb_mgr_hmac_sha_512_submit_avx512.asm:168: error: symbol `vmovdqu32' 
redefined
mb_mgr_hmac_sha_512_submit_avx512.asm:168: error: parser: 
instruction expected

Making object file obj/mb_mgr_hmac_submit_avx512.o
Making object file obj/mb_mgr_hmac_sha_512_submit_avx512.o
Making object file obj/sha1_ni_x2_sse.o
Makefile:273: recipe for target 
'obj/mb_mgr_hmac_sha_224_submit_avx512.o' failed

make[4]: *** [obj/mb_mgr_hmac_sha_224_submit_avx512.o] Error 1
make[4]: *** Waiting for unfinished jobs
Makefile:273: recipe for target 
'obj/mb_mgr_hmac_sha_256_submit_avx512.o' failed

make[4]: *** [obj/mb_mgr_hmac_sha_256_submit_avx512.o] Error 1
Makefile:273: recipe for target 
'obj/mb_mgr_hmac_sha_384_submit_avx512.o' failed

make[4]: *** [obj/mb_mgr_hmac_sha_384_submit_avx512.o] Error 1
nasm -o obj/mb_mgr_hmac_sha_512_submit_avx512.o -felf64 -Xgnu 
-gdwarf -DLINUX -D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ 
-Isse/ avx512/mb_mgr_hmac_sha_512_submit_avx512.asm
nasm -o obj/mb_mgr_hmac_submit_avx512.o -felf64 -Xgnu -gdwarf 
-DLINUX -D__linux__ -Iinclude/ -I./ 

Re: [vpp-dev] Issues building latest master

[Marco Varlese]

On Mon, 2017-08-14 at 09:50 +0100, Sergio Gonzalez Monroy wrote:
> 
> On 14/08/2017 09:46, Marco Varlese
>   wrote:
> 
> 
> 
> >   
> >   On Mon, 2017-08-14 at 09:37 +0100, Sergio Gonzalez Monroy
> > wrote:
> > 
> > > On 14/08/2017 09:25, Marco Varlese
> > >   wrote:
> > > 
> > > 
> > > 
> > > >   On Mon, 2017-08-14 at 08:17 +0100, Sergio Gonzalez Monroy
> > > > wrote:
> > > > 
> > > > > Hi,
> > > > > 
> > > > >   
> > > > > 
> > > > >   So I gather that:
> > > > > 
> > > > >   1. DPDK and the SW crypto libraries are building without
> > > > >   errors
> > > > > 
> > > > >   2. Only OpenSUSE displays this behavior.
> > > > > 
> > > > >   
> > > > > 
> > > > > > > > > >   Only thing I can think of is that configure 
> > > > > > > > > > has
different
> > > > >   default libdir directory in OpenSUSE?
> > > > > 
> > > > >   
> > > > > 
> > > > >   Could you show the output of the following command:
> > > > > 
> > > > >   grep "libdir:" 
> > > > > > > > > > 
> > > > > > > > > > build-root/build-vpp_debug-native/dpdk/isa-l_crypto-
2.18.0/config.log
> > > > > 
> > > > >   
> > > > > 
> > > > > > > > > >   Regarding the option 
> > > > > > > > > > vpp_uses_dpdk_cryptodev_sw=yes, it
is
> > > > >   indeed not used anymore but I obviously missed some
> > > > >   cleanup.
> > > > > 
> > > > > 
> > > > > 
> > > >   
> > > > 
> > > >   
> > > > 
> > > >   Is the latest code (post 17.05) requiring a specific IA
> > > > platform to compile (due to SSE/AVX instructions)?
> > > > 
> > > >   I noticed that it needs a "Sandybridge" type of
> > > > architecture. 
> > > > 
> > > >   
> > > > 
> > > >   
> > > > 
> > > 
> > > 
> > > Which nasm version are you using?
> > > 
> >   
> > 
> >   
> > 
> > > >   mvarlese@linux-yk3w:~/repos/vpp>
> > nasm -version
> > 
> >   NASM version 2.10.09 compiled on Aug  4 2017
> > 
> >   
> > 
> >   
> > 
> 
> 
> You need at least NASM 2.12.02
Ok; I will try again so. Will upgrade NASM and let you know if I encounter any
issues.

Cheers,
Marco

> > > > > > > > 


Thanks,

Sergio





> > > > 
  > > > > > > > > > > > > > > > > > > > > >  

Thanks,

Sergio



> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 

[vpp-dev] Missing libvppsocketwrapper library

[Tomáš Jančiga]

Hi all,
I'd like to test the host stack implemented in VPP using the LD_PRELOAD trick. 
It's used also by test/scripts/socket_test.sh but it uses wrapper library 
libvppsocketwrapper which is missing in VPP sources.
I'd like to ask you if you have some draft changes implementing the wrapper 
library I could test and when do you think you could merge it into VPP.

Thank you,
Tomas



Tomáš Jančiga
Staff Engineer

PANTHEON technologies s.r.o.
Mlynské Nivy 56, 821 05 Bratislava
Slovakia
Tel / +421 220 665 111

MAIL / tomas.janc...@pantheon.tech
WEB / https://pantheon.tech


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP compile error building vpp ipsec on Fed 26

[Thomas F Herbert]

On 08/14/2017 03:39 AM, Sergio Gonzalez Monroy wrote:

Hi Tom,

Some APIs currently used in VPP have been deprecated in OpenSSL 1.1, 
it would require some rework .


It seems there is already a Jira ticket for it VPP-569 


Thanks. I updated JIRA ticket with info below.


Thanks,
Sergio


On 13/08/2017 22:45, Thomas F Herbert wrote:


I am getting a compile error when building on Fedora 26.

I am building master commit 3f6ff19a30e9fbe5befb4cc3521d1812e5612197

With openssl-devel-1.1.0f-7.fc26.x86_64 installed.

  CC   vnet/ipsec/ipsec.lo
In file included from 
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/ipsec.c:25:0:
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:63:18: 
error: field ‘encrypt_ctx’ has incomplete type

   EVP_CIPHER_CTX encrypt_ctx;
  ^~~
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:65:18: 
error: field ‘decrypt_ctx’ has incomplete type

   EVP_CIPHER_CTX decrypt_ctx;
  ^~~
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:67:12: 
error: field ‘hmac_ctx’ has incomplete type

   HMAC_CTX hmac_ctx;
^~~~
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h: 
In function ‘esp_init’:
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:274:7: 
error: implicit declaration of function ‘HMAC_CTX_init’; did you mean 
‘HMAC_CTX_new’? [-Werror=implicit-function-declaration]

   HMAC_CTX_init (&(em->per_thread_data[thread_id].hmac_ctx));
   ^
   HMAC_CTX_new
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h: 
In function ‘hmac_calc’:
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:301:3: 
error: ‘HMAC_Init’ is deprecated [-Werror=deprecated-declarations]

   HMAC_Init (ctx, key, key_len, md);
   ^
In file included from /usr/include/openssl/opensslconf.h:42:0,
 from /usr/include/openssl/bn.h:31,
 from /usr/include/openssl/asn1.h:24,
 from /usr/include/openssl/objects.h:916,
 from /usr/include/openssl/evp.h:27,
 from /usr/include/openssl/hmac.h:15,
 from 
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/esp.h:18,
 from 
/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-data/../src/vnet/ipsec/ipsec.c:25:

/usr/include/openssl/hmac.h:28:1: note: declared here
 DEPRECATEDIN_1_1_0(__owur int HMAC_Init(HMAC_CTX *ctx, const void 
*key, int len,

 ^
cc1: all warnings being treated as errors
make[6]: *** [Makefile:6098: vnet/ipsec/ipsec.lo] Error 1
make[6]: *** Waiting for unfinished jobs
make[6]: Leaving directory 
'/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root/build-vpp-native/vpp'

make[5]: *** [Makefile:6979: all-recursive] Error 1
make[5]: Leaving directory 
'/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root/build-vpp-native/vpp'

make[4]: *** [Makefile:3562: all] Error 2
make[4]: Leaving directory 
'/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root/build-vpp-native/vpp'

make[3]: *** [Makefile:697: vpp-build] Error 2
make[3]: Leaving directory 
'/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root'

make[2]: *** [Makefile:933: install-packages] Error 1
make[2]: Leaving directory 
'/home/therbert/fd.io/vpp/extras/rpm/vpp-17.10/build-root'

error: Bad exit status from /var/tmp/rpm-tmp.kz3qOs (%build)

...


--
*Thomas F Herbert*
NFV and Fast Data Planes
Office of Technology
*Red Hat*


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev





--
*Thomas F Herbert*
NFV and Fast Data Planes
Office of Technology
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Missing libvppsocketwrapper library

[Dave Wallace]

Tomas,

The LD_PRELOAD library is under review and will be committed to the vpp 
sandbox project shortly (...vppsb/vcl-ldpreload).  I will be pushing a 
patch to refactor socket_test.sh to allow setting of an environment 
variable to point to the correct location of the VCL LD_PRELOAD library 
once it has been committed.


Thanks,
-daw-

On 08/14/2017 06:48 AM, Tomáš Jančiga wrote:

Hi all,
I'd like to test the host stack implemented in VPP using the 
LD_PRELOAD trick. It's used also bytest/scripts/socket_test.sh but it 
uses wrapper library libvppsocketwrapper which is missing in VPP sources.
I'd like to ask you if you have some draft changes implementing the 
wrapper library I could test and when do you think you could merge it 
into VPP.


Thank you,
Tomas

Tomáš Jančiga
Staff Engineer
PANTHEONtechnologies s.r.o.
Mlynské Nivy 56, 821 05 Bratislava
Slovakia
Tel / +421 220 665 111
MAIL /tomas.janc...@pantheon.tech
WEB /https://pantheon.tech


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Host stack TCP

[hamid nak]

Hi all,
I don't know how to run builtin_server and builtin_client examples. Also
don't know how to set LD_PRELOAD to run every native application on top of
vpp. Please help!
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issues building latest master

[Burt Silverman]

FYI, I had updated nasm by building from source -- I should have been more
clear about that in my earlier note -- openSUSE version of nasm was too old
-- after I updated nasm by building and installing it, the errors I saw
were the ones Marco you reported. Before that I was seeing other errors.

Here is some random trivia that is not directly related: sometimes with a
problem like this, I'd explore what happens if I try to build an off the
shelf DPDK. I tried that last night on openSUSE 42.3 and I found a DPDK bug
it would appear. The 4.7... linux kernel a field trans_start was moved out
of struct net_device. Well, no, DPDK thinks it happened in 4.7 but it
really happened earlier. So the 4.4... kernel level in openSUSE won't build
because trans_start was already moved. I guess in VPP we have a DPDK config
that does not try to build that, unlike the default config.

On Mon, Aug 14, 2017 at 4:58 AM, Marco Varlese 
wrote:

> On Mon, 2017-08-14 at 09:50 +0100, Sergio Gonzalez Monroy wrote:
>
> On 14/08/2017 09:46, Marco Varlese wrote:
>
> On Mon, 2017-08-14 at 09:37 +0100, Sergio Gonzalez Monroy wrote:
>
> On 14/08/2017 09:25, Marco Varlese wrote:
>
> On Mon, 2017-08-14 at 08:17 +0100, Sergio Gonzalez Monroy wrote:
>
> Hi,
>
> So I gather that:
> 1. DPDK and the SW crypto libraries are building without errors
> 2. Only OpenSUSE displays this behavior.
>
> Only thing I can think of is that configure has different default libdir
> directory in OpenSUSE?
>
> Could you show the output of the following command:
> grep "libdir:"  build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.
> 0/config.log
>
> Regarding the option vpp_uses_dpdk_cryptodev_sw=yes, it is indeed not
> used anymore but I obviously missed some cleanup.
>
>
> Is the latest code (post 17.05) requiring a specific IA platform to
> compile (due to SSE/AVX instructions)?
> I noticed that it needs a "Sandybridge" type of architecture.
>
>
> Which nasm version are you using?
>
>
> mvarlese@linux-yk3w:~/repos/vpp> nasm -version
> NASM version 2.10.09 compiled on Aug  4 2017
>
>
> You need at least NASM 2.12.02
>
> Ok; I will try again so. Will upgrade NASM and let you know if I encounter
> any issues.
>
> Cheers,
> Marco
>
>
> Thanks,
> Sergio
>
>
>
> Thanks,
> Sergio
>
> Below the error I get on a CORE I7 :
>
> mvarlese@linux-yk3w:~/repos/vpp> make build
> make[1]: Entering directory '/home/mvarlese/repos/vpp/build-root'
>  Arch for platform 'vpp' is native 
>  Finding source for dpdk 
>  Makefile fragment found in /home/mvarlese/repos/vpp/
> build-data/packages/dpdk.mk 
>  Source found in /home/mvarlese/repos/vpp/dpdk 
>  Arch for platform 'vpp' is native 
>  Finding source for vpp 
>  Makefile fragment found in /home/mvarlese/repos/vpp/
> build-data/packages/vpp.mk 
>  Source found in /home/mvarlese/repos/vpp/src 
>  Configuring dpdk: nothing to do 
>  Building dpdk: nothing to do 
>  Installing dpdk 
> make[2]: Entering directory '/home/mvarlese/repos/vpp/dpdk'
> make install
> make[3]: Entering directory '/home/mvarlese/repos/vpp/dpdk'
> mkdir -p /home/mvarlese/repos/vpp/build-root/install-vpp_debug-
> native/dpdk/lib/
> make -C /home/mvarlese/repos/vpp/build-root/build-vpp_debug-
> native/dpdk/intel-ipsec-mb-0.45 -j NO_GCM=y
> make[4]: Entering directory '/home/mvarlese/repos/vpp/
> build-root/build-vpp_debug-native/dpdk/intel-ipsec-mb-0.45'
> Making object file obj/mb_mgr_hmac_sha_224_submit_avx512.o
> nasm -o obj/mb_mgr_hmac_sha_224_submit_avx512.o -felf64 -Xgnu -gdwarf
> -DLINUX -D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/
> avx512/mb_mgr_hmac_sha_224_submit_avx512.asm
> Making object file obj/mb_mgr_hmac_sha_256_submit_avx512.o
> nasm -o obj/mb_mgr_hmac_sha_256_submit_avx512.o -felf64 -Xgnu -gdwarf
> -DLINUX -D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/
> avx512/mb_mgr_hmac_sha_256_submit_avx512.asm
> Making object file obj/mb_mgr_hmac_sha_384_submit_avx512.o
> nasm -o obj/mb_mgr_hmac_sha_384_submit_avx512.o -felf64 -Xgnu -gdwarf
> -DLINUX -D__linux__ -Iinclude/ -I./ -Iavx/ -Iavx2/ -Iavx512/ -Isse/
> avx512/mb_mgr_hmac_sha_384_submit_avx512.asm
> mb_mgr_hmac_sha_256_submit_avx512.asm:170: 
> avx512/mb_mgr_hmac_sha_256_submit_avx512.asm:170:
> error: parser: instruction expected
> error: parser: instruction expected
> mb_mgr_hmac_sha_256_submit_avx512.asm:171: 
> avx512/mb_mgr_hmac_sha_256_submit_avx512.asm:171:
> error: symbol `vmovdqu32' redefined
> error: symbol `vmovdqu32' redefined
> mb_mgr_hmac_sha_256_submit_avx512.asm:171: 
> avx512/mb_mgr_hmac_sha_256_submit_avx512.asm:171:
> error: parser: instruction expected
> error: parser: instruction expected
> mb_mgr_hmac_sha_512_submit_avx512.asm:165: error: parser: instruction
> expected
> mb_mgr_hmac_sha_512_submit_avx512.asm:166: error: symbol `vmovdqu32'
> redefined
> mb_mgr_hmac_sha_512_submit_avx512.asm:166: error: parser: instruction
> expected
> mb_mgr_hmac_sha_512_submi

Re: [vpp-dev] Missing libvppsocketwrapper library

[Tomáš Jančiga]

OK, thank you Dave,

Tomas


Od: Dave Wallace 
Odoslané: pondelok, 14. augusta 2017 15:37:29
Komu: vpp-dev@lists.fd.io
Predmet: Re: [vpp-dev] Missing libvppsocketwrapper library

Tomas,

The LD_PRELOAD library is under review and will be committed to the vpp sandbox 
project shortly (...vppsb/vcl-ldpreload).  I will be pushing a patch to 
refactor socket_test.sh to allow setting of an environment variable to point to 
the correct location of the VCL LD_PRELOAD library once it has been committed.

Thanks,
-daw-

On 08/14/2017 06:48 AM, Tomáš Jančiga wrote:
Hi all,
I'd like to test the host stack implemented in VPP using the LD_PRELOAD trick. 
It's used also by test/scripts/socket_test.sh but it uses wrapper library 
libvppsocketwrapper which is missing in VPP sources.
I'd like to ask you if you have some draft changes implementing the wrapper 
library I could test and when do you think you could merge it into VPP.

Thank you,
Tomas


Tomáš Jančiga
Staff Engineer

PANTHEON technologies s.r.o.
Mlynské Nivy 56, 821 05 Bratislava
Slovakia
Tel / +421 220 665 111

MAIL / tomas.janc...@pantheon.tech
WEB / https://pantheon.tech





___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


Tomáš Jančiga
Staff Engineer

PANTHEON technologies s.r.o.
Mlynské Nivy 56, 821 05 Bratislava
Slovakia
Tel / +421 220 665 111

MAIL / tomas.janc...@pantheon.tech
WEB / https://pantheon.tech


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issues building latest master

[Burt Silverman]

Hi Sergio,

That seems like poor practice. I use "objdump -x
/usr/lib/" and the same under lib64 rather than lib to
see that different file formats exist in these two directories -- that
appears to be the intended openSUSE design.

Your dpdk/Makefile hard codes the use of lib. Shouldn't you be fixing the
hard coding of that, rather than matching it. I mean, if openSUSE is to be
supported officially?

Burt

On Mon, Aug 14, 2017 at 4:19 AM, Sergio Gonzalez Monroy <
sergio.gonzalez.mon...@intel.com> wrote:

> On 14/08/2017 09:11, Marco Varlese wrote:
>
>> Hi Sergio,
>>
>> I tried on a different machine and I got this:
>>
>> libdir: ${exec_prefix}/lib64
>>
>
> That confirms that ./configure is setting a different libdir in OpenSUSE
> than RHEL/Ubuntu.
>
> I'll fix that by forcing libdir to always be ${exec_prefix}/lib
>
> Thanks,
> Sergio
>
>
> Thanks,
>> Marco
>>
>>
>> Marco Varlese 08/14/17 10:04 AM >>>
>

>>
>> Sergio Gonzalez Monroy  08/14/17 9:17
> AM >>>
>
 Hi,
>>>
>>> So I gather that:
>>> 1. DPDK and the SW crypto libraries are building without errors
>>> 2. Only OpenSUSE displays this behavior.
>>>
>>> Only thing I can think of is that configure has different default libdir
>>> directory in OpenSUSE?
>>>
>>> Could you show the output of the following command:
>>> grep "libdir:"
>>> build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
>>>
>>> mvarlese@linux-yk3w:~/repos/vpp> grep "libdir:"
>> build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log
>> grep: build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log:
>> No such file or directory
>>
>> Regarding the option vpp_uses_dpdk_cryptodev_sw=yes, it is indeed not
>>> used anymore but I obviously missed some cleanup.
>>>
>>> Thanks,
>>> Sergio
>>>
>>
>> On 11/08/2017 20:25, Burt Silverman wrote:
>>
>>> After updating my nasm, I am seeing the very same problem Marco is
>>> seeing. On openSUSE 42.3. Not seen on CentOS 7. Not seen on my VyOS
>>> system.
>>>
>>> Burt
>>>
>>> On Fri, Aug 11, 2017 at 10:36 AM, Marco Varlese
>>> mailto:marco.varl...@suse.com>> wrote:
>>>
>>>  Hi,
>>>
>>>  I am having troubles building the latest code off the master branch.
>>>
>>>  The commands I always use are:
>>>  > make bootstrap
>>>  > make build
>>>
>>>  I get this error:
>>>  cp: cannot stat
>>>  '/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-
>>>  l_crypto-2.18.0/install/lib/libisal_crypto.a': No such file or
>>>  directory
>>>
>>>  I noticed that once the compilation of DPDK completes the
>>>  libraries - as
>>>  suggested by the build process itself - are placed at:
>>>  /home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-
>>> l_crypto-
>>>  2.18.0/install/lib64
>>>
>>>  So it looks like somewhere the build system is using "lib64" and
>>>  in another
>>>  place just "lib".
>>>
>>>  I wonder if something has changed and - in that case - what shall
>>>  I do?
>>>
>>>  Also, I noticed that setting the vpp_uses_dpdk_cryptodev_sw = no
>>>  in build-
>>>  date/platforms/vpp.mk  has no effect (e.g. whether
>>>  yes or no the build process
>>>  still builds the crypto stuff from DPDK). Is this a known behaviour?
>>>
>>>
>>>  Cheers,
>>>  Marco
>>>  ___
>>>  vpp-dev mailing list
>>>  vpp-dev@lists.fd.io 
>>>  https://lists.fd.io/mailman/listinfo/vpp-dev
>>>  
>>>
>>>
>>>
>>>
>>> ___
>>> vpp-dev mailing list
>>> vpp-dev@lists.fd.io
>>> https://lists.fd.io/mailman/listinfo/vpp-dev
>>>
>>
>>
>>
>> marco@linux-3s68:~/vpp> grep "libdir:"  build-root/build-vpp_debug-nat
>> ive/dpdk/isa-l_crypto-2.18.0/config.log
>>  libdir: ${exec_prefix}/lib64
>>
>>
>> marco@linux-3s68:~/vpp> grep "libdir:"  build-root/build-vpp_debug-nat
>> ive/dpdk/isa-l_crypto-2.18.0/config.log
>>  libdir: ${exec_prefix}/lib64
>>
>>
>>
>>
>>
>>
>>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Issues building latest master

[Sergio Gonzalez Monroy]

On 14/08/2017 15:43, Burt Silverman wrote:

Hi Sergio,

That seems like poor practice. I use "objdump -x 
/usr/lib/" and the same under lib64 rather than lib 
to see that different file formats exist in these two directories -- 
that appears to be the intended openSUSE design.


Your dpdk/Makefile hard codes the use of lib. Shouldn't you be fixing 
the hard coding of that, rather than matching it. I mean, if openSUSE 
is to be supported officially?




We are not installing the libraries in the system. We just install them 
under build-root directory.


Thanks,
Sergio


Burt

On Mon, Aug 14, 2017 at 4:19 AM, Sergio Gonzalez Monroy 
> wrote:


On 14/08/2017 09:11, Marco Varlese wrote:

Hi Sergio,

I tried on a different machine and I got this:

libdir: ${exec_prefix}/lib64


That confirms that ./configure is setting a different libdir in
OpenSUSE than RHEL/Ubuntu.

I'll fix that by forcing libdir to always be ${exec_prefix}/lib

Thanks,
Sergio


Thanks,
Marco


Marco Varlese 08/14/17 10:04 AM >>>



Sergio Gonzalez Monroy
mailto:sergio.gonzalez.mon...@intel.com>>
08/14/17 9:17 AM >>>

Hi,

So I gather that:
1. DPDK and the SW crypto libraries are building without
errors
2. Only OpenSUSE displays this behavior.

Only thing I can think of is that configure has different
default libdir
directory in OpenSUSE?

Could you show the output of the following command:
grep "libdir:"

build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log

mvarlese@linux-yk3w:~/repos/vpp> grep "libdir:" 
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log

grep:
build-root/build-vpp_debug-native/dpdk/isa-l_crypto-2.18.0/config.log:
No such file or directory

Regarding the option vpp_uses_dpdk_cryptodev_sw=yes, it is
indeed not
used anymore but I obviously missed some cleanup.

Thanks,
Sergio


On 11/08/2017 20:25, Burt Silverman wrote:

After updating my nasm, I am seeing the very same problem
Marco is
seeing. On openSUSE 42.3. Not seen on CentOS 7. Not seen
on my VyOS
system.

Burt

On Fri, Aug 11, 2017 at 10:36 AM, Marco Varlese
mailto:marco.varl...@suse.com>
>> wrote:

 Hi,

 I am having troubles building the latest code off the
master branch.

 The commands I always use are:
 > make bootstrap
 > make build

 I get this error:
 cp: cannot stat
   
 '/home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-

 l_crypto-2.18.0/install/lib/libisal_crypto.a': No
such file or
 directory

 I noticed that once the compilation of DPDK completes the
 libraries - as
 suggested by the build process itself - are placed at:
   
 /home/marco/vpp/build-root/build-vpp_debug-native/dpdk/isa-l_crypto-

 2.18.0/install/lib64

 So it looks like somewhere the build system is using
"lib64" and
 in another
 place just "lib".

 I wonder if something has changed and - in that case
- what shall
 I do?

 Also, I noticed that setting the
vpp_uses_dpdk_cryptodev_sw = no
 in build-
 date/platforms/vpp.mk  
has no effect (e.g. whether
 yes or no the build process
 still builds the crypto stuff from DPDK). Is this a
known behaviour?


 Cheers,
 Marco
 ___
 vpp-dev mailing list
vpp-dev@lists.fd.io 
>
https://lists.fd.io/mailman/listinfo/vpp-dev

 >




___
vpp-dev mailing list
vpp-dev@lists.fd.io 
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Host stack TCP

[Dave Wallace]

Hamid,

The VCL LD_PRELOAD library is under review and will be committed in the 
VPP Sandbox project shortly (.../vppsb/vcl-ldpreload).  It is early in 
development and is not at a stage where you can run every native socket 
application on top of vpp.  If you are interested in helping achieve 
that goal then your contributions are welcome.


Please stay tuned for an email announcing the project goals and source 
code availability.


Thanks for your interest (and patience as we get the project kicked off).
-daw-


On 8/13/17 3:58 AM, hamid nak wrote:

Hi all,
I don't know how to run builtin_server and builtin_client examples. 
Also don't know how to set LD_PRELOAD to run every native application 
on top of vpp. Please help!



___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] MPLS labels question

[Michael Borokhovich]

Hi,

I'm adding a label using the following command:

ip route add 10.100.2.0/24 table 1 via 10.100.4.12 GigabitEthernet0/6/0
out-label 222

And on the receiving side poping it with:

set interface mpls GigabitEthernet0/6/0 enable
mpls local-label 222 ip4-lookup-in-table 1

However, this didn't work until I added "*add eos*" to the last command,
i.e., the following worked:

mpls local-label add eos 222 ip4-lookup-in-table 1

Why is it necessary to specify "*add eos*" at the receiving side? Or maybe
my configuration of the sender's side is wrong?

Thanks,
Michael.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Host stack TCP

[Florin Coras]

Hi Hamid, 

To run the builtin client/server do 

test tcp [server|clients] 

To see the cli options, just execute the command appended with “?”. The options 
list not complete right now but this patch [1] fixes that. 

Hope it helps, 
Florin

[1] https://gerrit.fd.io/r/#/c/8041/ 

> On Aug 13, 2017, at 12:58 AM, hamid nak  wrote:
> 
> Hi all,
> I don't know how to run builtin_server and builtin_client examples. Also 
> don't know how to set LD_PRELOAD to run every native application on top of 
> vpp. Please help!
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MPLS labels question

[Алексей Болдырев]

А как можно навесить несколько меток на маршрут?14.08.2017, 18:58, "Michael Borokhovich" :Hi,I'm adding a label using the following command:

ip route add 10.100.2.0/24 table 1 via 10.100.4.12 GigabitEthernet0/6/0 out-label 222And on the receiving side poping it with:

set interface mpls GigabitEthernet0/6/0 enablempls local-label 222 ip4-lookup-in-table 1However, this didn't work until I added "add eos" to the last command, i.e., the following worked:

mpls local-label add eos 222 ip4-lookup-in-table 1 Why is it necessary to specify "add eos" at the receiving side? Or maybe my configuration of the sender's side is wrong?Thanks,Michael.
,___vpp-dev mailing listvpp-dev@lists.fd.iohttps://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Host stack TCP

[Dave Wallace]

[1] has been merged.

On 08/14/2017 12:03 PM, Florin Coras wrote:

Hi Hamid,

To run the builtin client/server do

test tcp [server|clients] 

To see the cli options, just execute the command appended with “?”. 
The options list not complete right now but this patch [1] fixes that.


Hope it helps,
Florin

[1] https://gerrit.fd.io/r/#/c/8041/

On Aug 13, 2017, at 12:58 AM, hamid nak > wrote:


Hi all,
I don't know how to run builtin_server and builtin_client examples. 
Also don't know how to set LD_PRELOAD to run every native application 
on top of vpp. Please help!

___
vpp-dev mailing list
vpp-dev@lists.fd.io 
https://lists.fd.io/mailman/listinfo/vpp-dev




___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MPLS labels question

[Neale Ranns (nranns)]

Hi Michael,

‘add’ is the default.
It’s necessary to specify ‘eos’ because it I the end-of-stack entry you are 
adding and the default (i.e. without ‘eos’) is to add the non-end-of-stack 
entry.

Regards,
neale

From:  on behalf of Michael Borokhovich 

Date: Monday, 14 August 2017 at 16:58
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] MPLS labels question

Hi,

I'm adding a label using the following command:

ip route add 10.100.2.0/24 table 1 via 10.100.4.12 
GigabitEthernet0/6/0 out-label 222

And on the receiving side poping it with:

set interface mpls GigabitEthernet0/6/0 enable
mpls local-label 222 ip4-lookup-in-table 1

However, this didn't work until I added "add eos" to the last command, i.e., 
the following worked:

mpls local-label add eos 222 ip4-lookup-in-table 1

Why is it necessary to specify "add eos" at the receiving side? Or maybe my 
configuration of the sender's side is wrong?

Thanks,
Michael.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MPLS labels question

[Neale Ranns (nranns)]

On master branch the CLI has changed subtlety to allow one to specify multiple 
output-labels:
  ip route add 10.100.2.0/24 table 1 via 10.100.4.12 
GigabitEthernet0/6/0 out-labels 222 333

note the change from ‘out-label’ to ‘out-labels’. In older versions passing 
multiple out-labels is only possible via the API.

/neale


From:  on behalf of Алексей Болдырев 

Date: Monday, 14 August 2017 at 17:08
To: Michael Borokhovich , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] MPLS labels question

А как можно навесить несколько меток на маршрут?


14.08.2017, 18:58, "Michael Borokhovich" :
Hi,

I'm adding a label using the following command:

ip route add 10.100.2.0/24 table 1 via 10.100.4.12 
GigabitEthernet0/6/0 out-label 222

And on the receiving side poping it with:

set interface mpls GigabitEthernet0/6/0 enable
mpls local-label 222 ip4-lookup-in-table 1

However, this didn't work until I added "add eos" to the last command, i.e., 
the following worked:

mpls local-label add eos 222 ip4-lookup-in-table 1

Why is it necessary to specify "add eos" at the receiving side? Or maybe my 
configuration of the sender's side is wrong?

Thanks,
Michael.
,

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MPLS labels question

[Neale Ranns (nranns)]

There is no limit to the number of labels that can be specified.

/neale

From:  on behalf of "Neale Ranns (nranns)" 

Date: Monday, 14 August 2017 at 18:03
To: Алексей Болдырев , Michael Borokhovich 
, "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] MPLS labels question


On master branch the CLI has changed subtlety to allow one to specify multiple 
output-labels:
  ip route add 10.100.2.0/24 table 1 via 10.100.4.12 
GigabitEthernet0/6/0 out-labels 222 333

note the change from ‘out-label’ to ‘out-labels’. In older versions passing 
multiple out-labels is only possible via the API.

/neale


From:  on behalf of Алексей Болдырев 

Date: Monday, 14 August 2017 at 17:08
To: Michael Borokhovich , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] MPLS labels question

А как можно навесить несколько меток на маршрут?


14.08.2017, 18:58, "Michael Borokhovich" :
Hi,

I'm adding a label using the following command:

ip route add 10.100.2.0/24 table 1 via 10.100.4.12 
GigabitEthernet0/6/0 out-label 222

And on the receiving side poping it with:

set interface mpls GigabitEthernet0/6/0 enable
mpls local-label 222 ip4-lookup-in-table 1

However, this didn't work until I added "add eos" to the last command, i.e., 
the following worked:

mpls local-label add eos 222 ip4-lookup-in-table 1

Why is it necessary to specify "add eos" at the receiving side? Or maybe my 
configuration of the sender's side is wrong?

Thanks,
Michael.
,

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MPLS labels question

[Michael Borokhovich]

I see.. so there is a need to add the "add eos" to the "mpls local-label"
command if I want to send the packet to the IP lookup after popping a
single (the only) label.

Thanks, Neale!

On Mon, Aug 14, 2017 at 1:01 PM, Neale Ranns (nranns) 
wrote:

>
>
> Hi Michael,
>
>
>
> ‘add’ is the default.
>
> It’s necessary to specify ‘eos’ because it I the end-of-stack entry you
> are adding and the default (i.e. without ‘eos’) is to add the
> non-end-of-stack entry.
>
>
>
> Regards,
>
> neale
>
>
>
> *From: * on behalf of Michael Borokhovich <
> michael...@gmail.com>
> *Date: *Monday, 14 August 2017 at 16:58
> *To: *"vpp-dev@lists.fd.io" 
> *Subject: *[vpp-dev] MPLS labels question
>
>
>
> Hi,
>
>
>
> I'm adding a label using the following command:
>
>
>
> ip route add 10.100.2.0/24 table 1 via 10.100.4.12 GigabitEthernet0/6/0
> out-label 222
>
>
>
> And on the receiving side poping it with:
>
>
>
> set interface mpls GigabitEthernet0/6/0 enable
>
> mpls local-label 222 ip4-lookup-in-table 1
>
>
>
> However, this didn't work until I added "*add **eos*" to the last
> command, i.e., the following worked:
>
>
>
> mpls local-label add eos 222 ip4-lookup-in-table 1
>
>
>
> Why is it necessary to specify "*add **eos*" at the receiving side? Or
> maybe my configuration of the sender's side is wrong?
>
>
>
> Thanks,
>
> Michael.
>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MPLS labels question

[Neale Ranns (nranns)]

No, not quite. There’s a need to add ‘eos’ if you want the label entry to match 
against that label AND against the set EOS bit. An MPLS lookup is really a 21 
bit match; 20 bits of label value and 1 bit EOS.
It only makes sense to send EOS traffic to IP lookup. Sending non-EOS traffic 
to a IP lookup would not result in something good.

If label 222 has been dedicated to 10.100.2.0/24 (i.e. when we the receiver 
gets traffic with label 222, it must be for 10.100.2.0/24) then the command you 
are looking for is;
   mpls local-label 222 10.100.2.0/24
this does what the API refers to as a ‘bind’. It says, whatever IP does for 
10.100.2.0/24, MPLS should do for label 222. It will add the eos and non-eos 
entries appropriately.

/neale


From: Michael Borokhovich 
Date: Monday, 14 August 2017 at 18:20
To: "Neale Ranns (nranns)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] MPLS labels question

I see.. so there is a need to add the "add eos" to the "mpls local-label" 
command if I want to send the packet to the IP lookup after popping a single 
(the only) label.

Thanks, Neale!

On Mon, Aug 14, 2017 at 1:01 PM, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:

Hi Michael,

‘add’ is the default.
It’s necessary to specify ‘eos’ because it I the end-of-stack entry you are 
adding and the default (i.e. without ‘eos’) is to add the non-end-of-stack 
entry.

Regards,
neale

From: mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of Michael Borokhovich 
mailto:michael...@gmail.com>>
Date: Monday, 14 August 2017 at 16:58
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] MPLS labels question

Hi,

I'm adding a label using the following command:

ip route add 10.100.2.0/24 table 1 via 10.100.4.12 
GigabitEthernet0/6/0 out-label 222

And on the receiving side poping it with:

set interface mpls GigabitEthernet0/6/0 enable
mpls local-label 222 ip4-lookup-in-table 1

However, this didn't work until I added "add eos" to the last command, i.e., 
the following worked:

mpls local-label add eos 222 ip4-lookup-in-table 1

Why is it necessary to specify "add eos" at the receiving side? Or maybe my 
configuration of the sender's side is wrong?

Thanks,
Michael.

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [csit-dev] about UT test framework for VPP

[Billy McFall]

I am trying to run "make test" on a CentOS bare metal server. I'm getting
"Exception: Illegal syntax for IP address". What do I need to
setup/configure on my server before running "make test"?

Thanks,
Billy McFall


$ make test V=2
make -C /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root PLATFORM=vpp
TAG=vpp vpp-install
make[1]: Entering directory
`/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root'
 Arch for platform 'vpp' is native 
 Finding source for dpdk 
 Makefile fragment found in
/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-data/packages/dpdk.mk 
 Source found in /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/dpdk 
 Arch for platform 'vpp' is native 
 Finding source for vpp 
 Makefile fragment found in
/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-data/packages/vpp.mk 
 Source found in /home/bmcfall/dev/2017_08_14_VPP_Master/vpp/src 
 Configuring dpdk: nothing to do 
 Building dpdk: nothing to do 
 Installing dpdk: nothing to do 
 Configuring vpp: nothing to do 
 Building vpp: nothing to do 
 Installing vpp: nothing to do 
make[1]: Leaving directory
`/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root'
make -C test TEST_DIR=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test
VPP_TEST_BUILD_DIR=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/build-vpp-native
VPP_TES
T_BIN=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/vpp/bin/vpp
VPP_TEST_PLUGIN_PATH=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/i
nstall-vpp-native/vpp/lib/vpp_plugins:/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/vpp/lib64/vpp_plugins
VPP_TEST_INSTALL_PATH=/home/bmcfall
/dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/
LD_LIBRARY_PATH=/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/vpp/lib/:/home/bm
cfall/dev/2017_08_14_VPP_Master/vpp/build-root/install-vpp-native/vpp/lib64/
EXTENDED_TESTS= PYTHON= test
make[1]: Entering directory
`/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test'
Traceback (most recent call last):
  File "sanity_run_vpp.py", line 7, in 
from framework import VppTestCase, KeepAliveReporter
  File "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test/framework.py",
line 20, in 
from vpp_pg_interface import VppPGInterface
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test/vpp_pg_interface.py",
line 8, in 
from vpp_interface import VppInterface
  File "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test/vpp_interface.py",
line 4, in 
from util import Host, mk_ll_addr
  File "/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test/util.py", line 7,
in 
from scapy.layers.inet6 import in6_mactoifaceid
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/layers/inet6.py",
line 56, in 
import scapy.route6
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
line 273, in 
conf.route6 = Route6()
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
line 31, in __init__
self.resync()
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/route6.py",
line 44, in resync
self.routes = read_routes6()
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/arch/linux.py",
line 283, in read_routes6
cset = scapy.utils6.construct_source_candidate_set(d, dp, devaddrs,
LOOPBACK_NAME)
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/utils6.py",
line 50, in construct_source_candidate_set
if in6_isgladdr(addr) or in6_isuladdr(addr):
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/utils6.py",
line 708, in in6_isgladdr
return in6_isincluded(str, '2000::', 3)
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/utils6.py",
line 651, in in6_isincluded
temp = inet_pton(socket.AF_INET6, addr)
  File
"/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/build-root/python/virtualenv/lib/python2.7/site-packages/scapy/pton_ntop.py",
line 40, in inet_pton
raise Exception("Illegal syntax for IP address")
Exception: Illegal syntax for IP address
***
* Sanity check failed, cannot run vpp
***
make[1]: *** [sanity] Error 1
make[1]: Leaving directory
`/home/bmcfall/dev/2017_08_14_VPP_Master/vpp/test'
make: *** [test] Error 2


On Thu, Jul 6, 2017 at 6:26 AM, Maciek Konstantynowicz (mkonstan) <
mkons...@cisco.com> wrote:

> +vpp-dev.
>
> yes, vpp 

Re: [vpp-dev] MPLS labels question

[Michael Borokhovich]

Thanks a lot for the explanation, Neale!

I actually need that all incoming traffic with label 222 will go to a
specific VRF (table 1). So, as I understand, this can be achieved by:

mpls local-label add eos 222 ip4-lookup-in-table 1

And in this case, it seems that I always have to use "add eos".

On Mon, Aug 14, 2017 at 1:59 PM, Neale Ranns (nranns) 
wrote:

>
>
> No, not quite. There’s a need to add ‘eos’ if you want the label entry to
> match against that label AND against the set EOS bit. An MPLS lookup is
> really a 21 bit match; 20 bits of label value and 1 bit EOS.
>
> It only makes sense to send EOS traffic to IP lookup. Sending non-EOS
> traffic to a IP lookup would not result in something good.
>
>
>
> If label 222 has been dedicated to 10.100.2.0/24 (i.e. when we the
> receiver gets traffic with label 222, it must be for 10.100.2.0/24) then
> the command you are looking for is;
>
>mpls local-label 222 10.100.2.0/24
>
> this does what the API refers to as a ‘bind’. It says, whatever IP does
> for 10.100.2.0/24, MPLS should do for label 222. It will add the eos and
> non-eos entries appropriately.
>
>
>
> /neale
>
>
>
>
>
> *From: *Michael Borokhovich 
> *Date: *Monday, 14 August 2017 at 18:20
> *To: *"Neale Ranns (nranns)" 
> *Cc: *"vpp-dev@lists.fd.io" 
> *Subject: *Re: [vpp-dev] MPLS labels question
>
>
>
> I see.. so there is a need to add the "add eos" to the "mpls local-label"
> command if I want to send the packet to the IP lookup after popping a
> single (the only) label.
>
>
>
> Thanks, Neale!
>
>
>
> On Mon, Aug 14, 2017 at 1:01 PM, Neale Ranns (nranns) 
> wrote:
>
>
>
> Hi Michael,
>
>
>
> ‘add’ is the default.
>
> It’s necessary to specify ‘eos’ because it I the end-of-stack entry you
> are adding and the default (i.e. without ‘eos’) is to add the
> non-end-of-stack entry.
>
>
>
> Regards,
>
> neale
>
>
>
> *From: * on behalf of Michael Borokhovich <
> michael...@gmail.com>
> *Date: *Monday, 14 August 2017 at 16:58
> *To: *"vpp-dev@lists.fd.io" 
> *Subject: *[vpp-dev] MPLS labels question
>
>
>
> Hi,
>
>
>
> I'm adding a label using the following command:
>
>
>
> ip route add 10.100.2.0/24 table 1 via 10.100.4.12 GigabitEthernet0/6/0
> out-label 222
>
>
>
> And on the receiving side poping it with:
>
>
>
> set interface mpls GigabitEthernet0/6/0 enable
>
> mpls local-label 222 ip4-lookup-in-table 1
>
>
>
> However, this didn't work until I added "*add eos*" to the last command,
> i.e., the following worked:
>
>
>
> mpls local-label add eos 222 ip4-lookup-in-table 1
>
>
>
> Why is it necessary to specify "*add eos*" at the receiving side? Or
> maybe my configuration of the sender's side is wrong?
>
>
>
> Thanks,
>
> Michael.
>
>
>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Do we have any plan to support DNAT

[Ole Troan]

Hongjun,

> Do we have any plan to support DNAT feature?

Source NAT and Destination NAT are concepts of the Linux iptables 
implementation.

The VPP NAT feature called SNAT. For _Simple_ NAT, was perhaps not the best 
naming choice. ;-)
We did discuss renaming it to just NAT at some point.

And yes, we do translate destination addresses too.

Best regards,
Ole


signature.asc
Description: Message signed with OpenPGP
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] VPP Packet Generator and pg0 IP address

[Michael Borokhovich]

Hi,

Is it true that in VPP 1707 we have to give IP to the pg0 interface?

In the previous VPP version (1609), the packet generator worked without IP
address on pg0, but in 1707 it gives "ip4 adjacency drop" and no packets
come out. Configuring pg0 with some fake IP worked.

Thanks,
Michael.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] VPP Performance drop from 17.04 to 17.07

[Billy McFall]

In the last VPP call, I reported some internal Red Hat performance testing
was showing a significant drop in performance between releases 17.04 to
17.07. This with l2-bridge testing - PVP - 0.002% Drop Rate:
   VPP-17.04: 256 Flow 7.8 MP/s 10k Flow 7.3 MP/s 1m Flow 5.2 MP/s
   VPP-17.07: 256 Flow 7.7 MP/s 10k Flow 2.7 MP/s 1m Flow 1.8 MP/s

The performance team re-ran some of the tests for me with some additional
data collected. Looks like the size of the L2 FIB table was reduced in
17.07. Below are the number of entries in the MAC Table after the tests are
run:
   17.04:
 show l2fib
 408 l2fib entries
   17.07:
 show l2fib
 1067053 l2fib entries with 1048576 learned (or non-static) entries

This caused more packets to be flooded (see out of 'show node counters'
below). I looked but couldn't find anything. Is the size of the L2 FIB
Table table configurable?

Thanks,
Billy McFall


17.04:

show node counters
   CountNode  Reason
:
 313035313l2-inputL2 input packets
555726l2-floodL2 flood packets
:
 310115490l2-inputL2 input packets
824859l2-floodL2 flood packets
:
 313508376l2-inputL2 input packets
   1041961l2-floodL2 flood packets
:
 313691024l2-inputL2 input packets
698968l2-floodL2 flood packets

17.07:

show node counters
   CountNode  Reason
:
  97810569l2-inputL2 input packets
  72557612l2-floodL2 flood packets
:
  97830674l2-inputL2 input packets
  72478802l2-floodL2 flood packets
:
  97714888l2-inputL2 input packets
  71655987l2-floodL2 flood packets
:
  97710374l2-inputL2 input packets
  70058006l2-floodL2 flood packets


-- 
*Billy McFall*
SDN Group
Office of Technology
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MPLS labels question

[Алексей Болдырев]

Скажите пожалуйста, умеет ли vpp отображать процесс в трассировке о надивании и снятии MPLS-меток?Как например тут:traceroute to kernel.org (198.145.29.83), 30 hops max, 60 byte packets 1  10.247.1.1 (10.247.1.1)  0.095 ms  0.127 ms  0.122 ms 2  100.64.0.1 (100.64.0.1)  0.765 ms  0.753 ms  0.893 ms 3  192.168.192.193 (192.168.192.193)  5.333 ms  5.334 ms  5.329 ms 4  192.168.192.1 (192.168.192.1)  4.476 ms * * 5  kiev-r0.w-ix.net (193.106.112.4)  31.109 ms  28.508 ms  28.508 ms 6  * * * 7  10ge1-8.core1.vie1.he.net (184.105.222.25)  61.858 ms  61.844 ms  59.284 ms 8  100ge13-1.core1.par2.he.net (184.105.65.5)  70.435 ms  70.443 ms  70.592 ms 9  100ge14-1.core1.nyc4.he.net (184.105.81.77)  150.720 ms  150.975 ms  151.391 ms10  100ge14-1.core1.tor1.he.net (184.105.80.10)   154.989 ms  155.078 ms  146.024 ms11  100ge6-1.core1.ywg1.he.net (184.105.64.102)   176.754 ms  162.817 ms  168.390 ms12  100ge10-1.core1.yyc1.he.net (184.105.222.98)   180.728 ms  183.503 ms  192.020 ms13  100ge10-2.core1.yvr1.he.net (184.105.64.113)   240.695 ms  239.889 ms  236.867 ms14  100ge10-2.core1.sea1.he.net (184.105.64.109)  193.678 ms  196.335 ms  196.401 ms15  100ge14-1.core1.pdx1.he.net (184.105.64.138)  193.324 ms  195.997 ms  196.036 ms16  infinity-internet-inc.gigabitethernet2-11.core1.pdx1.he.net (64.71.165.18)  195.808 ms  196.093 ms  195.852 ms17  xe-6-0-0.r-1.linuxfoundation.org (198.145.0.9)  197.070 ms  197.043 ms  197.272 ms18  fw-1.linuxfoundation.org (198.145.0.11)  196.924 ms  197.011 ms  196.879 ms19  kernel.org (198.145.29.83)  199.697 ms  197.026 ms  199.542 ms 14.08.2017, 22:37, "Michael Borokhovich" :Thanks a lot for the explanation, Neale!I actually need that all incoming traffic with label 222 will go to a specific VRF (table 1). So, as I understand, this can be achieved by:mpls local-label add eos 222 ip4-lookup-in-table 1And in this case, it seems that I always have to use "add eos".On Mon, Aug 14, 2017 at 1:59 PM, Neale Ranns (nranns)  wrote:









 
No, not quite. There’s a need to add ‘eos’ if you want the label entry to match against that label AND against the set EOS bit. An MPLS lookup is really a 21
 bit match; 20 bits of label value and 1 bit EOS.
It only makes sense to send EOS traffic to IP lookup. Sending non-EOS traffic to a IP lookup would not result in something good.
 
If label 222 has been dedicated to 10.100.2.0/24 (i.e. when we the receiver gets traffic with label 222, it must be for 10.100.2.0/24) then the command you are
 looking for is;
   mpls local-label 222 10.100.2.0/24
this does what the API refers to as a ‘bind’. It says, whatever IP does for 10.100.2.0/24, MPLS should do for label 222. It will add the eos and non-eos entries
 appropriately.
 
/neale
 
 


From: 
Michael Borokhovich 
Date: Monday, 14 August 2017 at 18:20
To: "Neale Ranns (nranns)" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] MPLS labels question


 


I see.. so there is a need to add the "add eos" to the "mpls local-label" command if I want to send the packet to the IP lookup after popping a single (the only) label.


 


Thanks, Neale!


 

On Mon, Aug 14, 2017 at 1:01 PM, Neale Ranns (nranns)  wrote:



 
Hi Michael,
 
‘add’ is the default.
It’s necessary to specify ‘eos’ because it I the end-of-stack entry you are adding and the default (i.e. without ‘eos’) is to
 add the non-end-of-stack entry.
 
Regards,
neale
 


From:
 on behalf of Michael Borokhovich 
Date: Monday, 14 August 2017 at 16:58
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] MPLS labels question




 


Hi,


 


I'm adding a label using the following command:


 


ip route add
10.100.2.0/24 table 1 via 10.100.4.12 GigabitEthernet0/6/0 out-label 222


 


And on the receiving side poping it with:


 



set interface mpls GigabitEthernet0/6/0 enable


mpls local-label 222 ip4-lookup-in-table 1



 


However, this didn't work until I added "add eos" to the last command, i.e., the following worked:


 


mpls local-label add eos 222 ip4-lookup-in-table 1


 


Why is it necessary to specify "add eos" at the receiving side? Or maybe my configuration of the sender's
 side is wrong?


 


Thanks,


Michael.









 







,___vpp-dev mailing listvpp-dev@lists.fd.iohttps://lists.fd.io/mailman/listinfo/vpp-dev___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Do we have any plan to support DNAT

[Ni, Hongjun]

Hi Ole,

Thank you for detailed explanation.  Will give it a try.

-Hongjun

-Original Message-
From: Ole Troan [mailto:otr...@employees.org] 
Sent: Tuesday, August 15, 2017 4:24 AM
To: Ni, Hongjun 
Cc: vpp-dev 
Subject: Re: [vpp-dev] Do we have any plan to support DNAT

Hongjun,

> Do we have any plan to support DNAT feature?

Source NAT and Destination NAT are concepts of the Linux iptables 
implementation.

The VPP NAT feature called SNAT. For _Simple_ NAT, was perhaps not the best 
naming choice. ;-) We did discuss renaming it to just NAT at some point.

And yes, we do translate destination addresses too.

Best regards,
Ole
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev