[vpp-dev] tx-errors on VPP controlled dpdk device

[chakravarthy . arisetty]

Hi,

When VPP is sending out the traffic through DPDK device, it encounters transmit 
errors? Can someone shed some light what might be happening?

Thanks
Chakri

vpp# show int
              Name               Idx       State          Counter          Count
VirtualFunctionEthernet0/6/0      1         up       rx packets              
21141847
                                                     rx bytes             
33657724324
                                                     tx packets                 
   62
                                                     tx bytes                   
 2604
                                                     ip4                     
21141785
VirtualFunctionEthernet0/7/0      2         up       rx packets                 
   62
                                                     rx bytes                   
 2604
                                                     tx packets              
21141847
                                                     tx bytes             
33657724324
*                                                     tx-error                 
3675066*
local0                            0         up
loop1                             3         up
loop2                             5         up
memif1/1                          7         up       tx packets              
21141785
                                                     tx bytes             
32600632470
memif2/2                          8         up       rx packets              
21141785
                                                     rx bytes             
32600632470
vxlan_tunnel1                     4         up       rx packets              
21141785
                                                     rx bytes             
32600632470
vxlan_tunnel2                     6         up       tx packets              
21141785
                                                     tx bytes             
33361736730
vpp# sh error
   Count                    Node                  Reason
  10570865              vxlan4-input              good packets decapsulated
  21141785              vxlan4-encap              good packets encapsulated
  31712650                l2-output               L2 output packets
  31712650                l2-learn                L2 learn packets
  31712650                l2-input                L2 input packets
       126                arp-input               ARP replies sent
*   3675066     VirtualFunctionEthernet0/7/0-tx    Tx packet drops (dpdk tx 
failure)*
  10570920              vxlan4-input              good packets decapsulated
  10570920                l2-output               L2 output packets
  10570920                l2-learn                L2 learn packets
  10570920                l2-input                L2 input packets

Thread 0 vpp_main (lcore 1)
Time 957448.6, average vectors/node 1.00, last 128 main loops 0.00 per node 0.00
  vector rates in 0.e0, out 2.0889e-6, drop 0.e0, punt 0.e0
             Name                 State         Calls          Vectors        
Suspends         Clocks       Vectors/Call
VirtualFunctionEthernet0/6/0-o   active                  1               1      
         0          9.65e3            1.00
VirtualFunctionEthernet0/6/0-t   active                  1               1      
         0          2.03e4            1.00
VirtualFunctionEthernet0/7/0-o   active                  1               1      
         0          6.08e3            1.00
VirtualFunctionEthernet0/7/0-t   active                  1               1      
         0          1.11e4            1.00
acl-plugin-fa-cleaner-process  event wait                0               0      
         1          2.51e4            0.00
admin-up-down-process          event wait                0               0      
         1          1.12e3            0.00
api-rx-from-ring                any wait                 0               0      
     68101          1.24e4            0.00
avf-process                    event wait                0               0      
         1          6.97e3            0.00
bfd-process                    event wait                0               0      
         1          1.64e4            0.00
cdp-process                     any wait                 0               0      
    127877          2.62e3            0.00
dhcp-client-process             any wait                 0               0      
      9575          3.55e3            0.00
dns-resolver-process            any wait                 0               0      
       958          4.02e3            0.00
dpdk-ipsec-process                done                   1               0      
         0          1.29e5            0.00
dpdk-process                    any wait                 0               0      
    319126          5.14e4            0.00
fib-walk                        any wait                 0               0      
    478648          1.65e3            0.00

Re: [**EXTERNAL**] Re: [vpp-dev] Synchronous VPP-client over SHM

[Ole Troan]

Leela,

> =Thanks Ole for pointing at the asynchronous events. If they work like 
> interrupts, then there should not be any problem with synchronous client.
> Please let me know your thoughts.

There is a single message queue that you need to service. So a blocking request 
must handle messages for events. You need to deal with the dump/details calls, 
and you must drain the queue fast enough so that VPP doesn’t block. E.g. if you 
enabled want_interface_events, but you only drained the queue during a blocking 
call, the queue could fill in the mean time and VPP would block.

You might want to take a look at VAPI if you want to do this in C.
As in building a synchronous API on top of an asynchronous one, and use 
callbacks as event handlers.

I don’t think I would recommend reimplementing this part of the client library 
yourself. Use one of the existing language bindings instead.

Cheers,
Ole


>  
> Thanks,
> Leela sankar
>  
> From:  on behalf of Ole Troan 
> Date: Monday, July 30, 2018 at 3:24 PM
> To: Leela Gudimetla 
> Cc: "vpp-dev@lists.fd.io" 
> Subject: [**EXTERNAL**] Re: [vpp-dev] Synchronous VPP-client over SHM
>  
> 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 (#9990): https://lists.fd.io/g/vpp-dev/message/9990
> Mute This Topic: https://lists.fd.io/mt/23923763/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 (#9997): https://lists.fd.io/g/vpp-dev/message/9997
Mute This Topic: https://lists.fd.io/mt/23923763/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-dev] VPP Release 18.07 is out!

[Dave Wallace]

Most Excellent!

Congratulations to the entire VPP and CSIT community.

Thanks,
-daw-

On 7/30/18 10:57 PM, Edward Warnicke wrote:

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 (#2961): https://lists.fd.io/g/csit-dev/message/2961
Mute This Topic: https://lists.fd.io/mt/23900472/675079
Group Owner: csit-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/csit-dev/unsub  [dwallac...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-


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

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

Florin is correct. There is also a performance and/or scaling penalty 
due to the need to handle both kernel socket based file descriptors and 
VCL/VPP created file descriptors with the LD_PRELOAD callback functions.


Thanks,
-daw-

On 7/31/18 2:11 PM, Florin Coras wrote:

Hi Matt,

I’d say that trying to cover all possible combinations of POSIX calls 
is the main issue. Also, statically linked applications won’t work 
fine with ld_preload. But, I’ll let Dave provide more details since he 
is more closely involved with the effort.


Florin


On Jul 31, 2018, at 7:01 AM, Matthew Smith > wrote:



Hi Florin and Dave,

I’m curious what problems were observed with the LD_PRELOAD 
mechanism. Were there performance issues? Or was it too difficult to 
try and cover different usage of POSIX calls? Or something else?


Thanks!
-Matt


On Jul 30, 2018, at 10:39 AM, Florin Coras > wrote:


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/675725
Group Owner: vpp-dev+ow...@lists.fd.io 

Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
 [mgsm...@netgate.com ]

-=-=-=-=-=-=-=-=-=-=-=-






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

View/Reply Online (#9995): https://lists.fd.io/g/vpp-dev/message/9995
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-dev] VPP Release 18.07 is out!

[George Zhao]

Bravo!!!


From: csit-...@lists.fd.io [mailto:csit-...@lists.fd.io] On Behalf Of Edward 
Warnicke
Sent: Monday, July 30, 2018 7:57 PM
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 (#9994): https://lists.fd.io/g/vpp-dev/message/9994
Mute This Topic: https://lists.fd.io/mt/23924679/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] [**EXTERNAL**] RE: Synchronous VPP-client over SHM

[Ole Troan]

Hi Leela,

I presume you want to do this in C?
If so it might be worth looking at VAPI too as a higher level interface. 

Cheers 
Ole

> On 31 Jul 2018, at 19:54, Gudimetla, Leela Sankar  wrote:
> 
> Thanks Dave for the details. Since the client is a single-threaded, I would 
> want to take a synchronous approach.
>  
> To be specific, I would want the response to be returned from the request 
> call. So that the typical C construct create_subif(param1, param2, … *ret1) 
> would do the job and return the reply_t which has sw_ifindex in ret1.
>  
> If there is a way to return the response from reply_t_handlers to the request 
> call without using the global structures like vat_main, I also would not want 
> go for synchronous approach.
>  
> Thanks,
> Leela sankar
>  
> From: "Dave Barach (dbarach)" 
> Date: Monday, July 30, 2018 at 3:34 PM
> To: Leela Gudimetla , "vpp-dev@lists.fd.io" 
> 
> Subject: [**EXTERNAL**] RE: Synchronous VPP-client over SHM
>  
> 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 (#9989): https://lists.fd.io/g/vpp-dev/message/9989
> Mute This Topic: https://lists.fd.io/mt/23923692/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 (#9993): https://lists.fd.io/g/vpp-dev/message/9993
Mute This Topic: https://lists.fd.io/mt/23923692/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] [FD.io Helpdesk #56625] Nexus fd.io.master.centos7 VPP artifacts

[Vanessa Valderrama via RT]

Peter,

We need to make a decision on the number of artifacts to keep. I'd like to 
propose the following

previous release repos - 10 packages per subproject
master - 10 to 15 packages per subproject

Thank you,
Vanessa

On Tue Jun 05 00:51:02 2018, pmi...@cisco.com wrote:
> Hello Vanessa,
> 
> Thank you for an explanation. Indeed this will impact certain things
> that are planned like "automatic bisecting" (downloading and testing
> range of artifacts). Let me analyze current situation with CSIT team
> and get back to you.
> 
> Peter Mikus
> Engineer – Software
> Cisco Systems Limited
> 
> 
> -Original Message-
>  From: Vanessa Valderrama via RT [mailto:fdio-
> helpd...@rt.linuxfoundation.org]
> Sent: Monday, June 04, 2018 9:47 PM
> To: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco)
> 
> Cc: csit-...@lists.fd.io; infra-steer...@lists.fd.io; vpp-
> d...@lists.fd.io
> Subject: [FD.io Helpdesk #56625] Nexus fd.io.master.centos7 VPP
> artifacts
> 
> Peter,
> 
> The fd.io.master.centos7 repo had to be cleaned up significantly to
> eliminate Jenkins build timeout errors.  This was discussed in the
> TSC. Going forward we'll only be keeping an average of 10 of the
> current release candidate artifacts in the repository.  Please let me
> know if this retention policy causes an issue for you.
> 
> We do need to clean up the other repositories as well.  Please let me
> know if you'd like to discuss retention policies.  I'll hold off on
> cleaning up other repositories for now.
> 
> Thank you,
> Vanessa
> 
> On Wed May 30 10:20:21 2018, pmi...@cisco.com wrote:
> > Hello,
> >
> > I have recently spotted that CentOS repo got reduced and old binaries
> > are missing [1].
> >
> > Is this expected?
> > Will the similar be done for Ubuntu repos?
> >
> > Was this announced somewhere?
> >
> > Thank you.
> >
> > [1]
> > https://nexus.fd.io/content/repositories/fd.io.master.centos7/io/fd/vp
> > p/vpp/
> >
> > 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 (#9992): https://lists.fd.io/g/vpp-dev/message/9992
Mute This Topic: https://lists.fd.io/mt/21275985/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]

Hi Matt, 

I’d say that trying to cover all possible combinations of POSIX calls is the 
main issue. Also, statically linked applications won’t work fine with 
ld_preload. But, I’ll let Dave provide more details since he is more closely 
involved with the effort. 

Florin


> On Jul 31, 2018, at 7:01 AM, Matthew Smith  wrote:
> 
> 
> Hi Florin and Dave,
> 
> I’m curious what problems were observed with the LD_PRELOAD mechanism. Were 
> there performance issues? Or was it too difficult to try and cover different 
> usage of POSIX calls? Or something else?
> 
> Thanks!
> -Matt
> 
> 
>> On Jul 30, 2018, at 10:39 AM, Florin Coras > > wrote:
>> 
>> 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/675725 
>> 
>> Group Owner: vpp-dev+ow...@lists.fd.io 
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>>   [mgsm...@netgate.com 
>> ]
>> -=-=-=-=-=-=-=-=-=-=-=-
> 

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

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

Re: [**EXTERNAL**] Re: [vpp-dev] Synchronous VPP-client over SHM

[Gudimetla, Leela Sankar]

Thanks Ole for pointing at the asynchronous events. If they work like 
interrupts, then there should not be any problem with synchronous client.
Please let me know your thoughts.

Thanks,
Leela sankar

From:  on behalf of Ole Troan 
Date: Monday, July 30, 2018 at 3:24 PM
To: Leela Gudimetla 
Cc: "vpp-dev@lists.fd.io" 
Subject: [**EXTERNAL**] Re: [vpp-dev] Synchronous VPP-client over SHM

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 
mailto:lgudi...@ciena.com>> 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 (#9990): https://lists.fd.io/g/vpp-dev/message/9990
Mute This Topic: https://lists.fd.io/mt/23923763/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] [**EXTERNAL**] RE: Synchronous VPP-client over SHM

[Gudimetla, Leela Sankar]

Thanks Dave for the details. Since the client is a single-threaded, I would 
want to take a synchronous approach.

To be specific, I would want the response to be returned from the request call. 
So that the typical C construct create_subif(param1, param2, … *ret1) would do 
the job and return the reply_t which has sw_ifindex in ret1.

If there is a way to return the response from reply_t_handlers to the request 
call without using the global structures like vat_main, I also would not want 
go for synchronous approach.

Thanks,
Leela sankar

From: "Dave Barach (dbarach)" 
Date: Monday, July 30, 2018 at 3:34 PM
To: Leela Gudimetla , "vpp-dev@lists.fd.io" 

Subject: [**EXTERNAL**] RE: Synchronous VPP-client over SHM

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 (#9989): https://lists.fd.io/g/vpp-dev/message/9989
Mute This Topic: https://lists.fd.io/mt/23923692/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

[Maciek Konstantynowicz (mkonstan) via Lists.Fd.Io]

+1

-Maciek

On 28 Jul 2018, at 13:28, Damjan Marion mailto:dmar...@me.com>> 
wrote:


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@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>, csit-dev 
mailto:csit-...@lists.fd.io>>
Subject: Re: [vpp-dev] Parallel test execution in VPP Test Framework

Hi Maciek and vpp-devs,

I've run into a significant problem regarding VPP assignment to cores. All VPPs 
that are spawned are assigned to core 1. I looked at 
https://wiki.fd.io/view/VPP/Command-line_Arguments and I guess it's because 
that's the default behavior of VPP (dpdk coremask is not configured and  Note 
that the "main" thread always occupies the lowest core-id specified in the DPDK 
[process-level] coremask.").

Is my reading of the config options accurate?

Obviously, all VPP instances running on the same core goes against running the 
tests on multiple cores. There are a couple of solutions that come to mind:
• Assign VPP instances to cores manually. With possible multiple jobs 
running on a given host, this creates a situation where the different jobs 
don't know cores are already occupied (and by how many VPP instances) and thus 
introduces additional challenges to solve.
• Add an option to override this default behavior and let the Linux CFS 
scheduler assign VPPs to cores or something similar where VPPs would land on 
different cores.

Is there some other solution?

Vpp-devs, what do you think about the second solution? What 

Re: [vpp-dev] Regarding VPP TCP Stack usage

[Matthew Smith]

Hi Florin and Dave,

I’m curious what problems were observed with the LD_PRELOAD mechanism. Were 
there performance issues? Or was it too difficult to try and cover different 
usage of POSIX calls? Or something else?

Thanks!
-Matt


> On Jul 30, 2018, at 10:39 AM, Florin Coras  wrote:
> 
> 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/675725
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [mgsm...@netgate.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#9987): https://lists.fd.io/g/vpp-dev/message/9987
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: [SUSPICIOUS] [vpp-dev] L3VPN in VPP

[Neale Ranns via Lists.Fd.Io]

Hi,

Please show me:
  sh ip fib index 1 5.5.5.5/32
and
  sh ip fib index 0 192.168.23.3/32

I suspect you are missing an out-label on the latter.

/neale

From:  on behalf of Gulakh 
Date: Tuesday, 31 July 2018 at 14:53
To: "vpp-dev@lists.fd.io" 
Subject: [SUSPICIOUS] [vpp-dev] L3VPN in VPP

It seems that the Next hop IP resolution does not work correctly:
Here is my Configuration:

# set interface state GigabitEthernet4/0/0 up
# set interface state GigabitEthernet4/0/1 up

# ip table add 1   (create Customer VRF)

# set interface ip table GigabitEthernet 4/0/0 1  (Customer VRF)

# set interface ip address GigabitEthernet4/0/0 
192.168.12.2/24
  (Toward Customer)
# set interface ip address GigabitEthernet4/0/1 
192.168.23.2/24
  (Toward Core)

*** Now I want to add one of Customer's route into its VRF:
# ip route add 
5.5.5.5/32
 table 1 via 192.168.23.3 next-hop-table 0 out-labels 40

in which : 
5.5.5.5/32
 is the Customer's another site in somewhere else
   table 1 is the customer's VRF
   192.168.23.3 is the next hop which is in the core -> be resolved 
by Global VRF
   next-hop-table 0 is the Global VRF to resolve 192.168.23.3
   out-labels 40 is the VPN Label


Now When I see the VRF 1 ("show ip fib table 1"), here is the output for 
5.5.5.5/32

ipv4-VRF:1, fib_index:1, flow hash:[src dst sport dport proto ] 
locks:[src:CLI:2, ]
..
...

192.168.12.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:14 buckets:1 uRPF:13 to:[0:0]]
[0] [@4]: ipv4-glean: GigabitEthernet4/0/0: mtu:9000 
a0369f23aa780806
5.5.5.5/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:24 buckets:1 uRPF:25 to:[0:0]]
[0] [@0]: dpo-drop ip4


Here is the VRF 0:

ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:plugin-hi:2, src:default-route:1, ]
..
...

[vpp-dev] L3VPN in VPP

[Gulakh]

It seems that the Next hop IP resolution does not work correctly:
Here is my Configuration:

# *set interface state GigabitEthernet4/0/0 up*
# *set interface state GigabitEthernet4/0/1 up*

#* ip table add 1   *(create Customer VRF)

# *set interface ip table GigabitEthernet 4/0/0 1*  (Customer VRF)

# *set interface ip address GigabitEthernet4/0/0 192.168.12.2/24
*  (Toward Customer)
# *set interface ip address GigabitEthernet4/0/1 192.168.23.2/24
*  (Toward Core)

*** Now I want to add one of Customer's route into its VRF:
# *ip route add 5.5.5.5/32  table 1 via 192.168.23.3
next-hop-table 0 out-labels 40*

in which :* 5.5.5.5/32 * is the Customer's another site
in somewhere else
  * table 1* is the customer's VRF
   *192.168.23.3* is the next hop which is in the core -> be
resolved by Global VRF
   *next-hop-table 0* is the Global VRF to resolve 192.168.23.3
   *out-labels 40 *is the VPN Label


Now When I see the VRF 1 ("*show ip fib table 1*"), here is the output for
5.5.5.5/32

ipv4-VRF:1, fib_index:1, flow hash:[src dst sport dport proto ]
locks:[src:CLI:2, ]
..
...

192.168.12.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:14 buckets:1 uRPF:13 to:[0:0]]
[0] [@4]: ipv4-glean: GigabitEthernet4/0/0: mtu:9000
a0369f23aa780806





*5.5.5.5/32   unicast-ip4-chain  [@0]: dpo-load-balance:
[proto:ip4 index:24 buckets:1 uRPF:25 to:[0:0]][0] [@0]: dpo-drop ip4*


Here is the VRF 0:

ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ]
locks:[src:plugin-hi:2, src:default-route:1, ]
..
...

192.168.23.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:18 buckets:1 uRPF:19 to:[0:0]]
[0] [@4]: ipv4-glean: GigabitEthernet4/0/1: mtu:9000
a0369f23aa7a0806


Question: why does it say Drop?? I expect to see something that shows
next-hop is resolved in VRF 0.

On Tue, Jul 31, 2018 at 4:18 PM, Neale Ranns (nranns) 
wrote:

>
>
> Hi,
>
>
>
> You are correct on all points.
>
>
>
> regards
>
> /neale
>
>
>
> *From: *Holoo Gulakh 
> *Date: *Tuesday, 31 July 2018 at 12:19
> *To: *"Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" <
> vpp-dev@lists.fd.io>
> *Subject: *Re: [vpp-dev] L3VPN in VPP
>
>
>
> Hi,
>
> In order to have both VPLS and L3VPN works *concurrently * in a PE
> router, I guess that I should do the following things:
>
>
>
> 1- Regardless of the type of service that whether it's *VPLS *,*L3VPN *or
> *none*(e.g. a simple connectivity) , the core of the network works the
> same, that is I should Insert everything about the core of the network in
> the Global VRF i.e. *IP FIB 0* and *MPLS FIB 0 in VPP*.
>
>
>
> The above step is done before even providing any services.
>
>
>
> 2- *For the PW-Label of VPLS*, the task is delivered to the mpls tunnel
> to put the PW-Label on the Packet (i.e. *mpls tunnel add l2-only
>  out-labels*) then to resolve the PE-TARGET IP
> address the resolution is done by checking the Global VRF which contains
> information about the core and at that stage the MPLS label is added to
> packet.
>
>
>
>*For the VPN-Label of the L3VPN* the task of putting it on the packet
> is delivered to the VRF associated with the incoming Interface (i.e. *#* *ip
> route add   table  via  out-labels
> *) and then to resolve the NEXT-HOP IP address, Global VRF
> must be checked since the routing information about the core is stored in
> the Global VRF (i.e. IP FIB 0 and MPLS FIB 0 in VPP)
>
> but the problem is that the route store in the customer's VRF must use
> Global VRF in order to resolve its NEXT-HOP.
>
> Searching VPP Doc, I confronted with a parameter that I can use to select
> which VRF to use to resolve the next hop.
>
> so the *#* command must be modified by (*ip route add  table
>  via   next-hop-table  out-labels
> *) and then during the resolution of the PE-TARGET IP address
> the MPLS Labels is added to the packet.
>
>
>
> *Question*: Am I right??
>
>
>
> Excuse me for my questions ... most of the materials found in Internet are
> about Cisco commands to run the service and they give my little insights on
> what to do with lower level configurations.
>
> Thanks in advance
>
>
>
> On Mon, Jul 30, 2018 at 1:31 PM, Neale Ranns (nranns) 
> wrote:
>
> 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
> 

Re: [vpp-dev] L3VPN in VPP

[Neale Ranns via Lists.Fd.Io]

Hi,

You are correct on all points.

regards
/neale

From: Holoo Gulakh 
Date: Tuesday, 31 July 2018 at 12:19
To: "Neale Ranns (nranns)" , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] L3VPN in VPP

Hi,
In order to have both VPLS and L3VPN works concurrently in a PE router, I guess 
that I should do the following things:

1- Regardless of the type of service that whether it's VPLS ,L3VPN or none(e.g. 
a simple connectivity) , the core of the network works the same, that is I 
should Insert everything about the core of the network in the Global VRF i.e. 
IP FIB 0 and MPLS FIB 0 in VPP.

The above step is done before even providing any services.

2- For the PW-Label of VPLS, the task is delivered to the mpls tunnel to put 
the PW-Label on the Packet (i.e. mpls tunnel add l2-only  
out-labels) then to resolve the PE-TARGET IP address the resolution 
is done by checking the Global VRF which contains information about the core 
and at that stage the MPLS label is added to packet.

   For the VPN-Label of the L3VPN the task of putting it on the packet is 
delivered to the VRF associated with the incoming Interface (i.e. # ip route 
add   table  via  out-labels ) 
and then to resolve the NEXT-HOP IP address, Global VRF must be checked since 
the routing information about the core is stored in the Global VRF (i.e. IP FIB 
0 and MPLS FIB 0 in VPP)
but the problem is that the route store in the customer's VRF must use Global 
VRF in order to resolve its NEXT-HOP.
Searching VPP Doc, I confronted with a parameter that I can use to select which 
VRF to use to resolve the next hop.
so the # command must be modified by (ip route add  table 
 via   next-hop-table  out-labels 
) and then during the resolution of the PE-TARGET IP address the 
MPLS Labels is added to the packet.

Question: Am I right??

Excuse me for my questions ... most of the materials found in Internet are 
about Cisco commands to run the service and they give my little insights on 
what to do with lower level configurations.
Thanks in advance

On Mon, Jul 30, 2018 at 1:31 PM, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:
Hi,

Answers inline marked [nr]

/neale

From: mailto:vpp-dev@lists.fd.io>> on behalf of Gulakh 
mailto:holoogul...@gmail.com>>
Date: Saturday, 28 July 2018 at 13:45
To: "vpp-dev@lists.fd.io" 
mailto: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.

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

[Peter Mikus via Lists.Fd.Io]

Hello,

Thanks to Vratko (cc), he tested latest master with DPDK 18.02.2 [0]. The issue 
is there as well.

I cannot confirm if "no JSON data.VAT" is related. The bad thing is that there 
is no meaningful return message with more verbose output.

(we do see this on pretty much on all NIC cards in LF and all TBs)

[0] 
https://jenkins.fd.io/sandbox/job/vpp-csit-verify-hw-perf-master-2n-skx/6/consoleFull

Peter Mikus
Engineer - Software
Cisco Systems Limited

-Original Message-
From: Ray Kinsella [mailto:m...@ashroe.eu] 
Sent: Tuesday, July 31, 2018 12:06 PM
To: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
; vpp-dev@lists.fd.io; yulong@intel.com
Subject: Re: [vpp-dev] CSIT - sw_interface_set_flags admin-up link-up failing

Hi Peter,

It may be unrelated, but I think we see this issue also pretty regularly with 
FD.io VPP 18.04 and the x520, on our local test rig.

The error we typically see is "VAT command sw_interface_set_flags sw_if_index 1 
admin-up: no JSON data.VAT".

Do think it is the same or a separate issue?

Ray K


On 30/07/2018 08:02, Peter Mikus via Lists.Fd.Io wrote:
> 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/675355
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [m...@ashroe.eu]
> -=-=-=-=-=-=-=-=-=-=-=-
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9983): https://lists.fd.io/g/vpp-dev/message/9983
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] L3VPN in VPP

[Gulakh]

Hi,
In order to have both VPLS and L3VPN works *concurrently *in a PE router, I
guess that I should do the following things:

1- Regardless of the type of service that whether it's *VPLS *,*L3VPN *or
*none*(e.g. a simple connectivity) , the core of the network works the
same, that is I should Insert everything about the core of the network in
the Global VRF i.e. *IP FIB 0* and *MPLS FIB 0 in VPP*.

The above step is done before even providing any services.

2- *For the PW-Label of VPLS*, the task is delivered to the mpls tunnel to
put the PW-Label on the Packet (i.e. *mpls tunnel add l2-only 
out-labels*) then to resolve the PE-TARGET IP address the
resolution is done by checking the Global VRF which contains information
about the core and at that stage the MPLS label is added to packet.

   *For the VPN-Label of the L3VPN* the task of putting it on the packet is
delivered to the VRF associated with the incoming Interface (i.e.* #* *ip
route add   table  via  out-labels
*) and then to resolve the NEXT-HOP IP address, Global VRF must
be checked since the routing information about the core is stored in the
Global VRF (i.e. IP FIB 0 and MPLS FIB 0 in VPP)
but the problem is that the route store in the customer's VRF must use
Global VRF in order to resolve its NEXT-HOP.
Searching VPP Doc, I confronted with a parameter that I can use to select
which VRF to use to resolve the next hop.
so the *#* command must be modified by (*ip route add  table
 via   next-hop-table  out-labels
*) and then during the resolution of the PE-TARGET IP address
the MPLS Labels is added to the packet.

*Question*: Am I right??

Excuse me for my questions ... most of the materials found in Internet are
about Cisco commands to run the service and they give my little insights on
what to do with lower level configurations.
Thanks in advance

On Mon, Jul 30, 2018 at 1:31 PM, Neale Ranns (nranns) 
wrote:

> 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 J
>
>
>
> ===
>
> *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 (#9982): 

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

[Ray Kinsella]

Hi Peter,

It may be unrelated, but I think we see this issue also pretty regularly 
with FD.io VPP 18.04 and the x520, on our local test rig.


The error we typically see is "VAT command sw_interface_set_flags 
sw_if_index 1 admin-up: no JSON data.VAT".


Do think it is the same or a separate issue?

Ray K


On 30/07/2018 08:02, Peter Mikus via Lists.Fd.Io wrote:

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/675355
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [m...@ashroe.eu]
-=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#9981): https://lists.fd.io/g/vpp-dev/message/9981
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]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Ray Kinsella]

W00t!

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

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 mailto:vpp-dev@lists.fd.io>>; 
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 (#9980): https://lists.fd.io/g/vpp-dev/message/9980
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]
-=-=-=-=-=-=-=-=-=-=-=-