Re: [vpp-dev] Another fix to avoid assertion failure related to vlib_time_now()

[Ole Troan]

Hi Elias,

Thanks for fixing these.
You could just call vlib_get_main() instead of passing thread_index (for now).

Cheers,
Ole

> On 27 May 2020, at 03:49, Elias Rudberg  wrote:
> 
> Hello again,
> 
> Here is another fix to avoid assertion failure due to vlib_time_now()
> being called with a vm corresponding to a different thread, in
> nat_ipfix_logging.c:
> 
> https://gerrit.fd.io/r/c/vpp/+/27281
> 
> Please have a look and merge if it seems okay. Maybe it could be done
> more elegantly, this way required changing in several places to pass
> along the thread_index value.
> 
> Best regards,
> Elias
> 
> 

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

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

Re: [vpp-dev] Fix in set_ipfix_exporter_command_fn() to avoid segmentation fault crash

[Ole Troan]

Hi Elias,

Thanks for spotting that.
Just make collector_port a u32 and add a boundary check?

Best regards,
Ole

> On 27 May 2020, at 03:27, Elias Rudberg  wrote:
> 
> Hello VPP experts,
> 
> When testing the current master branch for NAT with ipfix logging
> enabled we encountered a problem with a segmentation fault crash. It
> seems like this was caused by a bug in set_ipfix_exporter_command_fn()
> in vnet/ipfix-export/flow_report.c where the variable collector_port
> is declared as u16:
> 
> u16 collector_port = UDP_DST_PORT_ipfix;
> 
> and then a few lines later the address of that variable is given as
> argument to unformat() with %u like this:
> 
> else if (unformat (input, "port %u", &collector_port))
> 
> I think that is wrong because %u should correspond to a 32-bit
> variable, so when passing the address of a 16-bit variable some data
> next to it can get corrupted. In our case what happened was that the
> "fib_index" variable that happened to be nearby on the stack got
> corrupted, leading to a crash later on.
> 
> The problem only appears for release build and not for debug, perhaps
> because compiler optimization affects how variables are stored on the
> stack. It could be that the compiler (clang or gcc) also matters, that
> could explain why the problem was not seen earlier.
> 
> Here is a fix, please check it and merge if you agree:
> https://gerrit.fd.io/r/c/vpp/+/27280
> 
> Best regards,
> Elias
> 

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

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

Re: [vpp-dev] Spike in core VPP VSZ

[siddarth rai]

Hi Damjan,

I have tried the latest master and it seems that the core size is around
1.3 G , as you mentioned above.
However, the VPP VSZ is still around 16G. This used to be low in earlier
released(around 2G)

Can you give any hint why the Virtual size has increased so much?

The pmap output is attached above.

Regards,
Siddarth

On Wed, Apr 1, 2020 at 6:18 PM Damjan Marion  wrote:

>
> Not sure about 19.08 but i just tried on latest master.
> Without dpdk core size is is 1.29G uncompressed and 1.31G with dpdk plugin
> loaded.
>
> —
> Damjan
>
> On 1 Apr 2020, at 14:09, siddarth rai  wrote:
>
> Hi,
> I am using VPP version v19.08.1
> I have noticed that the virtual memory size for core VPP has increased a
> lot since the last VPP I used(v 18.01)
>
> Earlier it used to be ~2 G, but now its up to ~16 G. This is causing the
> VPP core-dump files to bloat up.
> When I say core VPP I mean VPP *without* any plugins.
>
> Can anyone tell what changes caused this increase in VPP VSZ ? Is there
> any way to reduce it ?
>
> I am attaching pmap output of VPP started with default configuration
>
> https://pastebin.com/0nKwFyHF
>
> Regards,
> Siddarth
>
> 
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution giving error

[Chinmaya Aggarwal]

Hi,
Attached is the sample VPP commands script, having a delay of 50 ms. Below is 
the screenshot of he output we get on running the script : -
Request 88 :  time 14:05:01.906
Request 89 :  time 14:05:01.906
Request 90 :  time 14:05:02.043
_____   _  ___
 __/ __/ _ \  (_)__| | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/

vpp# Request 91 :  time 14:05:02.043
_____   _  ___
 __/ __/ _ \  (_)__| | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/

vpp# Request 92 :  time 14:05:02.213
Request 93 :  time 14:05:02.213
Request 94 :  time 14:05:02.358

The commands are executed sequentially at a gap of 50 ms. As seen from the 
execution time displayed by the script, we never see a situation where the gap 
is more than 1 sec.
Can you please guide us through this?

From: Luke, Chris 
Sent: Tuesday, May 26, 2020 7:09 PM
To: Chinmaya Aggarwal ; vpp-dev@lists.fd.io 

Subject: RE: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error


CAUTION:This email originated from an external organization

You’ll get the banner if it thinks it’s an interactive session.



Roughly vppctl does this (I am paraphrasing):



is_interactive = isatty(STDIN);

…

if (is_interactive) TERM = “vppctl”;

…

open telnet session to the CLI socket; pass the terminal information



Then in VPP:



is_interactive = (strcmp(TERM, “vppctl”) != 0);

…

if (is_interactive) emit_banner();



The passing of the terminal options in the TELNET protocol is bounded by a 
timer (1 second); if for whatever reason that information arrives late, VPP 
will make assumptions; typically that the terminal is of the ‘dumb’ type rather 
than non-interactive.



Does this correlate to what you are observing? Does the output you see make use 
of ANSI color? That would be another clue, the ‘dumb’ terminal doesn’t use 
color.



Chris.





From: vpp-dev@lists.fd.io  On Behalf Of Chinmaya Aggarwal
Sent: Tuesday, May 26, 2020 08:19
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error



Further adding to observations regarding above issue, we have created a script 
that has only vpp commands running sequentially having a constant delay between 
the execution of each commands. On running the script, we again see VPP shell 
output as shown below :-

_____   _  ___

 __/ __/ _ \  (_)__| | / / _ \/ _ \

 _/ _// // / / / _ \   | |/ / ___/ ___/

 /_/ /(_)_/\___/   |___/_/  /_/

We executed the script with delay of 10ms, 50ms and 100ms. In most of the 
cases, we get no output from vppctl command but in some random times, we get 
the vpp shell as output of the command.



Please suggest, in what scenarios does the vpp return this kind of output?

DISCLAIMER: This electronic message and all of its contents, contains 
information which is privileged, confidential or otherwise protected from 
disclosure. The information contained in this electronic mail transmission is 
intended for use only by the individual or entity to which it is addressed. If 
you are not the intended recipient or may have received this electronic mail 
transmission in error, please notify the sender immediately and delete / 
destroy all copies of this electronic mail transmission without disclosing, 
copying, distributing, forwarding, printing or retaining any part of it. Hughes 
Systique accepts no responsibility for loss or damage arising from the use of 
the information transmitted by this email including damage from virus.
echo " request 1"
counter=1
vppctl sr policy add bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98 next 2001:19:c1::1 insert spray weight 1
vppctl sr policy mod bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98 add sl next 2001:19:c2::1 insert spray weight 1
vppctl sr steer l3 2001:5b0:5678:1::/64 via bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98
sleep 0.050
request1_time="$(date +"%T.%3N")"
echo "Request $counter :  time $request1_time"
vppctl sr policy mod bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98 del sl index 0 && echo " unicast request 1 " ;
sleep 0.050
for ((i=2;i<=50;i++)); do
  # echo " request $i"
   counter=$((counter+1))
   request1_time="$(date +"%T.%3N")"
   echo "Request $counter :  time $request1_time"
   vppctl sr policy mod bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98 add sl next 2001:19:c1::1 insert spray weight 1;
   sleep 0.050
   counter=$((counter+1))
   request2_time="$(date +"%T.%3N")"
   echo "Request $counter :  time $request1_time"
   vppctl sr policy mod bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98 del sl index 0;
   sleep 0.050
done
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16524): https://lists.fd.io/g/vpp-dev/message/16524
Mute This Topic: https://lists.fd.io/mt/74477335/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: ht

Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution giving error

[Chinmaya Aggarwal]

Attached is the sample VPP commands script, having a delay of 50 ms. Below is 
the screenshot of he output we get on running the script : -
Request 88 :  time 14:05:01.906
Request 89 :  time 14:05:01.906
Request 90 :  time 14:05:02.043
___    _        _   _  ___
__/ __/ _ \  (_)__    | | / / _ \/ _ \
_/ _// // / / / _ \   | |/ / ___/ ___/
/_/ /(_)_/\___/   |___/_/  /_/

vpp# Request 91 :  time 14:05:02.043
___    _        _   _  ___
__/ __/ _ \  (_)__    | | / / _ \/ _ \
_/ _// // / / / _ \   | |/ / ___/ ___/
/_/ /(_)_/\___/   |___/_/  /_/

vpp# Request 92 :  time 14:05:02.213
Request 93 :  time 14:05:02.213
Request 94 :  time 14:05:02.358

The commands are executed sequentially at a gap of 50 ms. As seen from the 
execution time displayed by the script, we never see a situation where the gap 
is more than 1 sec.
Can you please guide us through this?
echo " request 1"
counter=1
vppctl sr policy add bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98 next 2001:19:c1::1 insert spray weight 1
vppctl sr policy mod bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98 add sl next 2001:19:c2::1 insert spray weight 1
vppctl sr steer l3 2001:5b0:5678:1::/64 via bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98
sleep 0.050
request1_time="$(date +"%T.%3N")"
echo "Request $counter :  time $request1_time"
vppctl sr policy mod bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98 del sl index 0 && echo " unicast request 1 " ;
sleep 0.050
for ((i=2;i<=50;i++)); do
  # echo " request $i"
   counter=$((counter+1))
   request1_time="$(date +"%T.%3N")"
   echo "Request $counter :  time $request1_time"
   vppctl sr policy mod bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98 add sl next 2001:19:c1::1 insert spray weight 1;
   sleep 0.050
   counter=$((counter+1))
   request2_time="$(date +"%T.%3N")"
   echo "Request $counter :  time $request1_time"
   vppctl sr policy mod bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98 del sl index 0;
   sleep 0.050
done
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution giving error

[Chinmaya Aggarwal]

Attached is the sample VPP commands script, having a delay of 50 ms. Below is 
the screenshot of he output we get on running the script : -
Request 88 :  time 14:05:01.906
Request 89 :  time 14:05:01.906
Request 90 :  time 14:05:02.043
_____   _  ___
 __/ __/ _ \  (_)__| | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/

vpp# Request 91 :  time 14:05:02.043
_____   _  ___
 __/ __/ _ \  (_)__| | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/

vpp# Request 92 :  time 14:05:02.213
Request 93 :  time 14:05:02.213
Request 94 :  time 14:05:02.358

The commands are executed sequentially at a gap of 50 ms. As seen from the 
execution time displayed by the script, we never see a situation where the gap 
is more than 1 sec.
Can you please guide us through this?

Thanks and Regards,
Chinmaya Agarwal.

From: Luke, Chris 
Sent: Tuesday, May 26, 2020 7:34 PM
To: Luke, Chris ; Chinmaya Aggarwal 
; vpp-dev@lists.fd.io 
Subject: RE: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error


CAUTION:This email originated from an external organization

Actually, I missed one detail, if you tell vppctl to run a command using its 
command line arguments, it will always assume non-interactive.



The only way you’ll see the banner, then, is if the 1s session startup timer 
expires and it makes assumptions. In those cases that you see the output, does 
the script you run stall for a second?



Chris.



From: vpp-dev@lists.fd.io  On Behalf Of Chris Luke
Sent: Tuesday, May 26, 2020 09:40
To: Chinmaya Aggarwal ; vpp-dev@lists.fd.io
Subject: Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error



You’ll get the banner if it thinks it’s an interactive session.



Roughly vppctl does this (I am paraphrasing):



is_interactive = isatty(STDIN);

…

if (is_interactive) TERM = “vppctl”;

…

open telnet session to the CLI socket; pass the terminal information



Then in VPP:



is_interactive = (strcmp(TERM, “vppctl”) != 0);

…

if (is_interactive) emit_banner();



The passing of the terminal options in the TELNET protocol is bounded by a 
timer (1 second); if for whatever reason that information arrives late, VPP 
will make assumptions; typically that the terminal is of the ‘dumb’ type rather 
than non-interactive.



Does this correlate to what you are observing? Does the output you see make use 
of ANSI color? That would be another clue, the ‘dumb’ terminal doesn’t use 
color.



Chris.





From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Chinmaya Aggarwal
Sent: Tuesday, May 26, 2020 08:19
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error



Further adding to observations regarding above issue, we have created a script 
that has only vpp commands running sequentially having a constant delay between 
the execution of each commands. On running the script, we again see VPP shell 
output as shown below :-

_____   _  ___

 __/ __/ _ \  (_)__| | / / _ \/ _ \

 _/ _// // / / / _ \   | |/ / ___/ ___/

 /_/ /(_)_/\___/   |___/_/  /_/

We executed the script with delay of 10ms, 50ms and 100ms. In most of the 
cases, we get no output from vppctl command but in some random times, we get 
the vpp shell as output of the command.



Please suggest, in what scenarios does the vpp return this kind of output?

DISCLAIMER: This electronic message and all of its contents, contains 
information which is privileged, confidential or otherwise protected from 
disclosure. The information contained in this electronic mail transmission is 
intended for use only by the individual or entity to which it is addressed. If 
you are not the intended recipient or may have received this electronic mail 
transmission in error, please notify the sender immediately and delete / 
destroy all copies of this electronic mail transmission without disclosing, 
copying, distributing, forwarding, printing or retaining any part of it. Hughes 
Systique accepts no responsibility for loss or damage arising from the use of 
the information transmitted by this email including damage from virus.
echo " request 1"
counter=1
vppctl sr policy add bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98 next 
2001:19:c1::1 insert spray weight 1
vppctl sr policy mod bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98 add sl next 
2001:19:c2::1 insert spray weight 1
vppctl sr steer l3 2001:5b0:5678:1::/64 via bsid 
6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98
sleep 0.050
request1_time="$(date +"%T.%3N")"
echo "Request $counter :  time $request1_time"
vppctl sr policy mod bsid 6d97:5fd3:fd2b:ee77:24a0:d358:c873:9a98 del sl index 
0 && echo " unicast request 1 " ;
sleep 0.050
for ((i=2;i<=50;i++)); do
  # echo " request $i"
   cou

[vpp-dev] IPFIX Export not sending Data Sets #ipfix-export #vpp

[mauricio.solisjr via lists.fd.io]

[Edited Message Follows]
[Reason: added diagram of what i'm trying to acheive]

Hi,

I have successfully set ipfix export (to some extent) and I can see the 
template set and records I have configured in the vpp is in fac being sent and 
received by tap0.  I'm using scapy, session NetflowSession to verify this and 
tcpdump.  Everything about the template record looks fine, but I'm not 
receiving any data records with it, only the template records. I can see the 
telemetry information in the decap vpp, along with data from other nodes, via 
"show trace".

Here is was I did to get ipfix export working. Please let me know if I've 
missed anything.
There is already a post similar to this one ( 
https://lists.fd.io/g/vpp-dev/topic/69246061?p=Created,,,20,1,0,0 ) ,but not 
much is given to help resolve.  I'm not using dpdk too.

*vpp version 20.01*

Also, can someone explain the active and passive times in flowprobe?

Here is a diagram of what I'm trying to achieve.  I'm simply trying to use 
collector.py to sniff on tap0 to collect telemetry data.
I'm only seeing template sets and no data sets

Decap Node;
IOAM configs
set ioam-trace profile trace-type 0x1f trace-elts 3 trace-tsp 2 node-id 0xf 
app-data 0xD000
classify table miss-next ip6-node ip6-lookup mask l3 ip6 dst
classify session acl-hit-next ip6-node ip6-lookup table-index 0 match l3 ip6 
dst db04::2 opaque-index 100 ioam-decap test1
set int input acl intfc host- ci0 ip6-table 0
set int input acl intfc host- ci1 ip6-table 0

Tap interface for collector
create tap id 0
set interface ip address tap0 10.10.1.1/24
set interface state tap0 up

IPFIX configs
flowprobe params record l2 l3 l4 active 1 passive 10
flowprobe feature add-del tap0 ip4
set ipfix exporter collector 10.10.1.2 src 10.10.1.1 template-interval 1 
path-mtu 1450
trace add af-packet-input 255

Notes:
I've set tap0 mtu to 1450 on host side
I have also noted that "set ioam export ipfix collector 10.10.1.2 src 
10.10.1.1" does not seem to do anything. Is this correct?!?
The command that 'allows' ipfix export to work is the "set ipfix exporter 
collector "
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] Spike in core VPP VSZ

[Damjan Marion via lists.fd.io]

We reserve continuous address space…..

> On 27 May 2020, at 10:14, siddarth rai  wrote:
> 
> Hi Damjan,
> 
> I have tried the latest master and it seems that the core size is around 1.3 
> G , as you mentioned above.
> However, the VPP VSZ is still around 16G. This used to be low in earlier 
> released(around 2G)
> 
> Can you give any hint why the Virtual size has increased so much?

We reserve continuous address space so we can grow buffer pools and physical 
memory dynamically.

What is your problem with that?

— 
Damjan



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

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

[vpp-dev] Regarding support for MSTP in VPP

[Intelligent Learning [ Proverb 18:15]]

Hi,

Kindly let us know if VPP supports MSTP or STP.
Do we have any plan for adding port status in structure  vnet_hw_interface_t.

Do we have any data structure which is already available to set port status to 
learn/forward/blocking etc..



Regards,
M. Kavitha-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution giving error

[Chris Luke]

That is quite odd indeed.  This is the sort of issue that could take some time 
to properly diagnose and I cannot dig in to it right away. For now, if you are 
not using the output, perhaps as a workaround simply redirect stdout to 
/dev/null?

That said, if this part of a larger application, I suspect SR provides API 
access and that will generally be much more performant than using vppctl.

Chris.

From: Chinmaya Aggarwal 
Sent: Wednesday, May 27, 2020 05:47
To: Luke, Chris ; vpp-dev@lists.fd.io
Subject: Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error

Attached is the sample VPP commands script, having a delay of 50 ms. Below is 
the screenshot of he output we get on running the script : -
Request 88 :  time 14:05:01.906
Request 89 :  time 14:05:01.906
Request 90 :  time 14:05:02.043
_____   _  ___
 __/ __/ _ \  (_)__| | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/

vpp# Request 91 :  time 14:05:02.043
_____   _  ___
 __/ __/ _ \  (_)__| | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /(_)_/\___/   |___/_/  /_/

vpp# Request 92 :  time 14:05:02.213
Request 93 :  time 14:05:02.213
Request 94 :  time 14:05:02.358

The commands are executed sequentially at a gap of 50 ms. As seen from the 
execution time displayed by the script, we never see a situation where the gap 
is more than 1 sec.
Can you please guide us through this?

Thanks and Regards,
Chinmaya Agarwal.

From: Luke, Chris mailto:chris_l...@comcast.com>>
Sent: Tuesday, May 26, 2020 7:34 PM
To: Luke, Chris mailto:chris_l...@comcast.com>>; 
Chinmaya Aggarwal mailto:chinmaya.agar...@hsc.com>>; 
vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error


CAUTION:This email originated from an external organization

Actually, I missed one detail, if you tell vppctl to run a command using its 
command line arguments, it will always assume non-interactive.



The only way you'll see the banner, then, is if the 1s session startup timer 
expires and it makes assumptions. In those cases that you see the output, does 
the script you run stall for a second?



Chris.



From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Chris Luke
Sent: Tuesday, May 26, 2020 09:40
To: Chinmaya Aggarwal 
mailto:chinmaya.agar...@hsc.com>>; 
vpp-dev@lists.fd.io
Subject: Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error



You'll get the banner if it thinks it's an interactive session.



Roughly vppctl does this (I am paraphrasing):



is_interactive = isatty(STDIN);

...

if (is_interactive) TERM = "vppctl";

...

open telnet session to the CLI socket; pass the terminal information



Then in VPP:



is_interactive = (strcmp(TERM, "vppctl") != 0);

...

if (is_interactive) emit_banner();



The passing of the terminal options in the TELNET protocol is bounded by a 
timer (1 second); if for whatever reason that information arrives late, VPP 
will make assumptions; typically that the terminal is of the 'dumb' type rather 
than non-interactive.



Does this correlate to what you are observing? Does the output you see make use 
of ANSI color? That would be another clue, the 'dumb' terminal doesn't use 
color.



Chris.





From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Chinmaya Aggarwal
Sent: Tuesday, May 26, 2020 08:19
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution 
giving error



Further adding to observations regarding above issue, we have created a script 
that has only vpp commands running sequentially having a constant delay between 
the execution of each commands. On running the script, we again see VPP shell 
output as shown below :-

_____   _  ___

 __/ __/ _ \  (_)__| | / / _ \/ _ \

 _/ _// // / / / _ \   | |/ / ___/ ___/

 /_/ /(_)_/\___/   |___/_/  /_/

We executed the script with delay of 10ms, 50ms and 100ms. In most of the 
cases, we get no output from vppctl command but in some random times, we get 
the vpp shell as output of the command.



Please suggest, in what scenarios does the vpp return this kind of output?
DISCLAIMER: This electronic message and all of its contents, contains 
information which is privileged, confidential or otherwise protected from 
disclosure. The information contained in this electronic mail transmission is 
intended for use only by the individual or entity to which it is addressed. If 
you are not the intended recipient or may have received this electronic mail 
transmission in error, please notify the sender immediately and delete / 
destroy all copies of this electronic mail transm

[vpp-dev] generic TCP MSS clamping

[Miklos Tirpak]

Hi,

I see the NAT plugin already supports TCP MSS clamping but it is implemented 
only in in2out direction.

We have endpoints with wrong MTUs behind tunnels and not all the traffic is 
NATed. Hence, it would be very nice to have generic support for MSS clamping 
that could be enabled on the tunnel interface.

Do you think implementing this as a feature arch would make sense? Then it 
would not be limited to NAT or to one kind of tunnel for example.
If so, what is the best place? A new plugin?

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

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

Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command execution giving error

[Dave Wallace]

+1

Also, please be aware that the VPP cli is by design "The Debug CLI" and 
is not intended for use as a production API.
VPP cli commands can be changed without warning and without any 
guarantee of backwards compatibility.


Thanks,
-daw-

On 5/27/2020 8:53 AM, Chris Luke wrote:


That is quite odd indeed.  This is the sort of issue that could take 
some time to properly diagnose and I cannot dig in to it right away. 
For now, if you are not using the output, perhaps as a workaround 
simply redirect stdout to /dev/null?


That said, if this part of a larger application, I suspect SR provides 
API access and that will generally be much more performant than using 
vppctl.


Chris.

*From:*Chinmaya Aggarwal 
*Sent:* Wednesday, May 27, 2020 05:47
*To:* Luke, Chris ; vpp-dev@lists.fd.io
*Subject:* Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command 
execution giving error


Attached is the sample VPP commands script, having a delay of 50 ms. 
Below is the screenshot of he output we get on running the script : -


Request 88 :  time 14:05:01.906

Request 89 :  time 14:05:01.906

Request 90 :  time 14:05:02.043

  ___    _        _   _  ___

 __/ __/ _ \  (_)__    | | / / _ \/ _ \

 _/ _// // / / / _ \   | |/ / ___/ ___/

 /_/ /(_)_/\___/   |___/_/  /_/

vpp# Request 91 :  time 14:05:02.043

  ___    _        _   _  ___

 __/ __/ _ \  (_)__    | | / / _ \/ _ \

 _/ _// // / / / _ \   | |/ / ___/ ___/

 /_/ /(_)_/\___/   |___/_/  /_/

vpp# Request 92 :  time 14:05:02.213

Request 93 :  time 14:05:02.213

Request 94 :  time 14:05:02.358

The commands are executed sequentially at a gap of 50 ms. As seen from 
the execution time displayed by the script, we never see a situation 
where the gap is more than 1 sec.


Can you please guide us through this?

Thanks and Regards,

Chinmaya Agarwal.



*From:*Luke, Chris >

*Sent:* Tuesday, May 26, 2020 7:34 PM
*To:* Luke, Chris >; Chinmaya Aggarwal 
mailto:chinmaya.agar...@hsc.com>>; 
vpp-dev@lists.fd.io  >
*Subject:* RE: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command 
execution giving error


CAUTION:This email originated from an external organization

Actually, I missed one detail, if you tell vppctl to run a command 
using its command line arguments, it will always assume non-interactive.


The only way you’ll see the banner, then, is if the 1s session startup 
timer expires and it makes assumptions. In those cases that you see 
the output, does the script you run stall for a second?


Chris.

*From:* vpp-dev@lists.fd.io  
mailto:vpp-dev@lists.fd.io>> *On Behalf Of 
*Chris Luke

*Sent:* Tuesday, May 26, 2020 09:40
*To:* Chinmaya Aggarwal >; vpp-dev@lists.fd.io 

*Subject:* Re: [EXTERNAL] Re: [vpp-dev] VPP sequential policy command 
execution giving error


You’ll get the banner if it thinks it’s an interactive session.

Roughly vppctl does this (I am paraphrasing):

is_interactive = isatty(STDIN);

…

if (is_interactive) TERM = “vppctl”;

…

open telnet session to the CLI socket; pass the terminal information

Then in VPP:

is_interactive = (strcmp(TERM, “vppctl”) != 0);

…

if (is_interactive) emit_banner();

The passing of the terminal options in the TELNET protocol is bounded 
by a timer (1 second); if for whatever reason that information arrives 
late, VPP will make assumptions; typically that the terminal is of the 
‘dumb’ type rather than non-interactive.


Does this correlate to what you are observing? Does the output you see 
make use of ANSI color? That would be another clue, the ‘dumb’ 
terminal doesn’t use color.


Chris.

*From:* vpp-dev@lists.fd.io  
mailto:vpp-dev@lists.fd.io>> *On Behalf Of 
*Chinmaya Aggarwal

*Sent:* Tuesday, May 26, 2020 08:19
*To:* vpp-dev@lists.fd.io 
*Subject:* [EXTERNAL] Re: [vpp-dev] VPP sequential policy command 
execution giving error


Further adding to observations regarding above issue, we have created 
a script that has only vpp commands running sequentially having a 
constant delay between the execution of each commands. On running the 
script, we again see VPP shell output as shown below :-


___    _        _   _  ___

 __/ __/ _ \  (_)__    | | / / _ \/ _ \

 _/ _// // / / / _ \   | |/ / ___/ ___/

 /_/ /(_)_/\___/   |___/_/  /_/


We executed the script with delay of 10ms, 50ms and 100ms. In
most of the cases, we get no output from vppctl command but in
some random times, we get the vpp shell as output of the command.

Please suggest, in what scenarios does the vpp return this kind of output?

DISCLAIMER: This electronic message and all of its contents, contains 
information which is privileged, confidential or other

Re: [vpp-dev] Fix in set_ipfix_exporter_command_fn() to avoid segmentation fault crash

[Elias Rudberg]

Hi Ole,

OK, now I have changed the patch to include a bounds check. This is
still using an intermediate u32 variable however, I tried making
collector_port a u32 but then one of the Gerrit tests failed, I wasn't
able to figure out why as I could not reproduce that problem on my end,
it happened only in one of the gerrit test cases. This way, with a
temporary u32 variable that is copied to the u16 collector_port after
the bounds check, both solves the crash for me and passes the Gerrit
tests:

https://gerrit.fd.io/r/c/vpp/+/27280

What do you think, is this an acceptable solution?
(Otherwise it would be necessary to dig deeper into what went wrong in
the gerrit tests when collector_port was declared as u32.)

Best regards,
Elias


On Wed, 2020-05-27 at 09:15 +0200, Ole Troan wrote:
> Hi Elias,
> 
> Thanks for spotting that.
> Just make collector_port a u32 and add a boundary check?
> 
> Best regards,
> Ole
> 
> [...]
> > 
> > Here is a fix, please check it and merge if you agree:
> > https://gerrit.fd.io/r/c/vpp/+/27280
> > 
> > Best regards,
> > Elias
> > 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] RPM packaging on "stable/2005" branch maybe broken on suse leap 15.1 #vpp

[pashinho1990]

Hi all,

All worked just fine as I was on top of "stable/2001" branch, but today I 
rebased my work on top of "stable/2005" and did a "make pkg-rpm" which breaks 
right at the end at the "vpp-papi" build stage.
Specifically:
> 
> ...
> running install_egg_info
> running egg_info
> creating vpp_papi.egg-info
> writing requirements to vpp_papi.egg-info/requires.txt
> writing vpp_papi.egg-info/PKG-INFO
> writing top-level names to vpp_papi.egg-info/top_level.txt
> writing dependency_links to vpp_papi.egg-info/dependency_links.txt
> writing manifest file 'vpp_papi.egg-info/SOURCES.txt'
> reading manifest file 'vpp_papi.egg-info/SOURCES.txt'
> writing manifest file 'vpp_papi.egg-info/SOURCES.txt'
> Copying vpp_papi.egg-info to
> /root/tmp/vpp/build-root/rpmbuild/BUILDROOT/vpp-20.05-rc2~10_g31ba8e8cb.x86_64/usr/lib/python2.7/site-packages/vpp_papi-1.6.2-py2.7.egg-info
> 
> running install_scripts
> + mkdir -p -m755
> /root/tmp/vpp/build-root/rpmbuild/BUILDROOT/vpp-20.05-rc2~10_g31ba8e8cb.x86_64/usr/lib/python2.7/site-packages/vpp_papi
> 
> ++ find
> '/root/tmp/vpp/build-root/rpmbuild/BUILDROOT/vpp-20.05-rc2~10_g31ba8e8cb.x86_64/../../BUILD/vpp-20.05/build-root/install-vpp-native//*/lib/python2.7/site-packages/'
> -type f -print
> ++ grep -v pyc
> find:
> ‘/root/tmp/vpp/build-root/rpmbuild/BUILDROOT/vpp-20.05-rc2~10_g31ba8e8cb.x86_64/../../BUILD/vpp-20.05/build-root/install-vpp-native//*/lib/python2.7/site-packages/’:
> No such file or directory

Apparently, the "find" cmd is trying to watch into 
"/build-root/rpmbuild/BUILD/vpp-20.05/build-root/install-vpp-native/[external|vom|vpp]/lib/"
 where, in fact, I don't see any "python2.7" folder. Is this an issue on my 
end, or how can I understand this? Please someone do let me know.

The system is an openSUSE Leap 15.1

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

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

Re: [vpp-dev] Fix in set_ipfix_exporter_command_fn() to avoid segmentation fault crash

[Andrew Yourtchenko]

Basic LISP test - was it the one that was failing for you ?

That particular test intermittently failed a couple of times for me as well, on 
a doc-only change, so we have an unrelated issue.

I am running it locally to see what is going on.

--a

> On 27 May 2020, at 18:25, Elias Rudberg  wrote:
> 
> Hi Ole,
> 
> OK, now I have changed the patch to include a bounds check. This is
> still using an intermediate u32 variable however, I tried making
> collector_port a u32 but then one of the Gerrit tests failed, I wasn't
> able to figure out why as I could not reproduce that problem on my end,
> it happened only in one of the gerrit test cases. This way, with a
> temporary u32 variable that is copied to the u16 collector_port after
> the bounds check, both solves the crash for me and passes the Gerrit
> tests:
> 
> https://gerrit.fd.io/r/c/vpp/+/27280
> 
> What do you think, is this an acceptable solution?
> (Otherwise it would be necessary to dig deeper into what went wrong in
> the gerrit tests when collector_port was declared as u32.)
> 
> Best regards,
> Elias
> 
> 
>> On Wed, 2020-05-27 at 09:15 +0200, Ole Troan wrote:
>> Hi Elias,
>> 
>> Thanks for spotting that.
>> Just make collector_port a u32 and add a boundary check?
>> 
>> Best regards,
>> Ole
>> 
>> [...]
>>> 
>>> Here is a fix, please check it and merge if you agree:
>>> https://gerrit.fd.io/r/c/vpp/+/27280
>>> 
>>> Best regards,
>>> Elias
>>> 
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] Fix in set_ipfix_exporter_command_fn() to avoid segmentation fault crash

[Elias Rudberg]

Hi Andrew,

Yes, it was Basic LISP test. It looked like this in the console.log.gz
for vpp-verify-master-ubuntu1804:

===
===
TEST RESULTS:
 Scheduled tests: 1177
  Executed tests: 1176
Passed tests: 1039
   Skipped tests: 137
  Not Executed tests: 1
  Errors: 1
FAILURES AND ERRORS IN TESTS:
  Testcase name: Basic LISP test 
  ERROR: Test case for basic encapsulation
[test_lisp.TestLisp.test_lisp_basic_encap]
TESTCASES WHERE NO TESTS WERE SUCCESSFULLY EXECUTED:
  Basic LISP test 
===
===

/ Elias



On Wed, 2020-05-27 at 18:42 +0200, Andrew 👽 Yourtchenko wrote:
> Basic LISP test - was it the one that was failing for you ?
> 
> That particular test intermittently failed a couple of times for me
> as well, on a doc-only change, so we have an unrelated issue.
> 
> I am running it locally to see what is going on.
> 
> --a
> 
> > 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] Fix in set_ipfix_exporter_command_fn() to avoid segmentation fault crash

[Andrew Yourtchenko]

Yep, so it looks like we have an issue...

https://gerrit.fd.io/r/c/vpp/+/27305 has the same failures, I am rerunning it 
now to see how intermittent it is - as well as testing the latest master 
locally

--a

> On 27 May 2020, at 18:56, Elias Rudberg  wrote:
> 
> Hi Andrew,
> 
> Yes, it was Basic LISP test. It looked like this in the console.log.gz
> for vpp-verify-master-ubuntu1804:
> 
> ===
> ===
> TEST RESULTS:
> Scheduled tests: 1177
>  Executed tests: 1176
>Passed tests: 1039
>   Skipped tests: 137
>  Not Executed tests: 1
>  Errors: 1
> FAILURES AND ERRORS IN TESTS:
>  Testcase name: Basic LISP test 
>  ERROR: Test case for basic encapsulation
> [test_lisp.TestLisp.test_lisp_basic_encap]
> TESTCASES WHERE NO TESTS WERE SUCCESSFULLY EXECUTED:
>  Basic LISP test 
> ===
> ===
> 
> / Elias
> 
> 
> 
>> On Wed, 2020-05-27 at 18:42 +0200, Andrew 👽 Yourtchenko wrote:
>> Basic LISP test - was it the one that was failing for you ?
>> 
>> That particular test intermittently failed a couple of times for me
>> as well, on a doc-only change, so we have an unrelated issue.
>> 
>> I am running it locally to see what is going on.
>> 
>> --a
>> 
>>> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] GTPu Question

[Govindarajan Mohandoss]

Thanks Andreas !!


From: Andreas Schultz 
Sent: Tuesday, May 26, 2020 4:14 PM
To: Govindarajan Mohandoss 
Cc: vpp-dev@lists.fd.io; nd 
Subject: Re: [vpp-dev] GTPu Question

Hi Govind,

I'm NOT one of the GTPu maintainers, but I do work on a UPF implementation 
based on VPP.

The GTPu plugin is IMHO mostly useless and broken by design in its current 
state. It assumes that TEIDs are symmetric which they never are in real 3GPP 
settings.
There is an outdated change in gerrit (https://gerrit.fd.io/r/c/vpp/+/13134) 
that corrects that and other deficits.

AFAIK there is no GTP-C control interface that can control the GTP-U plugin 
through VPPs binaries API. Only static tunnels through the CLI are doable (I 
have not tested that myself). A real PGW/GGSN is therefore not doable.

The plugin also has no support for 3GPP compliant charging and QoS. This would 
be a major problem in case you want to evaluate performance as those areas are 
the ones that introduce the highest complexity. Performance tests on pure GTP 
encap/decap are IMHO useless for real world GTP use cases.

Regards,
Andreas

Am Di., 26. Mai 2020 um 05:18 Uhr schrieb Govindarajan Mohandoss 
mailto:govindarajan.mohand...@arm.com>>:

Dear GTPu Owners,

   I need some help in creating GTPu Origination and Termination config in DUT 
(Running VPP) as described below.



GTPu Origination:



[cid:image005.png@01D63420.3CBD6010]



GTPu Termination:



[cid:image006.png@01D63420.3CBD6010]

Whether GTPu plugin has the support to do such mapping (or) I need to write a 
test plugin to do such mapping ?



I found some information in the below link explaining about GTPu Tunneling.

https://wiki.fd.io/view/VPP/Per-feature_Notes#VRF.2C_Table_Ids_and_Routing

As per the example, foll. are the VPP CLI commands to create a GTPu Tunnel.  
But I don’t follow the commands. Please see inline.



“

loop create

set int state loop0 up

set int ip addr loop0 1.1.1.1/32   << Can the IP address be 
created on a physical interface connecting the next node in GTPu Origination 
Topology mentioned above ?

create gtpu tunnel src 1.1.1.1 dst 10.6.6.6 teid  decap-next ip4 << What 
does “decap-next” mean ?

set int ip addr gptu_tunnel0 1.1.1.2/31 << Why the IP 
address is assigned to GTPu Tunnel interface ?

“



For the GTPu origination case:

How can I associate the incoming Ethernet traffic to GTPu Tunnel config ?



It will be great if you can share some document / CLI config (or) test case 
which is similar to Origination & Termination topology.



Thanks

Govind



--

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

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

[vpp-dev] committers: stable/2005 branch is CLOSED

[Andrew Yourtchenko]

Dear VPP committers,

please do not merge any new patches onto stable/2005 until my notice
it's okay to do so.

--a
/* Your friendly 20.05 release manager */
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] ACL plugin optimization

[Govindarajan Mohandoss]

Hi Andrew,

  While profiling the ACL plugin node using perf tool in ARM Neoverse platform, 
Bihash related prefetches were shown as bottleneck.

Performance improvement is seen in ARM N1, TX2 and Intel Skylake servers after 
removing those prefetches. Testing is done with Ingress ACL/IPv4 forwarding in 
both SF and SL modes.

As the code change is common for Ingress/Egress ACL for both IPv4 and IPv6, 
performance improvement is expected for those cases also.

Following are the test results for Ingress ACL / IPv4 / 1 core / 64B @ MRR in 
ARM N1, TX2 and Intel Skylake servers:



Legend:

===

N1 - ARM Neoverse

TX2 - ARM Thunder X2

SKX - Intel Skylake

SL: % imp - Performance improvement in stateless mode

SF: % imp - Performance improvement in stateful mode






SKX
N1
TX2
Num Rules
Matching Rules
SL: Avg % imp
SF: Avg % imp
SL: % imp
SF: % imp
SL: % imp
SF: % imp
1
1
0.99
12.09
8.38
10.41
4.48
4.63
50
1 (50th)
0.79
9.63
8.76
10.06
5.32
4.63
100
1 (100th)
4.34
10.75
8.60
10.06
6.98
4.63
1000
1(1000th)
4.18
13.06
8.61
11.14
6.17
5.58
100
100
3.70
11.70
6.65
14
2.82
6.53
1000
1000
1.84
15.96
5.52
27.72
4.72
8.69





Please find the patch here: https://gerrit.fd.io/r/c/vpp/+/27167



I ran per patch regression on ARM Taishan server in CSIT lab. Following are the 
results for Stateless and Stateful modes:

1.  perftest-3n-tsh acl_statelessAND1cAND64b:

 https://jenkins.fd.io/job/vpp-csit-verify-perf-master-3n-tsh/23/consoleFull

 In the log, I can see the comparative numbers between parent and current 
(my patch) for 45 test cases.

 I searched for "Difference of averages relative to parent" in the log -  
41/45 test cases have shown around 4% improvement with the patch. Rest of the 4 
test cases stayed neutral.



2. perftest-3n-tsh acl_statefulAND1cAND64b:

https://jenkins.fd.io/job/vpp-csit-verify-perf-master-3n-tsh/25/

Performance improvement is seen in all 36 test cases.



Please provide your comments.



Thanks

Govind


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

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

[vpp-dev] VPP release 20.05 is complete!

[Andrew Yourtchenko]

Dear all,

I am happy to announce that the release 20.05 is available on
packagecloud.io in fdio/release repository.

I have verified that it is installable on Ubuntu 18.04 and Centos 7
distributions.

Special thanks to Vanessa Valderrama and Dave Wallace for the help
during the release.

--a (your friendly 20.05 release manager)

P.s. Branch stable/2005 is now open.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [EXTERNAL] [vpp-dev] VPP release 20.05 is complete!

[Chris Luke]

Brilliant, good job!

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Andrew Yourtchenko
Sent: Wednesday, May 27, 2020 17:28
To: vpp-dev 
Subject: [EXTERNAL] [vpp-dev] VPP release 20.05 is complete!

Dear all,

I am happy to announce that the release 20.05 is available on packagecloud.io 
in fdio/release repository.

I have verified that it is installable on Ubuntu 18.04 and Centos 7 
distributions.

Special thanks to Vanessa Valderrama and Dave Wallace for the help during the 
release.

--a (your friendly 20.05 release manager)

P.s. Branch stable/2005 is now open.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] VPP release 20.05 is complete!

[Jerome Tollet via lists.fd.io]

Congratulations!

Le 27/05/2020 23:28, « vpp-dev@lists.fd.io au nom de Andrew Yourtchenko » 
 a écrit :

Dear all,

I am happy to announce that the release 20.05 is available on
packagecloud.io in fdio/release repository.

I have verified that it is installable on Ubuntu 18.04 and Centos 7
distributions.

Special thanks to Vanessa Valderrama and Dave Wallace for the help
during the release.

--a (your friendly 20.05 release manager)

P.s. Branch stable/2005 is now open.

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

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

Re: [vpp-dev] ACL plugin optimization

[Andrew Yourtchenko]

Hi Govind,

1) According to Jenkins, this patch permits some of the packets that
should be denied, hence JJB voted "-1".

2) If you suspect merely the prefetches are the issue, just commenting
out the body of prefetch_session_entry() in the original code should
turn it into a no-op that doesn't break anything.

Hard to say anything else given the functionality is not correct.

In general - ensure you run "EXTENDED_TESTS=y TEST=acl* make test" as
a sanity check before extensive perf-tests. It's not a 100% guarantee
but it does catch a few naughty cases.

Also - take a look at f1cd92d8d9, which got about 30% improvement back
in the day, and is the source of much of the trickiness in that node.

--a


On 5/27/20, Govindarajan Mohandoss  wrote:
> Hi Andrew,
>
>   While profiling the ACL plugin node using perf tool in ARM Neoverse
> platform, Bihash related prefetches were shown as bottleneck.
>
> Performance improvement is seen in ARM N1, TX2 and Intel Skylake servers
> after removing those prefetches. Testing is done with Ingress ACL/IPv4
> forwarding in both SF and SL modes.
>
> As the code change is common for Ingress/Egress ACL for both IPv4 and IPv6,
> performance improvement is expected for those cases also.
>
> Following are the test results for Ingress ACL / IPv4 / 1 core / 64B @ MRR
> in ARM N1, TX2 and Intel Skylake servers:
>
>
>
> Legend:
>
> ===
>
> N1 - ARM Neoverse
>
> TX2 - ARM Thunder X2
>
> SKX - Intel Skylake
>
> SL: % imp - Performance improvement in stateless mode
>
> SF: % imp - Performance improvement in stateful mode
>
>
>
>
>
>
> SKX
> N1
> TX2
> Num Rules
> Matching Rules
> SL: Avg % imp
> SF: Avg % imp
> SL: % imp
> SF: % imp
> SL: % imp
> SF: % imp
> 1
> 1
> 0.99
> 12.09
> 8.38
> 10.41
> 4.48
> 4.63
> 50
> 1 (50th)
> 0.79
> 9.63
> 8.76
> 10.06
> 5.32
> 4.63
> 100
> 1 (100th)
> 4.34
> 10.75
> 8.60
> 10.06
> 6.98
> 4.63
> 1000
> 1(1000th)
> 4.18
> 13.06
> 8.61
> 11.14
> 6.17
> 5.58
> 100
> 100
> 3.70
> 11.70
> 6.65
> 14
> 2.82
> 6.53
> 1000
> 1000
> 1.84
> 15.96
> 5.52
> 27.72
> 4.72
> 8.69
>
>
>
>
>
> Please find the patch here: https://gerrit.fd.io/r/c/vpp/+/27167
>
>
>
> I ran per patch regression on ARM Taishan server in CSIT lab. Following are
> the results for Stateless and Stateful modes:
>
> 1.  perftest-3n-tsh acl_statelessAND1cAND64b:
>
>
> https://jenkins.fd.io/job/vpp-csit-verify-perf-master-3n-tsh/23/consoleFull
>
>  In the log, I can see the comparative numbers between parent and
> current (my patch) for 45 test cases.
>
>  I searched for "Difference of averages relative to parent" in the log -
>  41/45 test cases have shown around 4% improvement with the patch. Rest of
> the 4 test cases stayed neutral.
>
>
>
> 2. perftest-3n-tsh acl_statefulAND1cAND64b:
>
> https://jenkins.fd.io/job/vpp-csit-verify-perf-master-3n-tsh/25/
>
> Performance improvement is seen in all 36 test cases.
>
>
>
> Please provide your comments.
>
>
>
> Thanks
>
> Govind
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] VPP fails to start - error message EAL: FATAL: Cannot get hugepage information.

[Manoj Iyer]

Any more thoughts on this failure ?

Thanks
Manoj Iyer

From: vpp-dev@lists.fd.io  on behalf of Manoj Iyer via 
lists.fd.io 
Sent: Tuesday, May 26, 2020 6:51 PM
To: Damjan Marion 
Cc: bga...@cisco.com ; vpp-dev@lists.fd.io 
; Rodney Schmidt ; Kshitij Sudan 

Subject: Re: [vpp-dev] VPP fails to start - error message EAL: FATAL: Cannot 
get hugepage information.

$ lscpu
Architecture: aarch64
Byte Order:   Little Endian
CPU(s):   8
On-line CPU(s) list:  0
Off-line CPU(s) list: 1-7
Thread(s) per core:   1
Core(s) per socket:   1
Socket(s):1
NUMA node(s): 1
Vendor ID:ARM
Model:3
Model name:   Cortex-A72
Stepping: r0p3
BogoMIPS: 250.00
L1d cache:unknown size
L1i cache:unknown size
L2 cache: unknown size
NUMA node0 CPU(s):0
Flags:fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid

$ grep .  /sys/kernel/mm/hugepages/hugepages-*/*
/sys/kernel/mm/hugepages/hugepages-1048576kB/free_hugepages:0
/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages:0
/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages_mempolicy:0
/sys/kernel/mm/hugepages/hugepages-1048576kB/nr_overcommit_hugepages:0
/sys/kernel/mm/hugepages/hugepages-1048576kB/resv_hugepages:0
/sys/kernel/mm/hugepages/hugepages-1048576kB/surplus_hugepages:0
/sys/kernel/mm/hugepages/hugepages-2048kB/free_hugepages:1024
/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages:1024
/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages_mempolicy:1024
/sys/kernel/mm/hugepages/hugepages-2048kB/nr_overcommit_hugepages:0
/sys/kernel/mm/hugepages/hugepages-2048kB/resv_hugepages:0
/sys/kernel/mm/hugepages/hugepages-2048kB/surplus_hugepages:0
/sys/kernel/mm/hugepages/hugepages-32768kB/free_hugepages:0
/sys/kernel/mm/hugepages/hugepages-32768kB/nr_hugepages:0
/sys/kernel/mm/hugepages/hugepages-32768kB/nr_hugepages_mempolicy:0
/sys/kernel/mm/hugepages/hugepages-32768kB/nr_overcommit_hugepages:0
/sys/kernel/mm/hugepages/hugepages-32768kB/resv_hugepages:0
/sys/kernel/mm/hugepages/hugepages-32768kB/surplus_hugepages:0
/sys/kernel/mm/hugepages/hugepages-64kB/free_hugepages:0
/sys/kernel/mm/hugepages/hugepages-64kB/nr_hugepages:0
/sys/kernel/mm/hugepages/hugepages-64kB/nr_hugepages_mempolicy:0
/sys/kernel/mm/hugepages/hugepages-64kB/nr_overcommit_hugepages:0
/sys/kernel/mm/hugepages/hugepages-64kB/resv_hugepages:0
/sys/kernel/mm/hugepages/hugepages-64kB/surplus_hugepages:0


$ grep . /sys/devices/system/node/node*/hugepages/hugepages-*/*
/sys/devices/system/node/node0/hugepages/hugepages-1048576kB/free_hugepages:0
/sys/devices/system/node/node0/hugepages/hugepages-1048576kB/nr_hugepages:0
/sys/devices/system/node/node0/hugepages/hugepages-1048576kB/surplus_hugepages:
/sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages:1024
/sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages:1024
/sys/devices/system/node/node0/hugepages/hugepages-2048kB/surplus_hugepages:0
/sys/devices/system/node/node0/hugepages/hugepages-32768kB/free_hugepages:0
/sys/devices/system/node/node0/hugepages/hugepages-32768kB/nr_hugepages:0
/sys/devices/system/node/node0/hugepages/hugepages-32768kB/surplus_hugepages:0
/sys/devices/system/node/node0/hugepages/hugepages-64kB/free_hugepages:0
/sys/devices/system/node/node0/hugepages/hugepages-64kB/nr_hugepages:0
/sys/devices/system/node/node0/hugepages/hugepages-64kB/surplus_hugepages:0
ubuntu@sst100:~$

From: Damjan Marion 
Sent: Tuesday, May 26, 2020 6:01 PM
To: Manoj Iyer 
Cc: bga...@cisco.com ; vpp-dev@lists.fd.io 
; Rodney Schmidt ; Kshitij Sudan 

Subject: Re: [vpp-dev] VPP fails to start - error message EAL: FATAL: Cannot 
get hugepage information.

Can you capture:

lscpu

grep . /sys/kernel/mm/hugepages/hugepages-*/*

grep . /sys/devices/system/node/node*/hugepages/hugepages-*/*

—
Damjan

> On 27 May 2020, at 00:50, Manoj Iyer  wrote:
>
> But the issue is VPP's dpgk plugin fails and VPP service is not started as a 
> result.
> From: Damjan Marion 
> Sent: Tuesday, May 26, 2020 5:44 PM
> To: bga...@cisco.com 
> Cc: Manoj Iyer ; vpp-dev@lists.fd.io 
> ; Rodney Schmidt ; Kshitij Sudan 
> 
> Subject: Re: [vpp-dev] VPP fails to start - error message EAL: FATAL: Cannot 
> get hugepage information.
>
>
> VPP passes  --in-memory  so there should be no hugepage files created in the 
> fliesystem.
>
>
> > On 26 May 2020, at 18:42, Benoit Ganne (bganne) via lists.fd.io 
> >  wrote:
> >
> > Hi Manoj,
> >
> > The issue is because of DPDK initialization. In the working conf, you 
> > disable DPDK plugin so DPDK is not initialized and everything is fine.
> > Can you check whether /mnt/huge is full of dpdk-created staled files? I saw 
> > this happen from time to time. The fix is simple, just remove the staled 
> > files.
> >
> > Best
> > ben
> >
> >> -Original Message-
> >> From: vpp-dev@lists.fd.io  On 

Re: [vpp-dev] ACL plugin optimization

[Neale Ranns via lists.fd.io]

Hi Govind,

As well as removing the prefetches, you've also removed the per packet call to 
acl_fa_find_session_with_hash(). So IIUC you've removed the per-packet session 
lookup and instead re-use the lookup of packet 0 each time. that'll make things 
quicker but it's not functionally correct.

/neale

On 27/05/2020 23:51, "vpp-dev@lists.fd.io on behalf of Andrew Yourtchenko" 
 wrote:

Hi Govind,

1) According to Jenkins, this patch permits some of the packets that
should be denied, hence JJB voted "-1".

2) If you suspect merely the prefetches are the issue, just commenting
out the body of prefetch_session_entry() in the original code should
turn it into a no-op that doesn't break anything.

Hard to say anything else given the functionality is not correct.

In general - ensure you run "EXTENDED_TESTS=y TEST=acl* make test" as
a sanity check before extensive perf-tests. It's not a 100% guarantee
but it does catch a few naughty cases.

Also - take a look at f1cd92d8d9, which got about 30% improvement back
in the day, and is the source of much of the trickiness in that node.

--a


On 5/27/20, Govindarajan Mohandoss  wrote:
> Hi Andrew,
>
>   While profiling the ACL plugin node using perf tool in ARM Neoverse
> platform, Bihash related prefetches were shown as bottleneck.
>
> Performance improvement is seen in ARM N1, TX2 and Intel Skylake servers
> after removing those prefetches. Testing is done with Ingress ACL/IPv4
> forwarding in both SF and SL modes.
>
> As the code change is common for Ingress/Egress ACL for both IPv4 and 
IPv6,
> performance improvement is expected for those cases also.
>
> Following are the test results for Ingress ACL / IPv4 / 1 core / 64B @ MRR
> in ARM N1, TX2 and Intel Skylake servers:
>
>
>
> Legend:
>
> ===
>
> N1 - ARM Neoverse
>
> TX2 - ARM Thunder X2
>
> SKX - Intel Skylake
>
> SL: % imp - Performance improvement in stateless mode
>
> SF: % imp - Performance improvement in stateful mode
>
>
>
>
>
>
> SKX
> N1
> TX2
> Num Rules
> Matching Rules
> SL: Avg % imp
> SF: Avg % imp
> SL: % imp
> SF: % imp
> SL: % imp
> SF: % imp
> 1
> 1
> 0.99
> 12.09
> 8.38
> 10.41
> 4.48
> 4.63
> 50
> 1 (50th)
> 0.79
> 9.63
> 8.76
> 10.06
> 5.32
> 4.63
> 100
> 1 (100th)
> 4.34
> 10.75
> 8.60
> 10.06
> 6.98
> 4.63
> 1000
> 1(1000th)
> 4.18
> 13.06
> 8.61
> 11.14
> 6.17
> 5.58
> 100
> 100
> 3.70
> 11.70
> 6.65
> 14
> 2.82
> 6.53
> 1000
> 1000
> 1.84
> 15.96
> 5.52
> 27.72
> 4.72
> 8.69
>
>
>
>
>
> Please find the patch here: https://gerrit.fd.io/r/c/vpp/+/27167
>
>
>
> I ran per patch regression on ARM Taishan server in CSIT lab. Following 
are
> the results for Stateless and Stateful modes:
>
> 1.  perftest-3n-tsh acl_statelessAND1cAND64b:
>
>
> 
https://jenkins.fd.io/job/vpp-csit-verify-perf-master-3n-tsh/23/consoleFull
>
>  In the log, I can see the comparative numbers between parent and
> current (my patch) for 45 test cases.
>
>  I searched for "Difference of averages relative to parent" in the 
log -
>  41/45 test cases have shown around 4% improvement with the patch. Rest of
> the 4 test cases stayed neutral.
>
>
>
> 2. perftest-3n-tsh acl_statefulAND1cAND64b:
>
> https://jenkins.fd.io/job/vpp-csit-verify-perf-master-3n-tsh/25/
>
> Performance improvement is seen in all 36 test cases.
>
>
>
> Please provide your comments.
>
>
>
> Thanks
>
> Govind
>
>
>

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

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