Re: [vpp-dev] [csit-dev] VPP Release 18.07 is out!

[Ni, Hongjun]

Congratulations to the VPP community !!

From: csit-...@lists.fd.io [mailto:csit-...@lists.fd.io] On Behalf Of Edward 
Warnicke
Sent: Tuesday, July 31, 2018 10:57 AM
To: vpp-dev ; csit-...@lists.fd.io
Subject: [csit-dev] VPP Release 18.07 is out!

VPP Release 18.07 is out.  Packages are in the usual places.

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

View/Reply Online (#9979): https://lists.fd.io/g/vpp-dev/message/9979
Mute This Topic: https://lists.fd.io/mt/23901146/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 18.07 is out!

[Edward Warnicke]

VPP Release 18.07 is out.  Packages are in the usual places.

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

View/Reply Online (#9978): https://lists.fd.io/g/vpp-dev/message/9978
Mute This Topic: https://lists.fd.io/mt/23900471/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] Synchronous VPP-client over SHM

[Dave Barach via Lists.Fd.Io]

At least in C, it’s perfectly possible: use 
vl_client_connect_to_vlib_no_rx_pthread(...).

Follow the sketch in the default rx_thread_fn(..) pretty carefully. You’ll need 
to manually implement a non-while(1) version of vl_msg_api_queue_handler(...). 
Spin-waiting for replies will completely consume a CPU core. Such a spin-wait 
certainly requires a deadman timeout, and should do something to relinquish the 
cpu core.

Be aware that xxx_dump API messages result in multiple replies. The standard 
scheme for detecting the end of such a message set is to send an echo-request 
message immediately after xxx_dump. When the echo-reply arrives, the preceding 
message set is complete.

Personally, I wouldn’t go there. Vpp_api_test shows how to make the binary APIs 
appear to be synchronous.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Gudimetla, Leela 
Sankar
Sent: Monday, July 30, 2018 5:19 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Synchronous VPP-client over SHM

Hello,

We are writing a client for VPP to configure it over the shared-memory 
interface (similar to what VAT does).

I see that there is a rx_thread for processing responses from the server (VPP) 
to process the replies asynchronously.

Do we need to use the thread? Or Can we get rid of it and process the responses 
synchronously probably by introducing a wait if there is only one request at 
time from the client?

This way I can use the same request context to catch the “reply_t” structure.  
If it works, I can have request – response in a single call and return the 
response structure.

Please let me know if I can get rid of the rx_thread and handle this 
synchronously.

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

View/Reply Online (#9977): https://lists.fd.io/g/vpp-dev/message/9977
Mute This Topic: https://lists.fd.io/mt/23864436/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] Synchronous VPP-client over SHM

[Ole Troan]

Hi,

You can run synchronously, but then you need to find a way to deal with 
asynchronous events. Like the want_ apis. src/vpp-api/client has a knob to 
choose if you want the rx thread or not. 

Cheers 
Ole

> On 30 Jul 2018, at 23:19, Gudimetla, Leela Sankar  wrote:
> 
> Hello,
>  
> We are writing a client for VPP to configure it over the shared-memory 
> interface (similar to what VAT does).
>  
> I see that there is a rx_thread for processing responses from the server 
> (VPP) to process the replies asynchronously.
>  
> Do we need to use the thread? Or Can we get rid of it and process the 
> responses synchronously probably by introducing a wait if there is only one 
> request at time from the client?
>  
> This way I can use the same request context to catch the “reply_t” structure. 
>  If it works, I can have request – response in a single call and return the 
> response structure.
>  
> Please let me know if I can get rid of the rx_thread and handle this 
> synchronously.
>  
> Thanks,
> Leela sankar  
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#9975): https://lists.fd.io/g/vpp-dev/message/9975
> Mute This Topic: https://lists.fd.io/mt/23864436/675193
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [otr...@employees.org]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Synchronous VPP-client over SHM

[Gudimetla, Leela Sankar]

Hello,

We are writing a client for VPP to configure it over the shared-memory 
interface (similar to what VAT does).

I see that there is a rx_thread for processing responses from the server (VPP) 
to process the replies asynchronously.

Do we need to use the thread? Or Can we get rid of it and process the responses 
synchronously probably by introducing a wait if there is only one request at 
time from the client?

This way I can use the same request context to catch the “reply_t” structure.  
If it works, I can have request – response in a single call and return the 
response structure.

Please let me know if I can get rid of the rx_thread and handle this 
synchronously.

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

View/Reply Online (#9975): https://lists.fd.io/g/vpp-dev/message/9975
Mute This Topic: https://lists.fd.io/mt/23864436/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] Regarding VPP TCP Stack usage

[Florin Coras]

Prashant, 

Dave is exactly right. If you still want to try out the LDP layer, I wouldn’t 
set a global LD_PRELOAD variable because that will end up preloading all the 
applications and, inevitably, to some unsupported usage patterns and crashes. 
Instead, start only your app with LD_PRELOAD set, something like:

LD_PRELOAD=../vpp/build-root/install-vpp_debug-native/vpp/lib64/libvcl_ldpreload.so
 

Note that we’re exercising both the vcl and ldp layers with our test 
infrastructure. So, you may also want to take a look at test_vcl for more 
details on how we use the ldp layer. 

Hope this helps,
Florin


> On Jul 30, 2018, at 8:09 AM, Dave Wallace  wrote:
> 
> Prashant,
> 
> The VCL LD_PRELOAD library is experimental and only works with a very limited 
> set of legacy POSIX sockets applications (and only with single workers).
> 
> The conclusion based on the results of the initial experimentation with 
> LD_PRELOAD is that it is not a viable mechanism for accelerating legacy POSIX 
> sockets based applications using the VPP host stack.  The current 
> recommendation is to refactor legacy applications to use the VCL API directly.
> 
> You should also be aware that the VCL infrastructure is in the middle of 
> being refactored at this time and thus the VCL API may change.  I'll let 
> Florin, who is doing the refactoring, add his input on the VCL API roadmap.
> 
> Thanks,
> -daw-
> 
> On 7/30/2018 7:21 AM, Prashant Upadhyaya wrote:
>> Hi,
>> 
>> I have compiled VPP and it's running. I have an interface up and can
>> ping the IP applied there.
>> 
>> Now I am trying to bring up a legacy application TCP server (the one
>> which uses POSIX calls). So I set the LD_PRELOAD to point to
>> .../vpp/build-root/install-vpp_debug-native/vpp/lib64/libvcl_ldpreload.so
>> But the server application now crashes on startup.
>> Even the ldd command starts crashing.
>> 
>> Can somebody point me to the correct set of steps to be used for
>> LD_PRELOAD to bring up my legacy tcp server which will then engage the
>> VPP TCP stack instead of the kernel's
>> 
>> Regards
>> -Prashant
>> 
>> 
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#9971): https://lists.fd.io/g/vpp-dev/message/9971 
>> 
>> Mute This Topic: https://lists.fd.io/mt/23858819/675079 
>> 
>> Group Owner: vpp-dev+ow...@lists.fd.io 
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>>   [dwallac...@gmail.com 
>> ]
>> -=-=-=-=-=-=-=-=-=-=-=-
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#9973): https://lists.fd.io/g/vpp-dev/message/9973
> Mute This Topic: https://lists.fd.io/mt/23858819/675152
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#9974): https://lists.fd.io/g/vpp-dev/message/9974
Mute This Topic: https://lists.fd.io/mt/23858819/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] Regarding VPP TCP Stack usage

[Dave Wallace]

Prashant,

The VCL LD_PRELOAD library is experimental and only works with a very 
limited set of legacy POSIX sockets applications (and only with single 
workers).


The conclusion based on the results of the initial experimentation with 
LD_PRELOAD is that it is not a viable mechanism for accelerating legacy 
POSIX sockets based applications using the VPP host stack.  The current 
recommendation is to refactor legacy applications to use the VCL API 
directly.


You should also be aware that the VCL infrastructure is in the middle of 
being refactored at this time and thus the VCL API may change.  I'll let 
Florin, who is doing the refactoring, add his input on the VCL API roadmap.


Thanks,
-daw-

On 7/30/2018 7:21 AM, Prashant Upadhyaya wrote:

Hi,

I have compiled VPP and it's running. I have an interface up and can
ping the IP applied there.

Now I am trying to bring up a legacy application TCP server (the one
which uses POSIX calls). So I set the LD_PRELOAD to point to
.../vpp/build-root/install-vpp_debug-native/vpp/lib64/libvcl_ldpreload.so
But the server application now crashes on startup.
Even the ldd command starts crashing.

Can somebody point me to the correct set of steps to be used for
LD_PRELOAD to bring up my legacy tcp server which will then engage the
VPP TCP stack instead of the kernel's

Regards
-Prashant


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

View/Reply Online (#9971): https://lists.fd.io/g/vpp-dev/message/9971
Mute This Topic: https://lists.fd.io/mt/23858819/675079
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dwallac...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-


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

View/Reply Online (#9973): https://lists.fd.io/g/vpp-dev/message/9973
Mute This Topic: https://lists.fd.io/mt/23858819/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] CSIT - sw_interface_set_flags admin-up link-up failing

[Dave Barach via Lists.Fd.Io]

Before doing anything else: please revert to the previous DPDK version and see 
if the issue vanishes.

From: vpp-dev@lists.fd.io  On Behalf Of Peter Mikus via 
Lists.Fd.Io
Sent: Monday, July 30, 2018 3:02 AM
To: vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] CSIT - sw_interface_set_flags admin-up link-up failing

Hello vpp-dev,

I am looking for consultation. We started to test VPP for report on all LF CSIT 
testbeds Skylakes and Haswells.
We are observing weird behavior. In each test we are using sequence to first 
bring the both interfaces (physical up) by VAT:

  sw_interface_set_flags sw_if_index  admin-up (I also tried 
sw_interface_set_flags sw_if_index idx admin-up link-up)

After setting all interfaces UP we are testing if interfaces are really UP by 
VAT (loop 30times, 1s between API call check): "sw_interface_dump".
It wasn't an issue in past but recently we start seeing that sw_interface_dump 
is reporting interfaces as link_down (admin-up).

Notes/symptoms:
-   Our sw_interface_dump check is running 30x (1s interval) in loop.
-   Link-down is random, sometimes both interfaces are link-up sometimes just 
one and sometimes both link are down.
-   It is not TB related, nor cabling related, we see it on Haswells-3node in 
like 1 out of 70 tests, Skylakes-2node 1 out of 70, but on Skylake-3node more 
than half of the tests.
-   Checking state during test reveals that interfaces are link-down (show int) 
so "sw_interface_dump" is reporting state correctly.
-   Doing CLI during test "set interface state ... up" does bring interfaces UP 
-> (but it is hard to check the timing here).
-   Affected are mostly x520 and x710, but that is most probably because of 
statistics (low coverage of other NICs like xxv710 and xl710).
-   We have seen this in master vpp as well as rc2 vpp.
-   It is not clear when this starts to happen, so bisecting would take lot of 
time.
-   This was spotted on VIRL as well also on Memif interface which bring us to 
suspicious that this is related to API not HW.

Do you have an idea what we could check further? VPP is not crashing so no core 
dump are available. This issue is not 100% replicable which makes it hard to 
debug.

Is there a way to get more verbose error from the api call mentioned to reveal 
more information?

Thank you.

Peter Mikus
Engineer - Software
Cisco Systems Limited
[http://www.cisco.com/web/europe/images/email/signature/logo05.jpg]
Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

View/Reply Online (#9972): https://lists.fd.io/g/vpp-dev/message/9972
Mute This Topic: https://lists.fd.io/mt/23857615/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 VPP TCP Stack usage

[Prashant Upadhyaya]

Hi,

I have compiled VPP and it's running. I have an interface up and can
ping the IP applied there.

Now I am trying to bring up a legacy application TCP server (the one
which uses POSIX calls). So I set the LD_PRELOAD to point to
.../vpp/build-root/install-vpp_debug-native/vpp/lib64/libvcl_ldpreload.so
But the server application now crashes on startup.
Even the ldd command starts crashing.

Can somebody point me to the correct set of steps to be used for
LD_PRELOAD to bring up my legacy tcp server which will then engage the
VPP TCP stack instead of the kernel's

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

View/Reply Online (#9971): https://lists.fd.io/g/vpp-dev/message/9971
Mute This Topic: https://lists.fd.io/mt/23858819/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] L3VPN in VPP

[Neale Ranns via Lists.Fd.Io]

Hi,

Answers inline marked [nr]

/neale

From:  on behalf of Gulakh 
Date: Saturday, 28 July 2018 at 13:45
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] L3VPN in VPP

Hi,
I have setup a VPLS scenario successfully and now I want to setup a L3VPN 
scenario in VPP (L3VPN topology is in attachment).

My configuration for VPLS is some how like this 
link.

As far as I searched Internet, L3VPN has a VPN Label that I think is somehow 
like PW Label in VPLS with difference that VPN Label is used to select VRF and 
PW Label is used to select mpls tunnel (hence bridge).

[nr] other label allocation schemes are available ☺

===
Part1:
I guess I should configure the source PE as follow:

 In VPLS: mpls tunnel add l2-only via  out-labels 
   ip route add  via  out-labels 


 In L3VPN: CMD1 ??? (insert in customer VRF)
 ip route add  via  out-labels 
 (insert in GLOBAL VRF)

I don't know what command I should use for CMD1 ... This command must add 
VPN-LABEL which is selected base on the customer's VRF to the packet and then 
lookup the GLOBAL VRF to push the MPLS Label. just like VPLS that the mpls 
tunnel first adds a PW Label and then in the destination IP resolution, MPLS 
Label is added to packet.

Question1: Am I right about the configurations in the source PE?


[nr] ip route table   via  out-labels 


you could use PREFIX=0.0.0.0/0 or many more specifics

and your route to the PE-TARGET would be better as a non-recursive route (i.e. 
if it is learned via e.g. OSPF and this is not an inter-AS option C) otherwise 
you’ll need another labelled route for the next-hop

non-recursive means specify the next-hop and interface.



Part2:
I guess I should configure the target PE as follow:

 In VPLS: mpls local-label add eos  via l2-input-on 

 In L3VPN: mpls local-label add eos  via ip4-lookup-in-table 
  (insert in GLOBAL VRF)

Question2: Am I right about the configurations in the target PE?

[nr] Yes. The mpls label is added to the MPLS global table, i.e. there’s no 
‘insert in global-VRF’, since the instruction associated with the label is to 
lookup the exposed IP destination address in the customer’s VRF/

=
Part3:
In order to fill customer's VRF, I should use control plane's RouteTarget (RT) 
to select the VRF ID and then use below command to fill the VRF:

  ip route add  via   table 

Question3: Am I right?

[nr] yes.

thanks in advance


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

View/Reply Online (#9970): https://lists.fd.io/g/vpp-dev/message/9970
Mute This Topic: https://lists.fd.io/mt/23840657/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] Manual patch verify request: gerrit 13769

[Zhiyong Yang]

Hi Damjan, guys,

Agree with Damjan,
We can use new vectorized checksum calculation instead of VPP existing 
implementation also.
For my local GRE tunnel testing case, the code can improve 10% or so throughput 
on haswell as well.
Another patch is submitted as Damjan suggested.
using ip_csum in ip4_header_checksum
https://gerrit.fd.io/r/13803

Thanks
Zhiyong

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Damjan 
Marion via Lists.Fd.Io
Sent: Saturday, July 28, 2018 7:39 PM
To: Dave Barach 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Manual patch verify request: gerrit 13769


Is incremental checksum really needed here,
or we can just move to new vectorized checksum calculation (already used in 
ip-input)?

--
Damjan


On 27 Jul 2018, at 22:17, Dave Barach via Lists.Fd.Io 
mailto:dbarach=cisco@lists.fd.io>> wrote:

Thanks very much... Dave

From: Tina Tsou mailto:tina.t...@arm.com>>
Sent: Friday, July 27, 2018 1:51 PM
To: Dave Barach (dbarach) mailto:dbar...@cisco.com>>
Cc: Brian Brooks mailto:brian.bro...@arm.com>>; 
vpp-dev@lists.fd.io
Subject: Re: Manual patch verify request: gerrit 13769

Dear Dave,

Looking into it...

Thank you,
Tina

On Jul 27, 2018, at 7:23 AM, Dave Barach (dbarach) 
mailto:dbar...@cisco.com>> wrote:
Folks,

Would it be possible for someone to download and manually verify that 
https://gerrit.fd.io/r/#/c/13769 is functionally correct, and that the proposed 
change isn’t a performance disaster on aarch64?

Thanks... Dave

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 (#9956): https://lists.fd.io/g/vpp-dev/message/9956
Mute This Topic: https://lists.fd.io/mt/23832194/675642
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[dmar...@me.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

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

Re: [csit-dev] [vpp-dev] Parallel test execution in VPP Test Framework

[Juraj Linkeš]

Hi,

A couple of corrections/additions:

Python spawns processes with proper CFS scheduling (I've tested this), so it's 
VPP that's overriding CFS scheduling.

Damjan, assigning cpus to VPPs is not the problem. The problem is when multiple 
make test frameworks in different Jenkins slaves try to do the same thing - 
e.g. when a framework assigns any n cores to different VPP instances, the other 
framework instances running in other Jenkins slaves don't know which cores are 
currently assigned to how many VPPs. I guess I could parse this from all 
running VPP pids, then looking at their affinity and assign cores based on 
that, but I wanted to know about other approaches. I'll look into this in the 
meantime.

VPP Test Framework doesn't load the dpdk plugin, does it make sense to use CFS 
scheduler by default when it isn't loaded? Or maybe just use the CFS scheduler 
by default when dpdk plugin is not loaded and no workers are used?

Are there plans for running multiple workers in make test? I don't see that in 
the framework at the moment, but maybe I'm missing something.

Thanks,
Juraj

From: Damjan Marion [mailto:dmar...@me.com]
Sent: Saturday, July 28, 2018 1:28 PM
To: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
Cc: Maciek Konstantynowicz ; Alec Hothan (ahothan) 
; Juraj Linkeš ; 
vpp-dev@lists.fd.io
Subject: Re: [csit-dev] [vpp-dev] Parallel test execution in VPP Test Framework


Dear All,

My personal preference is that make test  framework implements cpu assignment 
code.
It should't be rocket science to parse /sys/devices/system/cpu/online and give 
one cpu to each instance.
It will also help to test framework to understand how many parallel jobs it can 
run...

Enforcing single cpu assignment in vpp is done intentionally, to avoid cross 
numa memory allocation.
If main-core is not specified, vpp simply uses cpu core 1 (unless only 0 
exists).
While adding something like "cpu { main-core any} " should be quite straight 
forward, it will have broken
behaviour when dpdk is loaded and it will just confuse people. Also, we will 
need to come back to the
drawing board when we decide to run multiple workers in make test, as logic 
there is more complex and will likely require
rework of the thread placement code.

--
Damjan


On 27 Jul 2018, at 20:46, Peter Mikus via Lists.Fd.Io 
mailto:pmikus=cisco@lists.fd.io>> wrote:

Hello,

>  What is the “significant problem” you’re running into?

The problem can be better described as: When python is spawning N instances of 
VPP process, all processes are from unknown reason placed with affinity 0x2 
(bin 10). This can be verified by taskset –p . CFS is then placing all 
VPP process to the same core, making it inefficient on multicore jenkins slave 
container.
The default vpp startup.conf is not modified thus there is no input to know 
where to pin the vpp threads. Simply one can said or think that this is related 
to python multiprocess/subprocess.popen code, which is hard-setting affinity 
mask to 0x2.

There are multiple solutions for workaround that Juraj proposed or Maciek, but 
none of them is answering why is this happening.

Peter Mikus
Engineer – Software
Cisco Systems Limited

From: csit-...@lists.fd.io 
[mailto:csit-...@lists.fd.io] On Behalf Of Maciek Konstantynowicz (mkonstan) 
via Lists.Fd.Io
Sent: Friday, July 27, 2018 6:53 PM
To: Alec Hothan (ahothan) mailto:ahot...@cisco.com>>; Juraj 
Linkeš mailto:juraj.lin...@pantheon.tech>>
Cc: csit-...@lists.fd.io
Subject: Re: [csit-dev] [vpp-dev] Parallel test execution in VPP Test Framework

Alec, This is about make test and not real packet forwarding. Per Juraj’s patch 
[1]

Juraj, My understanding is that if you’re starting VPP without specifying core 
placement in startup.conf [2] cpu {..}, then Linux CFS will be placing the 
threads onto available cpu core resources. If you’re saying this is not the 
case, and indeed the wiki comment indicates this, then the way to address it is 
to specify different core for main.c thread per vpp instance.

What is the “significant problem” you’re running into? Are tests not executing 
in parallel using python multiprocessing, are vpp’s having issues, else? Could 
you describe it a bit more?

-Maciek

[1] https://gerrit.fd.io/r/#/c/13491/
[2] https://git.fd.io/vpp/tree/src/vpp/conf/startup.conf



On 27 Jul 2018, at 17:23, Alec Hothan (ahothan) 
mailto:ahot...@cisco.com>> wrote:

Hi Juraj,
How many instances and what level of performance are you looking at?
Even if you assign different cores to each VPP instance, results can be skewed 
due to interference at the LLC and PCIe/NIC level (this can be somewhat 
mitigated by running on separate sockets)

   Alec


From: mailto:vpp-dev@lists.fd.io>> on behalf of Juraj 
Linkeš mailto:juraj.lin...@pantheon.tech>>
Date: Friday, July 27, 2018 at 7:25 AM
To: "Maciek Konstantynowicz (mkonstan)" 
mailto:mkons...@cisco.com>>
Cc: 

[vpp-dev] CSIT - sw_interface_set_flags admin-up link-up failing

[Peter Mikus via Lists.Fd.Io]

Hello vpp-dev,

I am looking for consultation. We started to test VPP for report on all LF CSIT 
testbeds Skylakes and Haswells.
We are observing weird behavior. In each test we are using sequence to first 
bring the both interfaces (physical up) by VAT:

  sw_interface_set_flags sw_if_index  admin-up (I also tried 
sw_interface_set_flags sw_if_index idx admin-up link-up)

After setting all interfaces UP we are testing if interfaces are really UP by 
VAT (loop 30times, 1s between API call check): "sw_interface_dump".
It wasn't an issue in past but recently we start seeing that sw_interface_dump 
is reporting interfaces as link_down (admin-up).

Notes/symptoms:
-   Our sw_interface_dump check is running 30x (1s interval) in loop.
-   Link-down is random, sometimes both interfaces are link-up sometimes just 
one and sometimes both link are down.
-   It is not TB related, nor cabling related, we see it on Haswells-3node in 
like 1 out of 70 tests, Skylakes-2node 1 out of 70, but on Skylake-3node more 
than half of the tests.
-   Checking state during test reveals that interfaces are link-down (show int) 
so "sw_interface_dump" is reporting state correctly.
-   Doing CLI during test "set interface state ... up" does bring interfaces UP 
-> (but it is hard to check the timing here).
-   Affected are mostly x520 and x710, but that is most probably because of 
statistics (low coverage of other NICs like xxv710 and xl710).
-   We have seen this in master vpp as well as rc2 vpp.
-   It is not clear when this starts to happen, so bisecting would take lot of 
time.
-   This was spotted on VIRL as well also on Memif interface which bring us to 
suspicious that this is related to API not HW.

Do you have an idea what we could check further? VPP is not crashing so no core 
dump are available. This issue is not 100% replicable which makes it hard to 
debug.

Is there a way to get more verbose error from the api call mentioned to reveal 
more information?

Thank you.

Peter Mikus
Engineer - Software
Cisco Systems Limited
[http://www.cisco.com/web/europe/images/email/signature/logo05.jpg]
Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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

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