Re: [vpp-dev] Can "use mq eventfd" solve epoll wait h igh cpu usage problem?

[wanghanlin]

Hi stephenIt's great. Is there any performance data comparing with the kernel path now?
Regards,Hanlin




发自网易邮箱大师


On 11/2/2019 06:42，Stephen Belair (sbelair) via Lists.Fd.Io wrote： 




Hanlin,
 
I’ve been working on Envoy/Vcl integration for a while now and Ping Yu has joined me in this effort. Vcl works fine with a large, multi-threaded application like Envoy, although the integration has had its challenges. We are getting very
 close to trying to upstream the code.
 
-stephen
 

From: Florin Coras 
Date: Thursday, October 31, 2019 at 10:26 PM
To: wanghanlin , "Stephen Belair (sbelair)" , "Yu, Ping" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Can "use mq eventfd" solve epoll wait h igh cpu usage problem?


 

Hi Hanlin,  

 


Stephen and Ping have made a lot of progress with Envoy and VCL, but I’ll let them comment on that. 


 


Regards, 


Florin






On Oct 31, 2019, at 9:44 PM, wanghanlin  wrote:

 




OK，I got it. Thanks a lot.


By the way, can VCL adapt to envoy or any progress about this？


 


Regards,


Hanlin












wanghanlin










wanghan...@corp.netease.com








签名由 网易邮箱大师 定制





On 11/1/2019 12:07，Florin
 Coras wrote： 



Hi Hanlin, 


 


If a worker’s mq uses eventfds for notifications, we could nest it in libc_epfd, i.e.,the epoll fd we create for the linux fds. So, if an app's worker calls epoll_wait,
 in ldp we can epoll_wait on libc_epfd and if we get an event on the mq’s eventfd, we can call vls_epoll_wait with a 0 timeout to drain the events from vcl. 


 


Having said that, keep in mind that we typically recommend that people use vcl because ldp, through vls, enforces a rather strict locking policy. That is needed in
 order to avoid invalidating vcl’s assumption that sessions are owned by only one vcl worker. Moreover, we’ve tested ldp only against a limited set of applications. 


 


Regards, 


Florin








On Oct 31, 2019, at 7:58 PM, wanghanlin  wrote:

 




Do you mean, if just use eventfds only, then I needn't set timeout  to 0 in ldp_epoll_pwait?


If so, then how to process unhandled_evts_vector in vppcom_epoll_wait timely? What I'm saying is,  another thread add event to unhandled_evts_vector during epoll_wait,
 or unhandled_evts_vector not process completely because of reaching maxevents.


 


Regards,


Hanlin


 












wanghanlin










wanghan...@corp.netease.com








签名由 网易邮箱大师 定制





On 10/31/2019 23:34，Florin
 Coras wrote： 



Hi, 


 


use_mq_eventfd will help with vcl but as you’ve noticed it won’t help for ldp because there we need to poll both vcl and linux fds. Because mutex-condvar notifications
 can’t be epolled we have to constantly switch between linux and vcl epolled fds. One option going forward would be to change ldp to detect if vcl is using mutex-condvars or eventfds and in case of the latter poll linux fds and the mq’s eventfd in a linux epoll. 


 


Regards,


Florin






On Oct 31, 2019, at 5:54 AM, wanghanlin  wrote:

 




hi ALL，


I found app using VCL "epoll_wait" still occupy 70% cpu with "use_mq_eventfd" configuration even if very little traffic.


Then I investigate code in ldp_epoll_pwait, vls_epoll_wait is called with timeout equal to 0.


Then I have two questions:


1. What problems can "use_mq_eventfd" solve?


2.Any other way to decrease cpu usage?


Thanks!


 


code in  ldp_epoll_pwait:



do


    {


      if (!ldpw->epoll_wait_vcl)


{


  rv = vls_epoll_wait (ep_vlsh, events, maxevents,
 0);


  if (rv > 0)


    {


      ldpw->epoll_wait_vcl = 1;


      goto done;


    }


  else if (rv < 0)


    {


      errno = -rv;


      rv = -1;


      goto done;


    }


}


      else


ldpw->epoll_wait_vcl = 0;


 


      if (libc_epfd > 0)


{


  rv = libc_epoll_pwait (libc_epfd, events,
 maxevents, 0, sigmask);


  if (rv != 0)


    goto done;


}


    }


  while ((timeout == -1) || (clib_time_now (&ldpw->clib_time) < max_time));













wanghanlin










wanghan...@corp.netease.com








签名由 网易邮箱大师 定制




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

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

Re: [vpp-dev] nat44 bug - created nat sessions aren't automatically cleaned up

[Filip Varga -X (fivarga - PANTHEON TECH SRO at Cisco) via Lists.Fd.Io]

Hi,

We have registred this issue int NAT plugin and i am already working on solving 
the issue. If you need to post any additional content please do so on jira 
issue VPP-1795 (https://jira.fd.io/browse/VPP-1795). You can monitor progress 
through the jira ticket.

Thank you.

Best regards,
Filip Varga


[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/logo/Cisco_Logo_no_TM_Cisco_Blue-RGB_43px.png]




Filip Varga
Engineer - Software
fiva...@cisco.com
Tel:










Cisco Systems, Inc.



Slovakia
cisco.com



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

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.
Please click 
here
 for Company Registration Information.







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

View/Reply Online (#14471): https://lists.fd.io/g/vpp-dev/message/14471
Mute This Topic: https://lists.fd.io/mt/3887/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] Can "use mq eventfd" solve epoll wait h igh cpu usage problem?

[Stephen Belair (sbelair) via Lists.Fd.Io]

Hanlin,

I’ve been working on Envoy/Vcl integration for a while now and Ping Yu has 
joined me in this effort. Vcl works fine with a large, multi-threaded 
application like Envoy, although the integration has had its challenges. We are 
getting very close to trying to upstream the code.

-stephen

From: Florin Coras 
Date: Thursday, October 31, 2019 at 10:26 PM
To: wanghanlin , "Stephen Belair (sbelair)" 
, "Yu, Ping" 
Cc: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] Can "use mq eventfd" solve epoll wait h igh cpu usage 
problem?

Hi Hanlin,

Stephen and Ping have made a lot of progress with Envoy and VCL, but I’ll let 
them comment on that.

Regards,
Florin


On Oct 31, 2019, at 9:44 PM, wanghanlin 
mailto:wanghan...@corp.netease.com>> wrote:

OK，I got it. Thanks a lot.
By the way, can VCL adapt to envoy or any progress about this？

Regards,
Hanlin
[Image removed by sender.]
wanghanlin
[Image removed by sender.]
wanghan...@corp.netease.com
签名由 网易邮箱大师 定制
On 11/1/2019 12:07，Florin 
Coras wrote：
Hi Hanlin,

If a worker’s mq uses eventfds for notifications, we could nest it in 
libc_epfd, i.e.,the epoll fd we create for the linux fds. So, if an app's 
worker calls epoll_wait, in ldp we can epoll_wait on libc_epfd and if we get an 
event on the mq’s eventfd, we can call vls_epoll_wait with a 0 timeout to drain 
the events from vcl.

Having said that, keep in mind that we typically recommend that people use vcl 
because ldp, through vls, enforces a rather strict locking policy. That is 
needed in order to avoid invalidating vcl’s assumption that sessions are owned 
by only one vcl worker. Moreover, we’ve tested ldp only against a limited set 
of applications.

Regards,
Florin


On Oct 31, 2019, at 7:58 PM, wanghanlin 
mailto:wanghan...@corp.netease.com>> wrote:

Do you mean, if just use eventfds only, then I needn't set timeout  to 0 in 
ldp_epoll_pwait?
If so, then how to process unhandled_evts_vector in vppcom_epoll_wait timely? 
What I'm saying is,  another thread add event to unhandled_evts_vector during 
epoll_wait, or unhandled_evts_vector not process completely because of reaching 
maxevents.

Regards,
Hanlin

[Image removed by sender.]
wanghanlin
[Image removed by sender.]
wanghan...@corp.netease.com
签名由 网易邮箱大师 定制
On 10/31/2019 23:34，Florin 
Coras wrote：
Hi,

use_mq_eventfd will help with vcl but as you’ve noticed it won’t help for ldp 
because there we need to poll both vcl and linux fds. Because mutex-condvar 
notifications can’t be epolled we have to constantly switch between linux and 
vcl epolled fds. One option going forward would be to change ldp to detect if 
vcl is using mutex-condvars or eventfds and in case of the latter poll linux 
fds and the mq’s eventfd in a linux epoll.

Regards,
Florin


On Oct 31, 2019, at 5:54 AM, wanghanlin 
mailto:wanghan...@corp.netease.com>> wrote:

hi ALL，
I found app using VCL "epoll_wait" still occupy 70% cpu with "use_mq_eventfd" 
configuration even if very little traffic.
Then I investigate code in ldp_epoll_pwait, vls_epoll_wait is called with 
timeout equal to 0.
Then I have two questions:
1. What problems can "use_mq_eventfd" solve?
2.Any other way to decrease cpu usage?
Thanks!

code in  ldp_epoll_pwait:
do
{
  if (!ldpw->epoll_wait_vcl)
{
  rv = vls_epoll_wait (ep_vlsh, events, maxevents, 0);
  if (rv > 0)
{
  ldpw->epoll_wait_vcl = 1;
  goto done;
}
  else if (rv < 0)
{
  errno = -rv;
  rv = -1;
  goto done;
}
}
  else
ldpw->epoll_wait_vcl = 0;

  if (libc_epfd > 0)
{
  rv = libc_epoll_pwait (libc_epfd, events, maxevents, 0, sigmask);
  if (rv != 0)
goto done;
}
}
  while ((timeout == -1) || (clib_time_now (&ldpw->clib_time) < max_time));
[Image removed by sender.]
wanghanlin
[Image removed by sender.]
wanghan...@corp.netease.com
签名由 网易邮箱大师 定制
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14413): https://lists.fd.io/g/vpp-dev/message/14413
Mute This Topic: https://lists.fd.io/mt/40123765/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 (#14448): https://lists.fd.io/g/vpp-dev/message/14448
Mute This Topic: https://lists.fd.io/mt/40351193/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 (#14472): https://lists.fd.io/g/vpp-dev/

Re: [vpp-dev] vlib_node_add_next_with_slot bug?

[Dave Barach via Lists.Fd.Io]

Shows you how often people have actually hacked graph arcs.

One way to handle it would be to add an explicit vlib_node_delete_next (vm, 
node_index, next_node_index) to clean out the hash table entry / set the arc 
next node index to ~0 or some such.

If that sounds OK, I can build it or you can build it.

Thoughts?

Thanks... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Christian Hopps
Sent: Friday, November 1, 2019 3:53 PM
To: vpp-dev 
Cc: Christian Hopps 
Subject: [vpp-dev] vlib_node_add_next_with_slot bug?

In my code based on the user changing the ipsec backend I need to update the 
node in my "encrypt" slots (for v4 and v6). I am calling 
vlib_node_add_next_with_slot to do this; however, the function isn't doing what 
I want.

Basically vlib_node_add_next_with_slot does the following:

  if ((p = hash_get (node->next_slot_by_node, next_node_index)))
{
  /* Next already exists: slot must match. */
  if (slot != ~0)
ASSERT (slot == p[0]);

  vlib_worker_thread_barrier_release (vm);
  return p[0];
}

Prior to making the change. It does not remove any old node from 
next_slot_by_node after it makes a change though. The result is that if you try 
and add back a node that was previously added (and removed) to that slot the 
function does nothing b/c it has this dangling reference in the hash table.

Now this could have been by design, but I suspect not as it really doesn't 
serve any purpose, that I can see, to leave an old node "back" reference there 
when it's no longer true.

If people agree I can submit a patch to remove the old hash table entry when 
the slot is changed.

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

View/Reply Online (#14466): https://lists.fd.io/g/vpp-dev/message/14466
Mute This Topic: https://lists.fd.io/mt/40479963/675269
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dbar...@cisco.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14470): https://lists.fd.io/g/vpp-dev/message/14470
Mute This Topic: https://lists.fd.io/mt/40479963/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] Basic l2 bridging does not work

[Chuan Han via Lists.Fd.Io]

Just for record purposes, we did not continue trying this R740-R230 setup.
We moved to R740-R740 setup. We did not see this phy nic down issue. It
seems some compatibility bug within R230 + some nic.

On Sun, Oct 20, 2019 at 9:37 PM Balaji Venkatraman via Lists.Fd.Io  wrote:

> I see in the log of “ethtool enp6s0f1“ on R230:
>
>
>
> root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1
>
>
>
> Supported ports: [ *FIBRE* ]   
>
> Supported link modes:   1baseT/Full
>
> Supports auto-negotiation: No
>
> Advertised link modes:  1baseT/Full <
>
> Speed: 1Mb/s
>
> Port: Direct Attach Copper
>
> *Auto-negotiation: off*
>
>
>
>
>
> While on R 230:
>
> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3
> Settings for eno3:
> Supported ports: [ *TP* ]. <
>
>
> *Supported link modes:   100baseT/Full
>   1000baseT/Full  1baseT/Full *<
> Supported pause frame use: Symmetric
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes:  100baseT/Full
> 1000baseT/Full
> 1baseT/Full
> Advertised pause frame use: Symmetric
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Speed: 1Mb/s
> Duplex: Full
> *Port: Twisted Pair*
> PHYAD: 0
> Transceiver: internal
> *Auto-negotiation: on*
> MDI-X: Unknown
>
>
>
>
>
> The supported ports seem mismatched at either end with AutoNeg disabled at
> one, I doubt the parameters are exchanged to get the transmissions going.
> Some expert in the ethernet might want to comment if this could be an issue.
>
> Regards,
>
> Balaji.
>
>
>
>
>
> *From: * on behalf of "steven luong via Lists.Fd.Io"
> 
> *Reply-To: *"Steven Luong (sluong)" 
> *Date: *Friday, October 18, 2019 at 10:06 PM
> *To: *"vpp-dev@lists.fd.io" 
> *Cc: *"vpp-dev@lists.fd.io" 
> *Subject: *Re: [vpp-dev] Basic l2 bridging does not work
>
>
>
> Can you reduce your rx and tx queues to 1 and try again?
>
>
>
> rx: queues 2 (max 128), desc 512 (min 32 max 4096 align 8)
> tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8)
>
>
> Steven
>
>
>
> *From: * on behalf of "Chuan Han via Lists.Fd.Io"
> 
> *Reply-To: *"chuan...@google.com" 
> *Date: *Friday, October 18, 2019 at 4:05 PM
> *To: *Chuan Han 
> *Cc: *"vpp-dev@lists.fd.io" 
> *Subject: *Re: [vpp-dev] Basic l2 bridging does not work
>
>
>
> Hi, Damjan,
>
>
>
> It seems the bug is in vpp.
>
>
>
> On R230, vpp shows eth0 is down.
>
>
>
> vpp# sh hardware-interfaces eth0
>   NameIdx   Link  Hardware
> eth0   2down  eth0
>   Link speed: unknown
>
>
> *  Ethernet address b4:96:91:23:1e:d6   Intel 82599 carrier down*
> flags: admin-up promisc pmd rx-ip4-cksum
> rx: queues 2 (max 128), desc 512 (min 32 max 4096 align 8)
> tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8)
> pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0
> max rx packet len: 15872
> promiscuous: unicast on all-multicast on
> vlan offload: strip off filter off qinq off
> rx offload avail:  vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro
>macsec-strip vlan-filter vlan-extend jumbo-frame
> scatter
>security keep-crc
> rx offload active: ipv4-cksum
> tx offload avail:  vlan-insert ipv4-cksum udp-cksum tcp-cksum
> sctp-cksum
>tcp-tso macsec-insert multi-segs security
> tx offload active: none
> rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex
> ipv6-tcp
>ipv6-udp ipv6-ex ipv6
> rss active:none
> tx burst function: (nil)
> rx burst function: ixgbe_recv_pkts_vec
>
> extended stats:
>   mac local errors   318
> vpp#
>
>
>
> However, the testpmd tool shows it is up.
>
>
>
> testpmd> show port summary 1
> Number of available ports: 2
> Port MAC Address   Name Driver Status   Link
> *1B4:96:91:23:1E:D6 :06:00.1 net_ixgbe  up   1Mbps*
> testpmd>
>
>
>
> Does this prove something wrong on vpp side?
>
>
>
> Thanks.
>
> Chuan
>
>
>
> On Fri, Oct 18, 2019 at 3:06 PM Chuan Han  wrote:
>
> I built testpmd binary on both r740 and r230, and ran the test. I did see
> testpmd reports some link status change on r230 server. testpmd report on
> r740 is stabler. no status change reported.
>
>
>
> r230 log
>
> 
>
> Press enter to exit
>
> Port 0: link state change event
>
> Port 1: link state change event
>
> Port 1: link state change event
>
> r740 log
>
> 
>
> Press enter to exitx0 - TX RS bit threshold=32
>
> If it is a dpdk bug, what shall I do? Report to dpdk mailing list?
>
>

Re: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08

[Chuan Han via Lists.Fd.Io]

Just for record purposes, here are the configs I figured out on l2 gretap +
ipsec transport mode. The other party config is similar with proper changes
in ip, mac address and spi. Make sure spi matches. Otherwise, pkt will be
punted on the receiving side.

set int state eth0 up
set int ip address eth0 10.10.10.11/24
set int promiscuous on eth0

set ip arp eth0 10.10.10.10 24:6e:96:b4:b2:07

set int state eth1 up
set int promiscuous on eth1

create gre tunnel src 10.10.10.11 dst 10.10.10.10 teb
set int state gre0 up

create bridge-domain 1
set interface l2 bridge gre0 1
set interface l2 bridge eth1 1

ipsec spd add 1
set interface ipsec spd eth0 1

ipsec sa add 1 spi 255128 esp crypto-key
0123456789012345678901234567890101234567890123456789012345678901 crypto-alg
aes-gcm-256
ipsec sa add 2 spi 255129 esp crypto-key
0123456789012345678901234567890101234567890123456789012345678901 crypto-alg
aes-gcm-256

ipsec policy add spd 1 priority 90 inbound action protect sa 2
local-ip-range 10.10.10.11-10.10.10.11 remote-ip-range
10.10.10.10-10.10.10.10
ipsec policy add spd 1 priority 90 outbound action protect sa 1
local-ip-range 10.10.10.11-10.10.10.11 remote-ip-range
10.10.10.10-10.10.10.10

trace add dpdk-input 10

On Tue, Oct 8, 2019 at 3:23 PM Chuan Han via Lists.Fd.Io  wrote:

> Hi, Neale/vpp experts,
>
> Can you help check why the receiving side drops all the incoming pkts
> because of unknown ip protocol?
>
> I looked at TestIpsecGreTebIfEsp, but had no clue how it is mapped to cli
> commands.
>
> I am new to vpp.
>
> Thanks.
> Chuan
>
> On Fri, Oct 4, 2019 at 11:41 AM Chuan Han via Lists.Fd.Io  google@lists.fd.io> wrote:
>
>> Thanks for helping.
>>
>> I removed spd configs on both sides, but still no luck. I am pinging from
>> r230 side.
>>
>> It seems r230 is able to sending ping pkts over dpdk interface. However,
>> on r740 side, gre0 interface drops all of them. See the attached updated
>> cfg files and log files for more details.
>>
>>   IPSec: remote:10.10.10.11 spi:255129 (0x0003e499) seq 418
>> 00:06:52:367944: esp4-decrypt-tun
>>   esp: crypto aes-cbc-128 integrity sha1-96 pkt-seq 418 sa-seq 0
>> sa-seq-hi 0
>> 00:06:52:367948: ip4-input-no-checksum
>>   GRE: 10.10.10.11 -> 10.10.10.10
>> tos 0x00, ttl 254, length 66, checksum 0x9464
>> fragment id 0x
>>   GRE teb
>> 00:06:52:367948: ip4-not-enabled
>> GRE: 10.10.10.11 -> 10.10.10.10
>>   tos 0x00, ttl 254, length 66, checksum 0x9464
>>   fragment id 0x
>> GRE teb
>> 00:06:52:367948: error-drop
>>   rx:gre0
>> 00:06:52:367949: drop
>>   ip4-input: unknown ip protocol
>>
>>
>> On Fri, Oct 4, 2019 at 8:39 AM Neale Ranns (nranns) 
>> wrote:
>>
>>>
>>>
>>> Hi Chuan,
>>>
>>>
>>>
>>> Please remove the SPD config. For tunnels all packets that
>>> ingress/egress the tunnel are decrypted/encrypted, so no policy is
>>> required. The presence of the SPD on the ingress eth0 link could be why
>>> it’s not working.
>>>
>>> Please provide packet traces when you are reporting packet loss
>>> problems, it helps us debug.
>>>
>>>
>>>
>>> For reference the setup for GRE TEB IPSec can be found in the python UT
>>> TestIpsecGreTebIfEsp.
>>>
>>>
>>>
>>> Regards,
>>>
>>> neale
>>>
>>>
>>>
>>>
>>>
>>> *From: * on behalf of "Chuan Han via Lists.Fd.Io"
>>> 
>>> *Reply to: *"chuan...@google.com" 
>>> *Date: *Friday 4 October 2019 at 02:15
>>> *To: *"John Lo (loj)" 
>>> *Cc: *"vpp-dev@lists.fd.io" 
>>> *Subject: *Re: [vpp-dev] How to configure l2 gre over ipsec in vpp 19.08
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> Thanks for information.
>>>
>>>
>>>
>>> I am trying to configure l2 gre over ipsec transport mode.
>>>
>>>
>>>
>>> Here are my startup.cfg files. Can you help check if my configuration is
>>> correct or not?
>>>
>>>
>>>
>>> r230 and r740 are two servers which are directly connected.
>>>
>>>
>>>
>>> eth0 is the phy nic. host-veth1 is one endpoint of veth pair. the other
>>> end is connected to a network namespace with ip address 172.16.1.2.
>>>
>>>
>>>
>>> From the network namespace, I cannot ping the other end 172.16.1.1.
>>>
>>>
>>>
>>> On r230, I can see  unknown ip protocol errors.
>>>
>>> vpp# sh errors
>>>CountNode  Reason
>>>  5null-node   blackholed packets
>>>  5  ipsec4-output-feature IPSec policy (no match)
>>>  1esp4-decrypt-tunESP pkts received
>>>  1ipsec4-tun-inputgood packets received
>>>  1  ipsec4-input-feature  IPSEC pkts received
>>>  1ip4-input   unknown ip protocol
>>>592gre-encap   GRE output packets
>>> encapsulated
>>>592  ipsec4-output-feature IPSec policy bypass
>>>592esp4-encrypt-tunESP pkts received
>>>592l2-output   L2 output packets
>>>592l

[vpp-dev] vlib_node_add_next_with_slot bug?

[Christian Hopps]

In my code based on the user changing the ipsec backend I need to update the 
node in my "encrypt" slots (for v4 and v6). I am calling 
vlib_node_add_next_with_slot to do this; however, the function isn't doing what 
I want.

Basically vlib_node_add_next_with_slot does the following:

  if ((p = hash_get (node->next_slot_by_node, next_node_index)))
{
  /* Next already exists: slot must match. */
  if (slot != ~0)
ASSERT (slot == p[0]);

  vlib_worker_thread_barrier_release (vm);
  return p[0];
}

Prior to making the change. It does not remove any old node from 
next_slot_by_node after it makes a change though. The result is that if you try 
and add back a node that was previously added (and removed) to that slot the 
function does nothing b/c it has this dangling reference in the hash table.

Now this could have been by design, but I suspect not as it really doesn't 
serve any purpose, that I can see, to leave an old node "back" reference there 
when it's no longer true.

If people agree I can submit a patch to remove the old hash table entry when 
the slot is changed.

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

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

[vpp-dev] plugin API header files

[Matthew Smith via Lists.Fd.Io]

Hi all,

I am trying to build some API client code against a copy of the
master branch I pulled a couple of days ago (ee74376 ip: refactor ip4_mtrie
to use atomic store-release). It seems like some required headers are not
getting installed for plugins.

E.g. - the LACP plugin header lacp.api.h has an '#include
"lacp.api_types.h"' which contains the typedef statements for the LACP API
message structs. The header lacp.api_types.h is generated in the build
directory but is not copied to the install directory.

[~/src/vpp]# grep '#include'
build-root/install-vpp_debug-native/vpp/include/vpp_plugins/lacp/lacp.api.h
#include 
#include "lacp.api_types.h"
[~/src/vpp]# ls build-root/build-vpp_debug-native/vpp/plugins/lacp/*api*
build-root/build-vpp_debug-native/vpp/plugins/lacp/lacp.api.c
build-root/build-vpp_debug-native/vpp/plugins/lacp/lacp.api_enum.h
build-root/build-vpp_debug-native/vpp/plugins/lacp/lacp.api.h
build-root/build-vpp_debug-native/vpp/plugins/lacp/lacp.api.json
build-root/build-vpp_debug-native/vpp/plugins/lacp/lacp.api_test.c
build-root/build-vpp_debug-native/vpp/plugins/lacp/lacp.api_types.h
[~/src/vpp]# ls
build-root/install-vpp_debug-native/vpp/include/vpp_plugins/lacp/
lacp.api.h  mux_machine.h  protocol.h rx_machine.h
machine.h   node.h ptx_machine.h  tx_machine.h

The other plugins that the code tries to build against have the same issue.
The client code I'm trying to build wants to include the header with
'vl_typedefs' defined in order to pull in the struct definitions, which
seem to be populated in lacp.api_types.h now.

API header file auto generation has changed recently. Did something get
missed with the plugins? Or is there something new that I need to do? The
vnet API headers don't seem to have this issue, it only appears to be
plugins that are affected.

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

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

[vpp-dev] DPDK coming to Mountain View

[Trishan de Lanerolle]

Hi,

If you are interested in or working with DPDK, the  community is hosting
their DPDK NA Summit, November 12-13 at the Computer History Museum, in
Mountain View.

The program and registration details can be found here:
https://events19.linuxfoundation.org/events/dpdknorthamerica2019/

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

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

Re: [EXT] [vpp-dev] cross-compilation support

[Nitin Saxena]

Understood. 

Thanks
Nitin

> -Original Message-
> From: Damjan Marion 
> Sent: Friday, November 1, 2019 5:13 PM
> To: Nitin Saxena 
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [EXT] [vpp-dev] cross-compilation support
> 
> 
> 
> > On 1 Nov 2019, at 12:14, Nitin Saxena  wrote:
> >
> > Hi Damjan,
> >
> >>> I don’t understand why you cannot specify your preferred set of args
> directly in the buildroot makefile...
> > We can do that. I thought (1) and (2) is the recommended way of cross
> > compiling VPP. So if I understand correctly all Makefiles in
> > build-data/platforms/ are intended for native compilation and not for
> > cross
> 
> There ere 2 different types of cross-compilation in my view:
> 
> 1. Platform images - where you build everything from scratch, toolchain,
> kernel, glibc, busybox - that is the case for which 2) was used in the past, 
> and
> it can be still used but somebody will need to create and maintain bunch of
> build-data/packages/*.mk files and those days it is not feasible that such
> thing will happen, as there are few well maintained open source projects
> which provide same functionality like buildroot, yocto, openwrt ...
> 
> 2. Distro packages - where vpp is crosscompiled, linked against distro
> provided shared libraries and packaged for that distro. That is something 2)
> cannot do properly, and that is the reason why i was looking for alternative
> solution with docker.
> 
> So in my view 2) provides maintenance overhead but not lot of value for our
> use cases, so we should replace it with something much simpler to maintain.
> 
> >
> > Thanks,
> > Nitin
> >
> >> -Original Message-
> >> From: Damjan Marion 
> >> Sent: Friday, November 1, 2019 4:10 PM
> >> To: Nitin Saxena 
> >> Cc: vpp-dev@lists.fd.io
> >> Subject: Re: [EXT] [vpp-dev] cross-compilation support
> >>
> >>
> >>
>  On 1 Nov 2019, at 09:57, Nitin Saxena  wrote:
> >>>
> >>> Hi Damjan,
> >>>
> > My comment bellow is that only 1) is really needed to build VPP,
> > people can decide to use own build system like buildroot or yocto
> > and invoke cmake directly, and completely ignore 2) and 3
> >>> Correct me if I am wrong, purpose of build-data/platforms/*.mk
> >>> (except
> >> vpp.mk) can be to configure ebuild for cross compilation. make
> >> build[- release] PLATFORM="aarch64..." was recommended way for cross
> >> compilation in VPP? If yes, is it OK to use 1) and 2) for cross 
> >> compilation?
> >>
> >> Personally i would not recommend to use 2) for cross-compilation
> >> because of reasons i explained in my previous emails.
> >>
> >>>
> >>> We internally uses (1) and (2) for our buildroot based cross
> >>> compilation for
> >> octeontx. Hence I asked for the capability to pass vpp_cmake_args
> >> from build-data/platforms/octeontx.mk because I found it as a cleaner
> approach.
> >> Comments?
> >>
> >> I don't see a point of doing that. you just add another moving part
> >> to your build system.
> >> I don’t understand why you cannot specify your preferred set of args
> >> directly in the buildroot makefile...
> >>
> >>
> >>>
> >>> Thanks,
> >>> Nitin
> >>>
>  -Original Message-
>  From: Damjan Marion 
>  Sent: Friday, November 1, 2019 1:34 AM
>  To: Damjan Marion 
>  Cc: Nitin Saxena ; vpp-dev@lists.fd.io
>  Subject: Re: [EXT] [vpp-dev] cross-compilation support
> 
> 
>  Let me clarify a bit more, as i can see that this still may be confusing:
> 
>  1) VPP is using cmake to build binaries and packages, all cmake
>  related stuff is in src/.
> 
>  2) there is build-root/Makefile and files in build-data/* which are
>  part of old build system called ebuild
>  - ebuild is very complex set of make scripts which have similar
>  functionality like buildroot, it was able to build kernel,
>  toolchain , userspace tools and libraries
>  - today we don't use much of ebuild, it is just used to run VPP
>  cmake prioject in the right directory with he right set of command
>  line arguments
> 
>  3) Other Makefiles
>  - top level makefile
>  - external deps makefiles in build/external/
> 
>  My comment bellow is that only 1) is really needed to build VPP,
>  people can decide to use own build system like buildroot or yocto
>  and invoke cmake directly, and completely ignore 2) and 3). In such
>  case selected build system also needs to take care for dependencies like
> DPDK.
> 
>  ebuild 2) have excellent cross compilation support for building
>  target images when those images contain everything from kernel and
>  libraries to vpp but it is not appropriate tool for creating
>  distribution packages, i.e. creating Centos ARM rpms on Ubuntu x86
>  machine. That is the reason why i tried to see if we can use docker
>  instead to be able to build cross-arch, cross-distro or cross-
>  distro-version
> >> (or all 3 together) packages.
> 

Re: [vpp-dev] event-logger output format

[Dave Barach via Lists.Fd.Io]

If you want to discover which functions are thread-safe the hard way, feel free 
to disable the barrier syncs as shown. Please don’t push a patch like that.

c->is_mp_safe != 0 means that a human being has looked at the code and done at 
least a cursory survey to make sure that vpp won’t have an accident if worker 
threads are allowed to process packets while the command runs.

We are not going to push barrier sync logic into every debug CLI command.

FWIW... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Aleksander Djuric
Sent: Friday, November 1, 2019 3:03 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] event-logger output format

Dave,
Thanks for your explanation!

In my opinion, it depends on what the "is_mp_safe" flag actually means. If all 
the functions are actually thread-safe and these barrier synchronization calls 
are required mainly for debugging, then I suggest the following:
#if CLIB_DEBUG > 0
if (!c->is_mp_safe)
   vlib_worker_thread_barrier_sync (vm);
#endif

c_error = c->function (vm, si, c);

#if CLIB_DEBUG > 0
if (!c->is_mp_safe)
   vlib_worker_thread_barrier_release (vm);
#endif

or

all these barrier synchronization calls must be moved into appropriate 
functions:

c_error = c->function (vm, si, c, sync);

Regards,

Aleksander
On Thu, Oct 31, 2019 at 10:27 PM, Dave Barach wrote:

Two cases: in single-core operation, debug CLI commands change the NDR / max 
throughput. A single “format” call might cost as many clock cycles as 
processing 50 packets. If the one and only core is busy printing something, 
it’s not processing packets.



In multi-core operation, CLI commands typically don’t change the NDR / max 
throughput numbers so long as they are marked thread_safe. Examples include 
“show run.” Note that most debug CLI commands are not marked thread-safe.



I think that folks will complain early and often if we start printing 
disclaimers every time vpp executes a non-thread-safe debug CLI command.



It wouldn’t be hard to count and [eventually] report non-thread-safe debug CLI 
commands. All such barrier sync calls originate in one place, in src/vlib/cli.c:



if (!c->is_mp_safe)

   vlib_worker_thread_barrier_sync (vm);



c_error = c->function (vm, si, c);



if (!c->is_mp_safe)

   vlib_worker_thread_barrier_release (vm);



What do people think?



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

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

Re: [EXT] [vpp-dev] cross-compilation support

[Damjan Marion via Lists.Fd.Io]

> On 1 Nov 2019, at 12:14, Nitin Saxena  wrote:
> 
> Hi Damjan,
> 
>>> I don’t understand why you cannot specify your preferred set of args 
>>> directly in the buildroot makefile...
> We can do that. I thought (1) and (2) is the recommended way of cross 
> compiling VPP. So if I understand correctly all Makefiles in 
> build-data/platforms/ are intended for native compilation and not for cross

There ere 2 different types of cross-compilation in my view:

1. Platform images - where you build everything from scratch, toolchain, 
kernel, glibc, busybox - that is the case for which 2) was used in the past, 
and it can be still used but somebody will need to create and maintain bunch of 
build-data/packages/*.mk files and those days it is not feasible that such 
thing will happen, as there are few well maintained open source projects which 
provide same functionality like buildroot, yocto, openwrt ...

2. Distro packages - where vpp is crosscompiled, linked against distro provided 
shared libraries and packaged for that distro. That is something 2) cannot do 
properly, and that is the reason why i was looking for alternative solution 
with docker.

So in my view 2) provides maintenance overhead but not lot of value for our use 
cases, so we should replace it with something much simpler to maintain.

> 
> Thanks,
> Nitin
> 
>> -Original Message-
>> From: Damjan Marion 
>> Sent: Friday, November 1, 2019 4:10 PM
>> To: Nitin Saxena 
>> Cc: vpp-dev@lists.fd.io
>> Subject: Re: [EXT] [vpp-dev] cross-compilation support
>> 
>> 
>> 
 On 1 Nov 2019, at 09:57, Nitin Saxena  wrote:
>>> 
>>> Hi Damjan,
>>> 
> My comment bellow is that only 1) is really needed to build VPP,
> people can decide to use own build system like buildroot or yocto
> and invoke cmake directly, and completely ignore 2) and 3
>>> Correct me if I am wrong, purpose of build-data/platforms/*.mk  (except
>> vpp.mk) can be to configure ebuild for cross compilation. make build[-
>> release] PLATFORM="aarch64..." was recommended way for cross
>> compilation in VPP? If yes, is it OK to use 1) and 2) for cross compilation?
>> 
>> Personally i would not recommend to use 2) for cross-compilation because of
>> reasons i explained in my previous emails.
>> 
>>> 
>>> We internally uses (1) and (2) for our buildroot based cross compilation for
>> octeontx. Hence I asked for the capability to pass vpp_cmake_args from
>> build-data/platforms/octeontx.mk because I found it as a cleaner approach.
>> Comments?
>> 
>> I don't see a point of doing that. you just add another moving part to your
>> build system.
>> I don’t understand why you cannot specify your preferred set of args directly
>> in the buildroot makefile...
>> 
>> 
>>> 
>>> Thanks,
>>> Nitin
>>> 
 -Original Message-
 From: Damjan Marion 
 Sent: Friday, November 1, 2019 1:34 AM
 To: Damjan Marion 
 Cc: Nitin Saxena ; vpp-dev@lists.fd.io
 Subject: Re: [EXT] [vpp-dev] cross-compilation support
 
 
 Let me clarify a bit more, as i can see that this still may be confusing:
 
 1) VPP is using cmake to build binaries and packages, all cmake
 related stuff is in src/.
 
 2) there is build-root/Makefile and files in build-data/* which are
 part of old build system called ebuild
 - ebuild is very complex set of make scripts which have similar
 functionality like buildroot, it was able to build kernel, toolchain
 , userspace tools and libraries
 - today we don't use much of ebuild, it is just used to run VPP cmake
 prioject in the right directory with he right set of command line
 arguments
 
 3) Other Makefiles
 - top level makefile
 - external deps makefiles in build/external/
 
 My comment bellow is that only 1) is really needed to build VPP,
 people can decide to use own build system like buildroot or yocto and
 invoke cmake directly, and completely ignore 2) and 3). In such case
 selected build system also needs to take care for dependencies like DPDK.
 
 ebuild 2) have excellent cross compilation support for building
 target images when those images contain everything from kernel and
 libraries to vpp but it is not appropriate tool for creating
 distribution packages, i.e. creating Centos ARM rpms on Ubuntu x86
 machine. That is the reason why i tried to see if we can use docker
 instead to be able to build cross-arch, cross-distro or cross- 
 distro-version
>> (or all 3 together) packages.
 While my patch is incomplete, it looks to me like this approach will work.
 
 My patch does native compilation only if TARGET_QUAD is equal to
 HOST_QUAD, where QUAD is:
 - distro name (ubuntu, centos)
 - distro version (18.04, 7.3)
 - arch (x86_64, aarch64, ...)
 - platform (generic, thunderx, ….)
 
 it also support multiple build_types (release, debug, gcov, … )
 
 At this point it is just 

Re: [EXT] [vpp-dev] cross-compilation support

[Nitin Saxena]

Hi Damjan,

>> I don’t understand why you cannot specify your preferred set of args 
>> directly in the buildroot makefile...
We can do that. I thought (1) and (2) is the recommended way of cross compiling 
VPP. So if I understand correctly all Makefiles in build-data/platforms/ are 
intended for native compilation and not for cross

Thanks,
Nitin

> -Original Message-
> From: Damjan Marion 
> Sent: Friday, November 1, 2019 4:10 PM
> To: Nitin Saxena 
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [EXT] [vpp-dev] cross-compilation support
> 
> 
> 
> > On 1 Nov 2019, at 09:57, Nitin Saxena  wrote:
> >
> > Hi Damjan,
> >
> >>> My comment bellow is that only 1) is really needed to build VPP,
> >>> people can decide to use own build system like buildroot or yocto
> >>> and invoke cmake directly, and completely ignore 2) and 3
> > Correct me if I am wrong, purpose of build-data/platforms/*.mk  (except
> vpp.mk) can be to configure ebuild for cross compilation. make build[-
> release] PLATFORM="aarch64..." was recommended way for cross
> compilation in VPP? If yes, is it OK to use 1) and 2) for cross compilation?
> 
> Personally i would not recommend to use 2) for cross-compilation because of
> reasons i explained in my previous emails.
> 
> >
> > We internally uses (1) and (2) for our buildroot based cross compilation for
> octeontx. Hence I asked for the capability to pass vpp_cmake_args from
> build-data/platforms/octeontx.mk because I found it as a cleaner approach.
> Comments?
> 
> I don't see a point of doing that. you just add another moving part to your
> build system.
> I don’t understand why you cannot specify your preferred set of args directly
> in the buildroot makefile...
> 
> 
> >
> > Thanks,
> > Nitin
> >
> >> -Original Message-
> >> From: Damjan Marion 
> >> Sent: Friday, November 1, 2019 1:34 AM
> >> To: Damjan Marion 
> >> Cc: Nitin Saxena ; vpp-dev@lists.fd.io
> >> Subject: Re: [EXT] [vpp-dev] cross-compilation support
> >>
> >>
> >> Let me clarify a bit more, as i can see that this still may be confusing:
> >>
> >> 1) VPP is using cmake to build binaries and packages, all cmake
> >> related stuff is in src/.
> >>
> >> 2) there is build-root/Makefile and files in build-data/* which are
> >> part of old build system called ebuild
> >> - ebuild is very complex set of make scripts which have similar
> >> functionality like buildroot, it was able to build kernel, toolchain
> >> , userspace tools and libraries
> >> - today we don't use much of ebuild, it is just used to run VPP cmake
> >> prioject in the right directory with he right set of command line
> >> arguments
> >>
> >> 3) Other Makefiles
> >>  - top level makefile
> >>  - external deps makefiles in build/external/
> >>
> >> My comment bellow is that only 1) is really needed to build VPP,
> >> people can decide to use own build system like buildroot or yocto and
> >> invoke cmake directly, and completely ignore 2) and 3). In such case
> >> selected build system also needs to take care for dependencies like DPDK.
> >>
> >> ebuild 2) have excellent cross compilation support for building
> >> target images when those images contain everything from kernel and
> >> libraries to vpp but it is not appropriate tool for creating
> >> distribution packages, i.e. creating Centos ARM rpms on Ubuntu x86
> >> machine. That is the reason why i tried to see if we can use docker
> >> instead to be able to build cross-arch, cross-distro or cross- 
> >> distro-version
> (or all 3 together) packages.
> >> While my patch is incomplete, it looks to me like this approach will work.
> >>
> >> My patch does native compilation only if TARGET_QUAD is equal to
> >> HOST_QUAD, where QUAD is:
> >> - distro name (ubuntu, centos)
> >> - distro version (18.04, 7.3)
> >> - arch (x86_64, aarch64, ...)
> >> - platform (generic, thunderx, ….)
> >>
> >> it also support multiple build_types (release, debug, gcov, … )
> >>
> >> At this point it is just early draft, but it shows some basic
> >> mechanics used to produce both native and cross packages.
> >>
> >>
> >>> On 31 Oct 2019, at 20:32, Damjan Marion via Lists.Fd.Io
> >>  wrote:
> >>>
> >>> I have similar scheme on my mind, where you can have platform
> >>> specific
> >> mk files loaded….
> >>>
>  On 31 Oct 2019, at 20:23, Nitin Saxena  wrote:
> 
>  Hi,
> 
> >> cmake  /path/to/vpp/src [your favorite xcompile args] cmake —build
> .
>  Instead of having a shell script to pass cmake commands, I really
>  liked the
> >> idea of passing vpp_cmake_args from build-data/platforms/*.mk
> >> (https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.fd.io_r_
> >> -
> >> 23_c_vpp_-2B_21035_23_build-2Ddata_platforms_native.mk-
> >>
> 4042&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=S4H7jibYAtA5YOvfL3IkGd
> >> uCfk9LbZMPOAecQGDzWV0&m=IxbLPjpkpGrr4_eh99mqx2_EhWrxhKwu-
> >> 8jEs5kosq8&s=izhC0z_k8Jz2hBw10il9EQpbYMyaLJ-d_7UczT_Ip8I&e= ). Any
> >> comment of taking those changes?
> 
>  Thanks,
>  

Re: [EXT] [vpp-dev] cross-compilation support

[Damjan Marion via Lists.Fd.Io]

> On 1 Nov 2019, at 09:57, Nitin Saxena  wrote:
> 
> Hi Damjan,
> 
>>> My comment bellow is that only 1) is really needed to build VPP,  people 
>>> can decide to use own build system like buildroot or yocto and invoke cmake 
>>> directly, and completely ignore 2) and 3
> Correct me if I am wrong, purpose of build-data/platforms/*.mk  (except 
> vpp.mk) can be to configure ebuild for cross compilation. make 
> build[-release] PLATFORM="aarch64..." was recommended way for cross 
> compilation in VPP? If yes, is it OK to use 1) and 2) for cross compilation?

Personally i would not recommend to use 2) for cross-compilation because of 
reasons i explained in my previous emails.

> 
> We internally uses (1) and (2) for our buildroot based cross compilation for 
> octeontx. Hence I asked for the capability to pass vpp_cmake_args from 
> build-data/platforms/octeontx.mk because I found it as a cleaner approach. 
> Comments?

I don't see a point of doing that. you just add another moving part to your 
build system.
I don’t understand why you cannot specify your preferred set of args directly 
in the buildroot makefile...


> 
> Thanks,
> Nitin 
> 
>> -Original Message-
>> From: Damjan Marion 
>> Sent: Friday, November 1, 2019 1:34 AM
>> To: Damjan Marion 
>> Cc: Nitin Saxena ; vpp-dev@lists.fd.io
>> Subject: Re: [EXT] [vpp-dev] cross-compilation support
>> 
>> 
>> Let me clarify a bit more, as i can see that this still may be confusing:
>> 
>> 1) VPP is using cmake to build binaries and packages, all cmake related stuff
>> is in src/.
>> 
>> 2) there is build-root/Makefile and files in build-data/* which are part of 
>> old
>> build system called ebuild
>> - ebuild is very complex set of make scripts which have similar functionality
>> like buildroot, it was able to build kernel, toolchain , userspace tools and
>> libraries
>> - today we don't use much of ebuild, it is just used to run VPP cmake 
>> prioject
>> in the right directory with he right set of command line arguments
>> 
>> 3) Other Makefiles
>>  - top level makefile
>>  - external deps makefiles in build/external/
>> 
>> My comment bellow is that only 1) is really needed to build VPP,  people can
>> decide to use own build system like buildroot or yocto and invoke cmake
>> directly, and completely ignore 2) and 3). In such case selected build system
>> also needs to take care for dependencies like DPDK.
>> 
>> ebuild 2) have excellent cross compilation support for building target images
>> when those images contain everything from kernel and libraries to vpp but it
>> is not appropriate tool for creating distribution packages, i.e. creating 
>> Centos
>> ARM rpms on Ubuntu x86 machine. That is the reason why i tried to see if we
>> can use docker instead to be able to build cross-arch, cross-distro or cross-
>> distro-version (or all 3 together) packages.
>> While my patch is incomplete, it looks to me like this approach will work.
>> 
>> My patch does native compilation only if TARGET_QUAD is equal to
>> HOST_QUAD, where QUAD is:
>> - distro name (ubuntu, centos)
>> - distro version (18.04, 7.3)
>> - arch (x86_64, aarch64, ...)
>> - platform (generic, thunderx, ….)
>> 
>> it also support multiple build_types (release, debug, gcov, … )
>> 
>> At this point it is just early draft, but it shows some basic mechanics used 
>> to
>> produce both native and cross packages.
>> 
>> 
>>> On 31 Oct 2019, at 20:32, Damjan Marion via Lists.Fd.Io
>>  wrote:
>>> 
>>> I have similar scheme on my mind, where you can have platform specific
>> mk files loaded….
>>> 
 On 31 Oct 2019, at 20:23, Nitin Saxena  wrote:
 
 Hi,
 
>> cmake  /path/to/vpp/src [your favorite xcompile args] cmake —build .
 Instead of having a shell script to pass cmake commands, I really liked the
>> idea of passing vpp_cmake_args from build-data/platforms/*.mk
>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.fd.io_r_-
>> 23_c_vpp_-2B_21035_23_build-2Ddata_platforms_native.mk-
>> 4042&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=S4H7jibYAtA5YOvfL3IkGd
>> uCfk9LbZMPOAecQGDzWV0&m=IxbLPjpkpGrr4_eh99mqx2_EhWrxhKwu-
>> 8jEs5kosq8&s=izhC0z_k8Jz2hBw10il9EQpbYMyaLJ-d_7UczT_Ip8I&e= ). Any
>> comment of taking those changes?
 
 Thanks,
 Nitin
 
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Damjan
> Marion via Lists.Fd.Io
> Sent: Friday, November 1, 2019 12:15 AM
> To: Christian Hopps 
> Cc: vpp-dev@lists.fd.io
> Subject: [EXT] Re: [vpp-dev] cross-compilation support
> 
> External Email
> 
> 
> --
> 
> Nobody requires you to use docker, you are free to pass right
> arguments straight to the cmake.
> 
> All the stuff in build-data, build-root, build/ is optional, and it
> is there to help developers to stage workspace and create packages
> but VPP can be built as simple as:
> 
> mkd

Re: [vpp-dev] RDMA fix needed in 19.08 also

[Elias Rudberg]

Yes, now it works. Thank you!
/ Elias


On Fri, 2019-11-01 at 08:42 +0100, Andrew 👽 Yourtchenko wrote:
> It’s merged. Please let me know if all ok now.
> 
> --a
> 
> > On 31 Oct 2019, at 23:55, Andrew Yourtchenko via Lists.Fd.Io <
> > ayourtch=gmail@lists.fd.io> wrote:
> > 
> > Elias,
> > 
> > Thanks for telling! I have cherry-picked  
> > https://gerrit.fd.io/r/#/c/vpp/+/23164/ and will merge it tomorrow.
> > 
> > --a
> > 
> > > On 31 Oct 2019, at 19:18, Elias Rudberg <
> > > elias.rudb...@bahnhof.net> wrote:
> > > 
> > > 386ebb6e2b
> > 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [EXT] [vpp-dev] cross-compilation support

[Nitin Saxena]

Hi Damjan,

>> My comment bellow is that only 1) is really needed to build VPP,  people can 
>> decide to use own build system like buildroot or yocto and invoke cmake 
>> directly, and completely ignore 2) and 3
Correct me if I am wrong, purpose of build-data/platforms/*.mk  (except vpp.mk) 
can be to configure ebuild for cross compilation. make build[-release] 
PLATFORM="aarch64..." was recommended way for cross compilation in VPP? If yes, 
is it OK to use 1) and 2) for cross compilation?

We internally uses (1) and (2) for our buildroot based cross compilation for 
octeontx. Hence I asked for the capability to pass vpp_cmake_args from 
build-data/platforms/octeontx.mk because I found it as a cleaner approach. 
Comments?

Thanks,
Nitin 

> -Original Message-
> From: Damjan Marion 
> Sent: Friday, November 1, 2019 1:34 AM
> To: Damjan Marion 
> Cc: Nitin Saxena ; vpp-dev@lists.fd.io
> Subject: Re: [EXT] [vpp-dev] cross-compilation support
> 
> 
> Let me clarify a bit more, as i can see that this still may be confusing:
> 
> 1) VPP is using cmake to build binaries and packages, all cmake related stuff
> is in src/.
> 
> 2) there is build-root/Makefile and files in build-data/* which are part of 
> old
> build system called ebuild
>  - ebuild is very complex set of make scripts which have similar functionality
> like buildroot, it was able to build kernel, toolchain , userspace tools and
> libraries
>  - today we don't use much of ebuild, it is just used to run VPP cmake 
> prioject
> in the right directory with he right set of command line arguments
> 
> 3) Other Makefiles
>   - top level makefile
>   - external deps makefiles in build/external/
> 
> My comment bellow is that only 1) is really needed to build VPP,  people can
> decide to use own build system like buildroot or yocto and invoke cmake
> directly, and completely ignore 2) and 3). In such case selected build system
> also needs to take care for dependencies like DPDK.
> 
> ebuild 2) have excellent cross compilation support for building target images
> when those images contain everything from kernel and libraries to vpp but it
> is not appropriate tool for creating distribution packages, i.e. creating 
> Centos
> ARM rpms on Ubuntu x86 machine. That is the reason why i tried to see if we
> can use docker instead to be able to build cross-arch, cross-distro or cross-
> distro-version (or all 3 together) packages.
> While my patch is incomplete, it looks to me like this approach will work.
> 
> My patch does native compilation only if TARGET_QUAD is equal to
> HOST_QUAD, where QUAD is:
>  - distro name (ubuntu, centos)
>  - distro version (18.04, 7.3)
>  - arch (x86_64, aarch64, ...)
>  - platform (generic, thunderx, ….)
> 
> it also support multiple build_types (release, debug, gcov, … )
> 
> At this point it is just early draft, but it shows some basic mechanics used 
> to
> produce both native and cross packages.
> 
> 
> > On 31 Oct 2019, at 20:32, Damjan Marion via Lists.Fd.Io
>  wrote:
> >
> > I have similar scheme on my mind, where you can have platform specific
> mk files loaded….
> >
> >> On 31 Oct 2019, at 20:23, Nitin Saxena  wrote:
> >>
> >> Hi,
> >>
>  cmake  /path/to/vpp/src [your favorite xcompile args] cmake —build .
> >> Instead of having a shell script to pass cmake commands, I really liked the
> idea of passing vpp_cmake_args from build-data/platforms/*.mk
> (https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.fd.io_r_-
> 23_c_vpp_-2B_21035_23_build-2Ddata_platforms_native.mk-
> 4042&d=DwIFaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=S4H7jibYAtA5YOvfL3IkGd
> uCfk9LbZMPOAecQGDzWV0&m=IxbLPjpkpGrr4_eh99mqx2_EhWrxhKwu-
> 8jEs5kosq8&s=izhC0z_k8Jz2hBw10il9EQpbYMyaLJ-d_7UczT_Ip8I&e= ). Any
> comment of taking those changes?
> >>
> >> Thanks,
> >> Nitin
> >>
> >>> -Original Message-
> >>> From: vpp-dev@lists.fd.io  On Behalf Of Damjan
> >>> Marion via Lists.Fd.Io
> >>> Sent: Friday, November 1, 2019 12:15 AM
> >>> To: Christian Hopps 
> >>> Cc: vpp-dev@lists.fd.io
> >>> Subject: [EXT] Re: [vpp-dev] cross-compilation support
> >>>
> >>> External Email
> >>>
> >>> 
> >>> --
> >>>
> >>> Nobody requires you to use docker, you are free to pass right
> >>> arguments straight to the cmake.
> >>>
> >>> All the stuff in build-data, build-root, build/ is optional, and it
> >>> is there to help developers to stage workspace and create packages
> >>> but VPP can be built as simple as:
> >>>
> >>> mkdir build
> >>> cd build
> >>> cmake  /path/to/vpp/src [your favorite xcompile args] cmake —build .
> >>>
> >>>
> >>>
>  On 31 Oct 2019, at 19:39, Christian Hopps 
> wrote:
> 
>  I mean to call out the use of docker/qemu. In order to allow for
>  this the
> >>> user has to have extra privileges.
> 
>  As I mentioned, locally we use docker for building, I like it, it's
>  a nice tool;
> >>> however, my personal opinion is that it seems wrong to req

[vpp-dev] cannot ping from host while vpp config with dpdk

[hoannv46]

Hi all.

My lab follow this guide : https://wiki.fd.io/view/VPP/Tutorial_DPDK_and_MacSwap

Interface info
> 
> vpp# show int
> Name   Idx    State  MTU (L3/IP4/IP6/MPLS) Counter
> Count
> TenGigabitEthernet5e/0/0  1  up  9000/0/0/0 rx
> packets   133
> rx bytes   29526
> drops 82
> punt  55

vpp ip info
> 
> vpp# show int addr
> TenGigabitEthernet5e/0/0 (up):
> L3 10.10.1.1/24

But i cannot ping ip 10.10.1.1 from hosts.
How can i config to ping 10.10.1.1.

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

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

Re: [EXT] [vpp-dev] cross-compilation support

[Luca Muscariello]

FYI,
I have recently started to use the buildx experimental feature in docker
(>=19.03).

it looks interesting as it is designed on purpose for building
multi-platform images,
and manages to reuse the same dockerfile for as many platforms as supported
by qemu (in theory).

I'm not quite sure yet about the actual concerns of running emulation
with jailed envs such as docker or the oldish chroot as opposed to
x-compilation.
I've tested for amd64/arm64 and works well.

docker buildx build --platform linux/arm64,linux/amd64 -t myorg/vswitch -f
Dockerfile .



On Thu, Oct 31, 2019 at 10:48 PM Christian Hopps  wrote:

>
>
> > On Oct 31, 2019, at 5:39 PM, Damjan Marion via Lists.Fd.Io  me@lists.fd.io> wrote:
> >
> >
> >
> >> On 31 Oct 2019, at 21:41, Christian Hopps  wrote:
> >>
> >>>
> >>> On Oct 31, 2019, at 4:03 PM, Damjan Marion via Lists.Fd.Io  me@lists.fd.io> wrote:
> >>>
> >>>
> >>> Let me clarify a bit more, as i can see that this still may be
> confusing:
> >>>
> >>> 1) VPP is using cmake to build binaries and packages, all cmake
> related stuff is in src/.
> >>>
> >>> 2) there is build-root/Makefile and files in build-data/* which are
> part of old build system called ebuild
> >>> - ebuild is very complex set of make scripts which have similar
> functionality like buildroot, it was able to build kernel, toolchain ,
> userspace tools and libraries
> >>> - today we don't use much of ebuild, it is just used to run VPP cmake
> prioject in the right directory with he right set of command line arguments
> >>>
> >>> 3) Other Makefiles
> >>> - top level makefile
> >>> - external deps makefiles in build/external/
> >>
> >>>
> >>> My comment bellow is that only 1) is really needed to build VPP,
> people can decide to use own build system like buildroot or yocto and
> invoke
> >>> cmake directly, and completely ignore 2) and 3). In such case selected
> build system also needs to take care for dependencies like DPDK.
> >>
> >> FWIW, (3) includes "build/external/patches/" which patch the standard
> distributions to add extra functionality. These patches could/will
> presumably eventually be upstreamed, but it's pretty useful for getting
> work done in the meantime.
> >
> > Not sure how is this related to this discussion, but to address your
> concerns i just submitted changes to remove 2 out of 3 patches. 3rd one is
> related to quickly library, and I will do my best to encourage authors to
> upstream that :)
>
> Thanks! :)
>
> I was only pointing out that if one only does (1) (using pre-built
> external packages instead of (3)) then one misses the patched
> functionality. And yes, one could also build those packages separately and
> apply the patches by hand, but that's a lot more work so (3) is pretty
> useful is all.
>
> Thanks,
> Chris.
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#14445): https://lists.fd.io/g/vpp-dev/message/14445
> Mute This Topic: https://lists.fd.io/mt/40243741/675095
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [muscarie...@ieee.org]
> -=-=-=-=-=-=-=-=-=-=-=-
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14455): https://lists.fd.io/g/vpp-dev/message/14455
Mute This Topic: https://lists.fd.io/mt/40243741/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] RDMA fix needed in 19.08 also

[Andrew Yourtchenko]

It’s merged. Please let me know if all ok now.

--a

> On 31 Oct 2019, at 23:55, Andrew Yourtchenko via Lists.Fd.Io 
>  wrote:
> 
> Elias,
> 
> Thanks for telling! I have cherry-picked  
> https://gerrit.fd.io/r/#/c/vpp/+/23164/ and will merge it tomorrow.
> 
> --a
> 
>>> On 31 Oct 2019, at 19:18, Elias Rudberg  wrote:
>>> 
>> 386ebb6e2b
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#14446): https://lists.fd.io/g/vpp-dev/message/14446
> Mute This Topic: https://lists.fd.io/mt/40219418/675608
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [ayour...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14454): https://lists.fd.io/g/vpp-dev/message/14454
Mute This Topic: https://lists.fd.io/mt/40219418/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] event-logger output format

[Aleksander Djuric]

Dave,
Thanks for your explanation!

In my opinion, it depends on what the "is_mp_safe" flag actually means. If all 
the functions are actually thread-safe and these barrier synchronization calls 
are required mainly for debugging, then I suggest the following:

#if CLIB_DEBUG > 0
if (!c->is_mp_safe)
vlib_worker_thread_barrier_sync (vm);
#endif

c_error = c->function (vm, si, c);

#if CLIB_DEBUG > 0
if (!c->is_mp_safe)
vlib_worker_thread_barrier_release (vm);
#endif

or

all these barrier synchronization calls must be moved into appropriate 
functions:

c_error = c->function (vm, si, c, sync);

Regards,

Aleksander

On Thu, Oct 31, 2019 at 10:27 PM, Dave Barach wrote:

> 
> 
> 
> Two cases: in single-core operation, debug CLI commands change the NDR /
> max throughput. A single “format” call might cost as many clock cycles as
> processing 50 packets. If the one and only core is busy printing
> something, it’s not processing packets.
> 
> 
> 
> 
> 
> 
> 
> In multi-core operation, CLI commands typically don’t change the NDR / max
> throughput numbers so long as they are marked thread_safe. Examples
> include “show run.” Note that most debug CLI commands are not marked
> thread-safe.
> 
> 
> 
> 
> 
> 
> 
> I think that folks will complain early and often if we start printing
> disclaimers every time vpp executes a non-thread-safe debug CLI command.
> 
> 
> 
> 
> 
> 
> 
> It wouldn’t be hard to count and [eventually] report non-thread-safe debug
> CLI commands. All such barrier sync calls originate in one place, in
> src/vlib/cli.c:
> 
> 
> 
> 
> 
> 
> 
> if (!c->is_mp_safe)
> 
> 
> 
> vlib_worker_thread_barrier_sync (vm);
> 
> 
> 
> 
> 
> 
> 
> c_error = c->function (vm, si, c);
> 
> 
> 
> 
> 
> 
> 
> if (!c->is_mp_safe)
> 
> 
> 
> vlib_worker_thread_barrier_release (vm);
> 
> 
> 
> 
> 
> 
> 
> What do people think?
> 
> 
> 
> 
> 
> 
> 
> Thanks... Dave
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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