Re: [vpp-dev] VPP with DPDK eventdev

[Brian Brooks]

Can eventdev inspire VPP to process packets from the same flow across multiple 
CPUs?

Brian


-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion
Sent: Monday, April 23, 2018 11:29 AM
To: Andrew Pinski 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP with DPDK eventdev


I’m not aware of such activities, but before you start working on the actual 
implementation i would suggest community discussion on architecture, use cases 
and required changes in the code. Biweekly community call is likely good forum 
for that.

—
Damjan

> On 22 Apr 2018, at 07:17, Andrew Pinski  wrote:
>
> Hi all,
>  We were wondering if anyone is currently working on getting VPP to
> work with the DPDK eventdev?  We don't want to duplication.
>
> Thanks,
> Andrew
>
>
>



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9085): https://lists.fd.io/g/vpp-dev/message/9085
View All Messages In Topic (3): https://lists.fd.io/g/vpp-dev/topic/18050545
Mute This Topic: https://lists.fd.io/mt/18050545/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] opensuse is dead, long live opensuse

[Ed Kern]

With 18.04 now released ive merge in a change for opensuse building.

if the job name is opensuse this refers to the opensuse release leap 42.3.  We 
are no longer building
master on this image but will continue to build 18.01 and 18.04.


If the job name is osleap15  this refers to the opensuse leap 15 image which is 
newer.  (Correct 15 > 42.3)
osleap15 has replaced opensuse jobs on master for verify and merge.

Ed

P.S. Opensuse leap15 currently doesn’t officially release until late may so 
this MAY cause delays in fixing
build issues.  The package cloud push also has issues that should be fixed 
before too long
-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9084): https://lists.fd.io/g/vpp-dev/message/9084
View All Messages In Topic (1): https://lists.fd.io/g/vpp-dev/topic/18101047
Mute This Topic: https://lists.fd.io/mt/18101047/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] vlib_main() taking maximum cycle in v1804 release

[Saxena, Nitin]

Hi,

While running L3 Fwd test case with VPP v1804 release (released yesterday), 
perf tool shows vlib_main() taking maximum cycles.
This has been observed on Aarch64 (Both on Marvell’s Macchiatobin and Cavium’s 
ThunderX products) and Broadwell machine as well.

Perf top from Broadwell machine
=
 29.72%  libvlib.so.0.0.0[.] vlib_main
  17.33%  dpdk_plugin.so  [.] i40e_xmit_pkts
   7.35%  dpdk_plugin.so  [.] i40e_recv_scattered_pkts_vec
   7.21%  libvlibmemory.so.0.0.0  [.] memclnt_queue_callback
   6.02%  libvnet.so.0.0.0[.] ip4_rewrite_avx2
   5.96%  libvnet.so.0.0.0[.] ip4_lookup_avx2
   5.69%  libvnet.so.0.0.0[.] ip4_input_no_checksum_avx2
   5.49%  dpdk_plugin.so  [.] dpdk_input_avx2
   3.40%  dpdk_plugin.so  [.] dpdk_interface_tx_avx2
   1.63%  libvnet.so.0.0.0[.] vnet_interface_output_node_avx2

Is this the expected behaviour? I haven’t observed vlib_main() taking max perf 
cycles in VPP v1801.

Thanks,
Nitin

Re: [vpp-dev] segfault due to movaps unaligned access

[Dave Barach]

Yes, it’s arguably a compiler bug.

But, it makes no sense to vec_validate_aligned(…), pool_get_aligned(…) etc. 
objects whose size is not a multiple of the alignment request. Only the first 
element will be aligned to the specified boundary.

__attribute__((aligned(xxx))) is not the same thing as ensuring that objects 
are sized correctly.

D.

From: vpp-dev@lists.fd.io  On Behalf Of Radu Nicolau
Sent: Thursday, April 26, 2018 4:54 AM
To: Florin Coras 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Florin,

Thanks! The patch fixes the issue.
Any idea why is it happening?

Regards,
Radu

From: vpp-dev@lists.fd.io 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Tuesday, April 24, 2018 11:25 PM
To: Nicolau, Radu >
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Radu,

Making the crypto_worker_main_t a full cache line in size (see patch [1]) seems 
to solve the issue. Could you confirm?

Florin

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

On Apr 24, 2018, at 9:23 AM, Radu Nicolau 
> wrote:

Hello all,

We’re seeing a weird issue, that is a segfault that looks to be caused by a 
movaps instruction that is trying to access an address that is not 16 byte 
aligned.
The call originates from a vec_validate_init_empty_aligned that has the 
argument aligned to 16 bytes.
I have seen something like this in the past, we couldn’t find a root cause and 
considered it a GCC bug (version 5 then), but now it pops up again on version 
7, so probably it isn’t.
Any idea? A snapshot of the gdb screen below.

gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
https://postimg.cc/image/9jy4p38at/

thanks and I will appreciate any help,
Radu

Re: [vpp-dev] SPAN questions

[John Lo (loj)]

Hi Matt,

SPAN without L2 is putting the packet mirror on an interface (only main 
interface) input and/or output irrespectively of it in L2 or L3 mode.

SPAN with L2 means to perform packet mirror on L2 input and/or output on an 
interface or sub-interface which is in a bridge domain or cross connect.  One 
thing to note with L2 SPAN is that the output/destination interface used for 
mirrored packet must also be in L2 mode. Using L2 interface for output allows 
user to configure VLAN rewrite operation on that interface on mirrored packets.

If SPAN is configure on an interface with both L2 and without L2, you will get 
packet mirrored twice if the interface is set to L2 bridging or xconnect. 
Packet is replicated once on input at the interface and replicated again on 
L2-input to a BD/xconnect.  If interface is in L3 mode, L2 SPAN will not have 
any effect.

Regards,
John

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Matthew Smith
Sent: Thursday, April 26, 2018 11:05 AM
To: vpp-dev 
Subject: [vpp-dev] SPAN questions


Is the L2 flag when adding a SPAN mirror intended to indicate that the source 
port is a member of a bridge domain?

I noticed that SPAN can be configured on a port with the L2 flag set and also 
with it unset. So configurations for L2 and ! L2 can both exist at the same 
time. E.g.:

vpp# set interface span TenGigabitEthernet2/0/1 destination 
TenGigabitEthernet2/0/0 both vpp# set interface span TenGigabitEthernet2/0/1 l2 
destination TenGigabitEthernet2/0/0 both vpp# show interface span
Source   Destination   Device   L2
TenGigabitEthernet2/ TenGigabitEthernet2/ (  both) (  both)

Are there cases where this would be necessary? Or do the graph nodes for only 
one of {L2, device} get used for a source interface at any given time?

Thanks,
-Matt





-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9081): https://lists.fd.io/g/vpp-dev/message/9081
View All Messages In Topic (2): https://lists.fd.io/g/vpp-dev/topic/18098046
Mute This Topic: https://lists.fd.io/mt/18098046/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VPP 18.04 has been released! Artifacts are available on nexus.fd.io

[Dave Barach]

Congrats to the team! Special thanks to Chris... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Chris Luke
Sent: Wednesday, April 25, 2018 6:53 PM
To: vpp-dev ; csit-...@lists.fd.io
Subject: [vpp-dev] VPP 18.04 has been released! Artifacts are available on 
nexus.fd.io

All,

I am happy to announce that VPP 18.04 has been released! The release notes can 
be found at https://docs.fd.io/vpp/18.04/release_notes_1804.html.

The various release artifacts have made their way to the right places on 
nexus.fd.io.

Packaging for Centos 7 (Intel), openSUSE Leap 42.3 (Intel), Ubuntu Xenial 
(Intel) and Ubuntu Xenial (ARM) are available. Details on how to install them 
are available at 
https://wiki.fd.io/view/VPP/Installing_VPP_binaries_from_packages.

Packages for the Intel platforms have been tested; I will follow up with ARM 
package testing once I get my arm64 box setup!

Our thanks to all of the VPP and FD.io community who have contributed to the 
18.04 VPP release.

Cheers,
Chris.

Re: [vpp-dev] segfault due to movaps unaligned access

[Florin Coras]

Yup, it surely seems so. 

Florin

> On Apr 26, 2018, at 8:40 AM, Nicolau, Radu  wrote:
> 
> Hi,
>
> If elements of the vector are 54 bytes and first is aligned, accessing the 
> second one should not generate instructions that assume it is aligned as 
> well. So based on that and your description, this is a gcc bug, right? The 
> issue does not occur on gcc 6.3, 6.4 but occurs on 7.2.0 and 7.3.1 (and I’ve 
> seen it a while ago on 5.x).
>   <>
> Regards,
> Radu
>  <>From: vpp-dev@lists.fd.io  
> [mailto:vpp-dev@lists.fd.io ] On Behalf Of Florin 
> Coras
> Sent: Thursday, April 26, 2018 4:13 PM
> To: Nicolau, Radu >
> Cc: vpp-dev@lists.fd.io 
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
>
> Hi Radu, 
>
> The problem was that the vector was expected to have cacheline size aligned 
> data, but the elements in the vector were not a multiple of a cache line 
> (size was 54). As a result, the first element was aligned and the rest were 
> not. The vector infra just allocates an aligned chunk of memory, it does not 
> guarantee anything with respect to individual element placement.
>
> Hope it helps!
>
> Cheers,
> Florin
> 
> 
> On Apr 26, 2018, at 1:53 AM, Nicolau, Radu  > wrote:
>
> Hi Florin,
>
> Thanks! The patch fixes the issue.
> Any idea why is it happening?
>
> Regards,
> Radu
>
> From: vpp-dev@lists.fd.io  
> [mailto:vpp-dev@lists.fd.io ] On Behalf Of Florin 
> Coras
> Sent: Tuesday, April 24, 2018 11:25 PM
> To: Nicolau, Radu >
> Cc: vpp-dev@lists.fd.io 
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
>
> Hi Radu, 
>
> Making the crypto_worker_main_t a full cache line in size (see patch [1]) 
> seems to solve the issue. Could you confirm?
>
> Florin
>
> [1] https://gerrit.fd.io/r/#/c/12086/ 
> 
> 
> 
> On Apr 24, 2018, at 9:23 AM, Radu Nicolau  > wrote:
>
> Hello all,
>
> We’re seeing a weird issue, that is a segfault that looks to be caused by a 
> movaps instruction that is trying to access an address that is not 16 byte 
> aligned.
> The call originates from a vec_validate_init_empty_aligned that has the 
> argument aligned to 16 bytes.
> I have seen something like this in the past, we couldn’t find a root cause 
> and considered it a GCC bug (version 5 then), but now it pops up again on 
> version 7, so probably it isn’t.
> Any idea? A snapshot of the gdb screen below.
>
> gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
> https://postimg.cc/image/9jy4p38at/ 
>
> thanks and I will appreciate any help,
> Radu
>
>
> 

Re: [vpp-dev] segfault due to movaps unaligned access

[Radu Nicolau]

Hi,

If elements of the vector are 54 bytes and first is aligned, accessing the 
second one should not generate instructions that assume it is aligned as well. 
So based on that and your description, this is a gcc bug, right? The issue does 
not occur on gcc 6.3, 6.4 but occurs on 7.2.0 and 7.3.1 (and I’ve seen it a 
while ago on 5.x).

Regards,
Radu
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Thursday, April 26, 2018 4:13 PM
To: Nicolau, Radu 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Radu,

The problem was that the vector was expected to have cacheline size aligned 
data, but the elements in the vector were not a multiple of a cache line (size 
was 54). As a result, the first element was aligned and the rest were not. The 
vector infra just allocates an aligned chunk of memory, it does not guarantee 
anything with respect to individual element placement.

Hope it helps!

Cheers,
Florin


On Apr 26, 2018, at 1:53 AM, Nicolau, Radu 
> wrote:

Hi Florin,

Thanks! The patch fixes the issue.
Any idea why is it happening?

Regards,
Radu

From: vpp-dev@lists.fd.io 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Tuesday, April 24, 2018 11:25 PM
To: Nicolau, Radu >
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Radu,

Making the crypto_worker_main_t a full cache line in size (see patch [1]) seems 
to solve the issue. Could you confirm?

Florin

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



On Apr 24, 2018, at 9:23 AM, Radu Nicolau 
> wrote:

Hello all,

We’re seeing a weird issue, that is a segfault that looks to be caused by a 
movaps instruction that is trying to access an address that is not 16 byte 
aligned.
The call originates from a vec_validate_init_empty_aligned that has the 
argument aligned to 16 bytes.
I have seen something like this in the past, we couldn’t find a root cause and 
considered it a GCC bug (version 5 then), but now it pops up again on version 
7, so probably it isn’t.
Any idea? A snapshot of the gdb screen below.

gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
https://postimg.cc/image/9jy4p38at/

thanks and I will appreciate any help,
Radu

Re: [vpp-dev] segfault due to movaps unaligned access

[Florin Coras]

Hi Radu, 

The problem was that the vector was expected to have cacheline size aligned 
data, but the elements in the vector were not a multiple of a cache line (size 
was 54). As a result, the first element was aligned and the rest were not. The 
vector infra just allocates an aligned chunk of memory, it does not guarantee 
anything with respect to individual element placement.

Hope it helps!

Cheers,
Florin

> On Apr 26, 2018, at 1:53 AM, Nicolau, Radu  wrote:
> 
> Hi Florin,
>
> Thanks! The patch fixes the issue.
> Any idea why is it happening?
>
> Regards,
> Radu
>   <>
>  <>From: vpp-dev@lists.fd.io  
> [mailto:vpp-dev@lists.fd.io ] On Behalf Of Florin 
> Coras
> Sent: Tuesday, April 24, 2018 11:25 PM
> To: Nicolau, Radu >
> Cc: vpp-dev@lists.fd.io 
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
>
> Hi Radu, 
>
> Making the crypto_worker_main_t a full cache line in size (see patch [1]) 
> seems to solve the issue. Could you confirm?
>
> Florin
>
> [1] https://gerrit.fd.io/r/#/c/12086/ 
> 
> 
> On Apr 24, 2018, at 9:23 AM, Radu Nicolau  > wrote:
>
> Hello all,
>
> We’re seeing a weird issue, that is a segfault that looks to be caused by a 
> movaps instruction that is trying to access an address that is not 16 byte 
> aligned.
> The call originates from a vec_validate_init_empty_aligned that has the 
> argument aligned to 16 bytes.
> I have seen something like this in the past, we couldn’t find a root cause 
> and considered it a GCC bug (version 5 then), but now it pops up again on 
> version 7, so probably it isn’t.
> Any idea? A snapshot of the gdb screen below.
>
> gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
> https://postimg.cc/image/9jy4p38at/ 
>
> thanks and I will appreciate any help,
> Radu
>
> 

[vpp-dev] SPAN questions

[Matthew Smith]

Is the L2 flag when adding a SPAN mirror intended to indicate that the source 
port is a member of a bridge domain?

I noticed that SPAN can be configured on a port with the L2 flag set and also 
with it unset. So configurations for L2 and ! L2 can both exist at the same 
time. E.g.:

vpp# set interface span TenGigabitEthernet2/0/1 destination 
TenGigabitEthernet2/0/0 both
vpp# set interface span TenGigabitEthernet2/0/1 l2 destination 
TenGigabitEthernet2/0/0 both
vpp# show interface span
Source   Destination   Device   L2
TenGigabitEthernet2/ TenGigabitEthernet2/ (  both) (  both)

Are there cases where this would be necessary? Or do the graph nodes for only 
one of {L2, device} get used for a source interface at any given time?

Thanks,
-Matt


-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9076): https://lists.fd.io/g/vpp-dev/message/9076
View All Messages In Topic (1): https://lists.fd.io/g/vpp-dev/topic/18098046
Mute This Topic: https://lists.fd.io/mt/18098046/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] NOTIFICATION: FD.io Maintenance

[Vanessa Valderrama]

Please let me know if the following maintenance schedule conflicts with
your projects.

*Nexus 2018-05-08 - **1700 UTC*

The Nexus maintenance will require a restart of Nexus to bump up the JVM
and run scheduled tasks to clean up the VPP CentOS repositories.  The
size of the repositories, specifically master is causing intermittent
timeouts and slowness.  There is risk in crashing the JVM when we run
the scheduled tasks.

*JIRA & OpenGrok AWS Migration 2018-05-09 - **2100 UTC to 0100 UTC*

Services will be unavailable for approximately 2-3 hours depending on
data transfer.

*Gerrit 2018-05-15 - 2100 UTC to 0100 UTC*

Gerrit will be unavailable for approximately 2-3 hours depending on data
transfer.  Jenkins will be placed in shutdown mode 1 hour prior to the
start of maintenance.

*Sonar 2018-05-16 - **2100 UTC to 0100 UTC*

Sonar will be unavailable for approximately 2-3 hours depending on data
transfer.

Re: [vpp-dev] [csit-dev] VPP 18.04 has been released! Artifacts are available on nexus.fd.io

[Maciek Konstantynowicz (mkonstan)]

Super - Congrats folks !!

-Maciek

On 26 Apr 2018, at 00:56, Dave Wallace 
> wrote:

Most Excellent!

Thanks Chris for all of your work on getting the release out the door.
Also many thanks to all of the VPP committers and FD.io community 
members who contributed to 18.04

Best,
-daw-

On 04/25/2018 06:52 PM, Chris Luke wrote:
All,

I am happy to announce that VPP 18.04 has been released! The release notes can 
be found at https://docs.fd.io/vpp/18.04/release_notes_1804.html.

The various release artifacts have made their way to the right places on 
nexus.fd.io.

Packaging for Centos 7 (Intel), openSUSE Leap 42.3 (Intel), Ubuntu Xenial 
(Intel) and Ubuntu Xenial (ARM) are available. Details on how to install them 
are available at 
https://wiki.fd.io/view/VPP/Installing_VPP_binaries_from_packages.

Packages for the Intel platforms have been tested; I will follow up with ARM 
package testing once I get my arm64 box setup!

Our thanks to all of the VPP and FD.io community who have 
contributed to the 18.04 VPP release.

Cheers,
Chris.

Re: [vpp-dev] [csit-dev] VPP 18.04 has been released! Artifacts are available on nexus.fd.io

[Jerome Tollet]

Congratulations !

De :  au nom de Dave Wallace 
Date : jeudi 26 avril 2018 à 01:56
À : Chris Luke , vpp-dev , 
"csit-...@lists.fd.io" 
Objet : Re: [vpp-dev] [csit-dev] VPP 18.04 has been released! Artifacts are 
available on nexus.fd.io

Most Excellent!

Thanks Chris for all of your work on getting the release out the door.
Also many thanks to all of the VPP committers and FD.io community members who 
contributed to 18.04

Best,
-daw-

On 04/25/2018 06:52 PM, Chris Luke wrote:
All,

I am happy to announce that VPP 18.04 has been released! The release notes can 
be found at https://docs.fd.io/vpp/18.04/release_notes_1804.html.

The various release artifacts have made their way to the right places on 
nexus.fd.io.

Packaging for Centos 7 (Intel), openSUSE Leap 42.3 (Intel), Ubuntu Xenial 
(Intel) and Ubuntu Xenial (ARM) are available. Details on how to install them 
are available at 
https://wiki.fd.io/view/VPP/Installing_VPP_binaries_from_packages.

Packages for the Intel platforms have been tested; I will follow up with ARM 
package testing once I get my arm64 box setup!

Our thanks to all of the VPP and FD.io community who have contributed to the 
18.04 VPP release.

Cheers,
Chris.

Re: [vpp-dev] segfault due to movaps unaligned access

[Radu Nicolau]

Hi Florin,

Thanks! The patch fixes the issue.
Any idea why is it happening?

Regards,
Radu

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Tuesday, April 24, 2018 11:25 PM
To: Nicolau, Radu 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] segfault due to movaps unaligned access

Hi Radu,

Making the crypto_worker_main_t a full cache line in size (see patch [1]) seems 
to solve the issue. Could you confirm?

Florin

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


On Apr 24, 2018, at 9:23 AM, Radu Nicolau 
> wrote:

Hello all,

We’re seeing a weird issue, that is a segfault that looks to be caused by a 
movaps instruction that is trying to access an address that is not 16 byte 
aligned.
The call originates from a vec_validate_init_empty_aligned that has the 
argument aligned to 16 bytes.
I have seen something like this in the past, we couldn’t find a root cause and 
considered it a GCC bug (version 5 then), but now it pops up again on version 
7, so probably it isn’t.
Any idea? A snapshot of the gdb screen below.

gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
https://postimg.cc/image/9jy4p38at/

thanks and I will appreciate any help,
Radu

Re: [vpp-dev] #vpp CGNAT implementation in VPP

[Hamid via Lists.Fd.Io]

Hi,

Found another issue in logging. When we connect to HTTP server via a web
browser, the 'show nat44 deterministic sessions' command shows the result
of the translation. However, when we use curl or wget to fetch the same
page, the translation does not show up in the CLI command. After repeating
curl command multiple times and quickly rechecking the show sessions
command, we were able to capture the translation once out of 10 times.

So, to further check I wrote a script on the inside address to curl the
webserver multiple times and another on VPP machine to call  "vppctl show
nat44 deterministic sessions" repeatedly (after every 10 milliseconds) so I
was able to gather the following results:

vpp# NAT44 deterministic sessions:
  in 100.64.0.5:53696 out 192.168.10.128:22464 external host 192.168.4.2:80
state: tcp-fin-wait expire: 3883
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53698 out 192.168.10.128:22466 external host 192.168.4.2:80
state: tcp-established expire: 3903
NAT44 deterministic sessions:
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53700 out 192.168.10.128:22468 external host 192.168.4.2:80
state: tcp-established expire: 3903
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53702 out 192.168.10.128:22470 external host 192.168.4.2:80
state: tcp-syn-sent expire: 3883
NAT44 deterministic sessions:
  in 100.64.0.5:53702 out 192.168.10.128:22470 external host 192.168.4.2:80
state: tcp-established expire: 3903
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53704 out 192.168.10.128:22472 external host 192.168.4.2:80
state: tcp-established expire: 3903
NAT44 deterministic sessions:
  in 100.64.0.5:53704 out 192.168.10.128:22472 external host 192.168.4.2:80
state: tcp-established expire: 3903
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53706 out 192.168.10.128:22474 external host 192.168.4.2:80
state: tcp-established expire: 3903
NAT44 deterministic sessions:
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53708 out 192.168.10.128:22476 external host 192.168.4.2:80
state: tcp-established expire: 3903
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53710 out 192.168.10.128:22478 external host 192.168.4.2:80
state: tcp-syn-sent expire: 3884
NAT44 deterministic sessions:
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53712 out 192.168.10.128:22480 external host 192.168.4.2:80
state: tcp-established expire: 3904
NAT44 deterministic sessions:
  in 100.64.0.5:53712 out 192.168.10.128:22480 external host 192.168.4.2:80
state: tcp-fin-wait expire: 3884
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53714 out 192.168.10.128:22482 external host 192.168.4.2:80
state: tcp-established expire: 3904
NAT44 deterministic sessions:
  in 100.64.0.5:53714 out 192.168.10.128:22482 external host 192.168.4.2:80
state: tcp-fin-wait expire: 3884
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53716 out 192.168.10.128:22484 external host 192.168.4.2:80
state: tcp-established expire: 3904
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53718 out 192.168.10.128:22486 external host 192.168.4.2:80
state: tcp-established expire: 3904
NAT44 deterministic sessions:
  in 100.64.0.5:53718 out 192.168.10.128:22486 external host 192.168.4.2:80
state: tcp-fin-wait expire: 3884
NAT44 deterministic sessions:
  in 100.64.0.5:53720 out 192.168.10.128:22488 external host 192.168.4.2:80
state: tcp-established expire: 3904
NAT44 deterministic sessions:
  in 100.64.0.5:53720 out 192.168.10.128:22488 external host 192.168.4.2:80
state: tcp-fin-wait expire: 3884
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53722 out 192.168.10.128:22490 external host 192.168.4.2:80
state: tcp-established expire: 3904
NAT44 deterministic sessions:
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53724 out 192.168.10.128:22492 external host 192.168.4.2:80
state: tcp-fin-wait expire: 3884
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53726 out 192.168.10.128:22494 external host 192.168.4.2:80
state: tcp-established expire: 3904
NAT44 deterministic sessions:
  in 100.64.0.5:53726 out 192.168.10.128:22494 external host 192.168.4.2:80
state: tcp-fin-wait expire: 3884
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53728 out 192.168.10.128:22496 external host 192.168.4.2:80
state: tcp-established expire: 3904
NAT44 deterministic sessions:
NAT44 deterministic sessions:
NAT44 deterministic sessions:
  in 100.64.0.5:53730 out 192.168.10.128:22498 external host 192.168.4.2:80
state: tcp-established expire: 3904
NAT44 deterministic sessions:
NAT44 deterministic sessions:



On Wed, Apr 25, 2018 at 11:48 AM, Hamid Rasool 

Re: [vpp-dev] VPP 18.04 has been released! Artifacts are available on nexus.fd.io

[Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES@Cisco)]

Congratulations!

From: csit-...@lists.fd.io [mailto:csit-...@lists.fd.io] On Behalf Of Chris Luke
Sent: 26 kwietnia 2018 00:53
To: vpp-dev ; csit-...@lists.fd.io
Subject: [csit-dev] VPP 18.04 has been released! Artifacts are available on 
nexus.fd.io

All,

I am happy to announce that VPP 18.04 has been released! The release notes can 
be found at https://docs.fd.io/vpp/18.04/release_notes_1804.html.

The various release artifacts have made their way to the right places on 
nexus.fd.io.

Packaging for Centos 7 (Intel), openSUSE Leap 42.3 (Intel), Ubuntu Xenial 
(Intel) and Ubuntu Xenial (ARM) are available. Details on how to install them 
are available at 
https://wiki.fd.io/view/VPP/Installing_VPP_binaries_from_packages.

Packages for the Intel platforms have been tested; I will follow up with ARM 
package testing once I get my arm64 box setup!

Our thanks to all of the VPP and FD.io community who have contributed to the 
18.04 VPP release.

Cheers,
Chris.