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

[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

[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

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) 
> 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 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)]

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)]

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] 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

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

А как можно навесить несколько меток на маршрут?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

[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

[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] 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
>
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

>> 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 

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
>>> > 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] 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

[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] 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] 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] 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



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

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./ 

[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

[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

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

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
> 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]

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 
> > 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]

>>> 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 
> > 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] 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 
> 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