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

[Florin Coras]

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 (>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: 

Re: [vpp-dev] Can "use mq eventfd" solve epoll wait h =?utf-8?Q?_igh_cpu_usage_problem??=

[wanghanlin]

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, FlorinOn 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,Hanlinwanghanlinwanghan...@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,FlorinOn 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 (>clib_time) < max_time));wanghanlinwanghan...@corp.netease.com签名由 网易邮箱大师 定制-=-=-=-=-=-=-=-=-=-=-=-Links: You receive all messages sent to this group.View/Reply Online (#14413): https://lists.fd.io/g/vpp-dev/message/14413Mute This Topic: https://lists.fd.io/mt/40123765/675152Group Owner: vpp-dev+ow...@lists.fd.ioUnsubscribe: 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/14448Mute This Topic: https://lists.fd.io/mt/40351193/675152Group Owner: vpp-dev+ow...@lists.fd.ioUnsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [fcoras.li...@gmail.com]-=-=-=-=-=-=-=-=-=-=-=-



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

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

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

[Nitin Saxena]

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://gerrit.fd.io/r/#/c/vpp/+/21035/23/build-data/platforms/native.mk@42). 
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 require docker
> and/or qemu for compiling an open source project.
> >
> > Important in holding this opinion is that it's seems possible to make this
> work w/o docker/qemu/root, I think someone just has to find the time to
> make an acceptable to the project working patch.
> >
> > I asked internally and it seems that our changes to support x-compile do
> not go as far as producing debian/ubuntu packages, so they aren't ready for
> upstreaming, unfortunately.
> >
> > Thanks,
> > Chris.
> >
> >> On Oct 31, 2019, at 2:23 PM, Damjan Marion  wrote:
> >>
> >>
> >> That is just copy paste from Ben’s command line.
> >>
> >> As. i wrote, this is just about presenting the concept...
> >>
> >>> On 31 Oct 2019, at 18:39, Christian Hopps  wrote:
> >>>
> >>> Requiring root privileges for building software is pretty atypical and
> limiting, even for x-compiling.
> >>>
> >>> Thanks,
> >>> Chris.
> >>>
>  On Oct 31, 2019, at 12:45 PM, Damjan Marion via Lists.Fd.Io
>  wrote:
> 
> 
>  So what people think about following approach for cross-compilation:
> 
>  Patch:
>  https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.fd.io_r
>  _c_vpp_-
> 2B_23153=DwIFaQ=nKjWec2b6R0mOyPaz7xtfQ=S4H7jibYAtA5YO
> 
> vfL3IkGduCfk9LbZMPOAecQGDzWV0=G81bDw8Lj77hbqAq7cdeDRXZev-
> ZVMwh0n_
>  oePUFrlQ=Lk5OD0CVQuGPdj-h0TfK-m8NMJj0Zci0EhjBcQxYn2E=
> 
>  At the moment this is just to show idea, so it works only for
>  x86-to-x86 and between ubuntu versions only but it can be easily
> extended to scenarios like build vpp packages for AArch64 centos7 on
> ubuntu x86 host.
> 
>  export CROSS_DISTRO_NAME=ubuntu
>  exprot CROSS_DISTRO_VER=18.04
>  export CROSS_ARCH=x86_64
>  export CROSS_TARGET=release
> 
>  $ make cross-env-init
> 
>  this is executed once, it creates docker container named "vpp-dev-env-
> ubuntu-18.04-x86_64”, install all dependencies including DPDK and other
> libs”
> 
>  $ make cross-env-update
> 
>  updates cross-env to latest packages and ext-deps
> 
>  $ make cross-shell
> 
>  starts shell inside cross-env
> 
>  $ make cross-package
> 
>  builds VPP and creates packages:
> 
>  ls -la build/ubuntu-18.04-x86_64-release total 11716
>  drwxr-xr-x  3 root root4096 Oct 31 17:30 .
>  drwxrwxr-x  4 damarion damarion4096 Oct 31 17:36 ..
>  drwxr-xr-x 22 root root4096 Oct 31 17:30 build
>  -rw-r--r--  1 root root  190124 Oct 31 17:30 libvppinfra_20.01-
> rc0~555-g7f980bcfe_amd64.deb
>  -rw-r--r--  1 root root  145056 Oct 31 17:30 
>  libvppinfra-dev_20.01-
> rc0~555-g7f980bcfe_amd64.deb
>  -rw-r--r--  1 root root   23140 Oct 31 17:30 
>  python3-vpp-api_20.01-
> rc0~555-g7f980bcfe_amd64.deb
>  -rw-r--r--  1 root root8815 Oct 31 17:30 vpp_20.01-rc0~555-
> g7f980bcfe_amd64.buildinfo
>  -rw-r--r--  1 root root4147 Oct 31 17:30 vpp_20.01-rc0~555-
> g7f980bcfe_amd64.changes
>  -rw-r--r--  1 root root 3674024 Oct 31 17:30 vpp_20.01-rc0~555-
> g7f980bcfe_amd64.deb
>  -rw-r--r--  1 root root   23104 Oct 31 17:30 
>  vpp-api-python_20.01-
> rc0~555-g7f980bcfe_amd64.deb
>  -rw-r--r--  1 root root  719712 Oct 31 17:30 
>  vpp-dbg_20.01-rc0~555-
> g7f980bcfe_amd64.deb
>  -rw-r--r--  1 root root  915744 Oct 31 17:30 
>  vpp-dev_20.01-rc0~555-
> g7f980bcfe_amd64.deb
>  -rw-r--r--  1 root root 3113820 Oct 31 17:30 
>  

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

[Florin Coras]

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 (>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.

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

[carlito nueno]

Hi Filip,

Thank you! I can do some tests if you want.

On Thu, Oct 31, 2019 at 7:14 AM Filip Varga -X (fivarga - PANTHEON TECH SRO
at Cisco)  wrote:

> 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
>
>
>
>
>
> [image:
> 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
>
> [image: 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 (#14449): https://lists.fd.io/g/vpp-dev/message/14449
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 =?utf-8?Q?igh_cpu_usage_problem??=

[wanghanlin]

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,FlorinOn 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 (>clib_time) < max_time));wanghanlinwanghan...@corp.netease.com签名由 网易邮箱大师 定制-=-=-=-=-=-=-=-=-=-=-=-Links: You receive all messages sent to this group.View/Reply Online (#14413): https://lists.fd.io/g/vpp-dev/message/14413Mute This Topic: https://lists.fd.io/mt/40123765/675152Group Owner: vpp-dev+ow...@lists.fd.ioUnsubscribe: 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/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] vpp with gtpu

[Guo, Ruijing]

Hi, Neale, Hongjun

The environment issue was fixed. Thanks for your help.

Thanks,
-Ruijing

From: Guo, Ruijing
Sent: Thursday, October 31, 2019 4:43 PM
To: Neale Ranns (nranns) ; Ni, Hongjun 
; vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] vpp with gtpu

Good catch, neale I will check why it use 192.168.1.1.

From: Neale Ranns (nranns) mailto:nra...@cisco.com>>
Sent: Thursday, October 31, 2019 4:39 PM
To: Guo, Ruijing mailto:ruijing@intel.com>>; Ni, 
Hongjun mailto:hongjun...@intel.com>>; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vpp with gtpu


Hi Ruijing,

Comments inline.

/neale

From: mailto:vpp-dev@lists.fd.io>> on behalf of "Guo, 
Ruijing" mailto:ruijing@intel.com>>
Date: Thursday 31 October 2019 at 09:29
To: "Ni, Hongjun" mailto:hongjun...@intel.com>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] vpp with gtpu

Hi, Hongjun

After adding the configuration, ping still failed as:

Packet 14

00:02:10:052842: af-packet-input
  af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
  status 0x81 len 146 snaplen 146 mac 66 net 80
  sec 0x5dbb241d nsec 0x2a83d8a6 vlan 0 vlan_tpid 0
00:02:10:052858: ethernet-input
  IP4: 52:54:00:43:88:63 -> 52:54:00:12:ab:01
00:02:10:052867: ip4-input
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:02:10:052878: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  UDP: 192.168.1.1 -> 192.168.1.22

^^ the packet is not sourced from the end-point address of the tunnel, hence 
does not classify to a tunnel …

tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:02:10:052888: ip4-local
UDP: 192.168.1.1 -> 192.168.1.22
  tos 0x00, ttl 253, length 132, checksum 0x3a01
  fragment id 0x
UDP: 24445 -> 2152
  length 112, checksum 0x
00:02:10:052892: ip4-udp-lookup
  UDP: src-port 24445 dst-port 2152
00:02:10:052894: gtpu4-input
  GTPU decap error - tunnel for teid 13 does not exist

… here ^^^.

Check the sender to see why it uses 192.168.1.1 as a source address.

/neale

00:02:10:052900: error-drop
  rx:host-eth1
00:02:10:052901: drop
  gtpu4-input: no such tunnel packets

From: Ni, Hongjun mailto:hongjun...@intel.com>>
Sent: Thursday, October 31, 2019 4:22 PM
To: Guo, Ruijing mailto:ruijing@intel.com>>; 
vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi Ruijing,

It seems that GTPU did not failed on the fib check.

Please add below items on your configuration:
sudo vppctl create gtpu tunnel src 192.168.1.22 dst 192.168.1.21 teid 13 
encap-vrf-id 0 decap-next ip4

Thanks,
Hongjun

From: Guo, Ruijing mailto:ruijing@intel.com>>
Sent: Thursday, October 31, 2019 3:23 PM
To: Ni, Hongjun mailto:hongjun...@intel.com>>; 
vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi, Hongjun

Packets are attached

Thanks,
-Ruijing

From: Ni, Hongjun mailto:hongjun...@intel.com>>
Sent: Thursday, October 31, 2019 3:12 PM
To: Guo, Ruijing mailto:ruijing@intel.com>>; 
vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi Ruijing,

It seems that there may be some issue on the gtpu decapsulation.

Could you help to capture the traffic between the vpp1 side and  vpp2 side?

Thanks,
Hongjun

From: Guo, Ruijing mailto:ruijing@intel.com>>
Sent: Thursday, October 31, 2019 2:57 PM
To: vpp-dev@lists.fd.io
Cc: Ni, Hongjun mailto:hongjun...@intel.com>>
Subject: vpp with gtpu

Hi,

I tried vpp (18.04-release, 19.08.1-release) with gtpu. it cannot work. Could 
you pls help?

Vpp1 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int mac address host-eth1 52:54:00:43:88:63
sudo vppctl set int ip add host-eth1 192.168.1.21/24
sudo vppctl show ip arp
sudo vppctl create gtpu tunnel src 192.168.1.21 dst 192.168.1.22 teid 13
sudo vppctl set int ip address gtpu_tunnel0  10.10.1.1/24
sudo vppctl set int stat gtpu_tunnel0 up

Vpp2 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int ip add host-eth1 192.168.1.22/24
sudo vppctl set int mac address host-eth1 52:54:00:12:ab:01
sudo vppctl create gtpu tunnel src 192.168.1.22 dst 192.168.1.21 teid 13
sudo vppctl set int  ip address gtpu_tunnel0  10.10.1.2/24
sudo vppctl set int stat gtpu_tunnel0 up


vpp1:
vagrant@vpp1:/vagrant$ sudo vppctl ping 192.168.1.22
116 bytes from 192.168.1.22: icmp_seq=1 ttl=64 time=3.8251 ms (<<< expect)

vagrant@vpp1:/vagrant$ sudo vppctl ping 10.10.1.2

Statistics: 5 sent, 0 received, 100% packet loss  (<<< expect ping can work)

I use wiresharp to decode the packets. TEID = 13 (exepct)


Vpp2:

Packet 13

00:18:42:156858: af-packet-input
  af_packet: hw_if_index 1 next-index 4

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

[Andrew Yourtchenko]

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/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

[Christian Hopps]

> On Oct 31, 2019, at 5:39 PM, Damjan Marion via 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 
>>>  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/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 31 Oct 2019, at 21:41, Christian Hopps  wrote:
> 
>> 
>> On Oct 31, 2019, at 4:03 PM, Damjan Marion via 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 :)


> 
>> 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://gerrit.fd.io/r/#/c/vpp/+/21035/23/build-data/platforms/native.mk@42).
  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 require docker
> and/or qemu for compiling an open source project.
>> 
>> Important in holding this opinion is that it's seems possible to make 
>> this
> work w/o docker/qemu/root, I think someone just has to find the time to
> make an acceptable to the project working patch.
>> 
>> I asked internally and it seems that our changes to support x-compile do
> not go as far as producing debian/ubuntu packages, so they aren't ready 
> for
> upstreaming, unfortunately.

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

[Christian Hopps]

> On Oct 31, 2019, at 4:03 PM, Damjan Marion via 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.

Thanks,
Chris.



> 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://gerrit.fd.io/r/#/c/vpp/+/21035/23/build-data/platforms/native.mk@42).
>>>  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 require docker
 and/or qemu for compiling an open source project.
> 
> Important in holding this opinion is that it's seems possible to make this
 work w/o docker/qemu/root, I think someone just has to find the time to
 make an acceptable to the project working patch.
> 
> I asked internally and it seems that our changes to support x-compile do
 not go as far as producing debian/ubuntu packages, so they aren't ready for
 upstreaming, unfortunately.
> 
> Thanks,
> Chris.
> 
>> On Oct 31, 2019, at 2:23 PM, Damjan Marion  wrote:
>> 
>> 
>> That is just copy paste from Ben’s command line.
>> 
>> As. i wrote, this is just about presenting the concept...
>> 
>>> On 31 Oct 2019, at 18:39, Christian Hopps  wrote:
>>> 
>>> Requiring root privileges for building software is pretty atypical and
 limiting, even 

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

[Balaji Venkatraman via Lists.Fd.Io]

Dave,
Couldn’t have explained it better! Thanks much!

Given that most CPU’s are 2+ cores, it should be okay but, you say “Note that 
most debug CLI commands are not marked thread-safe”

Does it mean, it might they would still revert to a single-core like operation?

Thanks!
--
Regards,
Balaji.


From: "Dave Barach (dbarach)" 
Date: Thursday, October 31, 2019 at 12:27 PM
To: "Balaji Venkatraman (balajiv)" , "vpp-dev@lists.fd.io" 

Subject: RE: [vpp-dev] event-logger output format

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

From: vpp-dev@lists.fd.io  On Behalf Of Balaji Venkatraman 
via Lists.Fd.Io
Sent: Thursday, October 31, 2019 12:21 PM
To: Aleksander Djuric ; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] event-logger output format

Do you think it would be prudent to publish a ‘warning’ message on its impact 
on packet forwarding when this cmd is used?

Thanks!

--
Regards,
Balaji.


From: mailto:vpp-dev@lists.fd.io>> on behalf of Aleksander 
Djuric mailto:aleksander.dju...@gmail.com>>
Date: Thursday, October 31, 2019 at 8:07 AM
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] event-logger output format

Hi Dave, Thanks!

Now it looks like this:
> show event-logger [all] [] [delta|no-delta|date-time]

Updated patch:
https://gerrit.fd.io/r/c/vpp/+/23146


On Thu, Oct 31, 2019 at 04:47 PM, Dave Barach wrote:

Yes, we see things differently. I never look at elog data in the debug CLI. I 
save the data and deal with it offline. See 
https://fd.io/docs/vpp/master/gettingstarted/developers/eventviewer.html. We 
often use elog buffer sizes measured in millions of events. The offline tools 
are happy to deal with 1e7 events.



Packet processing comes to a screeching halt while the “show event-logger” 
debug CLI command runs. If folks decide that it’s worth trying to use the “show 
event-logger” debug CLI on a regular basis, the first step should be to make 
and mark the debug CLI command thread-safe. At least when using one or more 
worker threads, packet processing won’t stop in its tracks for the duration...



I would prefer something of the form “show event-logger ... [full-timestamp]” 
to request date/hms/msusns timestamps, and I would prefer the delta format I 
described to tagging each event with a full timestamp. Maybe add 
“[delta|no-delta]” qualifier keywords to the debug CLI command.



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

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

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://gerrit.fd.io/r/#/c/vpp/+/21035/23/build-data/platforms/native.mk@42).
>>  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 require docker
>>> and/or qemu for compiling an open source project.
 
 Important in holding this opinion is that it's seems possible to make this
>>> work w/o docker/qemu/root, I think someone just has to find the time to
>>> make an acceptable to the project working patch.
 
 I asked internally and it seems that our changes to support x-compile do
>>> not go as far as producing debian/ubuntu packages, so they aren't ready for
>>> upstreaming, unfortunately.
 
 Thanks,
 Chris.
 
> On Oct 31, 2019, at 2:23 PM, Damjan Marion  wrote:
> 
> 
> That is just copy paste from Ben’s command line.
> 
> As. i wrote, this is just about presenting the concept...
> 
>> On 31 Oct 2019, at 18:39, Christian Hopps  wrote:
>> 
>> Requiring root privileges for building software is pretty atypical and
>>> limiting, even for x-compiling.
>> 
>> Thanks,
>> Chris.
>> 
>>> On Oct 31, 2019, at 12:45 PM, Damjan Marion via Lists.Fd.Io
>>>  wrote:
>>> 
>>> 
>>> So what people think about following approach for cross-compilation:
>>> 
>>> Patch:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.fd.io_r
>>> _c_vpp_-
>>> 2B_23153=DwIFaQ=nKjWec2b6R0mOyPaz7xtfQ=S4H7jibYAtA5YO
>>> 
>>> vfL3IkGduCfk9LbZMPOAecQGDzWV0=G81bDw8Lj77hbqAq7cdeDRXZev-
>>> 

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

[Damjan Marion via Lists.Fd.Io]

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://gerrit.fd.io/r/#/c/vpp/+/21035/23/build-data/platforms/native.mk@42).
>  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 require docker
>> and/or qemu for compiling an open source project.
>>> 
>>> Important in holding this opinion is that it's seems possible to make this
>> work w/o docker/qemu/root, I think someone just has to find the time to
>> make an acceptable to the project working patch.
>>> 
>>> I asked internally and it seems that our changes to support x-compile do
>> not go as far as producing debian/ubuntu packages, so they aren't ready for
>> upstreaming, unfortunately.
>>> 
>>> Thanks,
>>> Chris.
>>> 
 On Oct 31, 2019, at 2:23 PM, Damjan Marion  wrote:
 
 
 That is just copy paste from Ben’s command line.
 
 As. i wrote, this is just about presenting the concept...
 
> On 31 Oct 2019, at 18:39, Christian Hopps  wrote:
> 
> Requiring root privileges for building software is pretty atypical and
>> limiting, even for x-compiling.
> 
> Thanks,
> Chris.
> 
>> On Oct 31, 2019, at 12:45 PM, Damjan Marion via Lists.Fd.Io
>>  wrote:
>> 
>> 
>> So what people think about following approach for cross-compilation:
>> 
>> Patch:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.fd.io_r
>> _c_vpp_-
>> 2B_23153=DwIFaQ=nKjWec2b6R0mOyPaz7xtfQ=S4H7jibYAtA5YO
>> 
>> vfL3IkGduCfk9LbZMPOAecQGDzWV0=G81bDw8Lj77hbqAq7cdeDRXZev-
>> ZVMwh0n_
>> oePUFrlQ=Lk5OD0CVQuGPdj-h0TfK-m8NMJj0Zci0EhjBcQxYn2E=
>> 
>> At the moment this is just to show idea, so it works only for
>> x86-to-x86 and between ubuntu versions only but it can be easily
>> extended to scenarios like build vpp packages for AArch64 centos7 on
>> ubuntu x86 host.
>> 
>> export CROSS_DISTRO_NAME=ubuntu
>> exprot CROSS_DISTRO_VER=18.04
>> export CROSS_ARCH=x86_64
>> export CROSS_TARGET=release
>> 
>> $ make cross-env-init
>> 
>> this is executed once, it creates docker container named "vpp-dev-env-
>> ubuntu-18.04-x86_64”, install all dependencies including DPDK and other
>> libs”
>> 
>> $ make cross-env-update
>> 
>> updates cross-env to latest packages and ext-deps
>> 
>> $ make cross-shell
>> 
>> starts shell inside cross-env
>> 
>> $ make cross-package
>> 
>> builds VPP and creates packages:
>> 
>> ls -la build/ubuntu-18.04-x86_64-release total 11716
>> drwxr-xr-x  3 root root4096 Oct 31 17:30 .
>> drwxrwxr-x  4 damarion damarion4096 Oct 31 17:36 ..
>> drwxr-xr-x 22 root root4096 Oct 31 17:30 build
>> -rw-r--r--  1 root root  190124 Oct 31 17:30 libvppinfra_20.01-
>> rc0~555-g7f980bcfe_amd64.deb
>> -rw-r--r--  1 root root  145056 Oct 31 17:30 
>> libvppinfra-dev_20.01-
>> rc0~555-g7f980bcfe_amd64.deb
>> -rw-r--r--  1 root root   23140 Oct 31 17:30 
>> python3-vpp-api_20.01-
>> rc0~555-g7f980bcfe_amd64.deb
>> -rw-r--r--  1 root root8815 Oct 31 17:30 vpp_20.01-rc0~555-
>> g7f980bcfe_amd64.buildinfo
>> -rw-r--r--  1 root root4147 Oct 31 17:30 vpp_20.01-rc0~555-
>> g7f980bcfe_amd64.changes
>> -rw-r--r--  1 root root 3674024 Oct 31 17:30 vpp_20.01-rc0~555-
>> g7f980bcfe_amd64.deb
>> -rw-r--r--  1 root root   23104 Oct 31 17:30 
>> vpp-api-python_20.01-
>> rc0~555-g7f980bcfe_amd64.deb
>> -rw-r--r--  1 root root  719712 Oct 31 17:30 
>> 

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

[Dave Barach via Lists.Fd.Io]

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

From: vpp-dev@lists.fd.io  On Behalf Of Balaji Venkatraman 
via Lists.Fd.Io
Sent: Thursday, October 31, 2019 12:21 PM
To: Aleksander Djuric ; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] event-logger output format

Do you think it would be prudent to publish a ‘warning’ message on its impact 
on packet forwarding when this cmd is used?

Thanks!

--
Regards,
Balaji.


From: mailto:vpp-dev@lists.fd.io>> on behalf of Aleksander 
Djuric mailto:aleksander.dju...@gmail.com>>
Date: Thursday, October 31, 2019 at 8:07 AM
To: "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] event-logger output format

Hi Dave, Thanks!

Now it looks like this:
> show event-logger [all] [] [delta|no-delta|date-time]

Updated patch:
https://gerrit.fd.io/r/c/vpp/+/23146


On Thu, Oct 31, 2019 at 04:47 PM, Dave Barach wrote:

Yes, we see things differently. I never look at elog data in the debug CLI. I 
save the data and deal with it offline. See 
https://fd.io/docs/vpp/master/gettingstarted/developers/eventviewer.html. We 
often use elog buffer sizes measured in millions of events. The offline tools 
are happy to deal with 1e7 events.



Packet processing comes to a screeching halt while the “show event-logger” 
debug CLI command runs. If folks decide that it’s worth trying to use the “show 
event-logger” debug CLI on a regular basis, the first step should be to make 
and mark the debug CLI command thread-safe. At least when using one or more 
worker threads, packet processing won’t stop in its tracks for the duration...



I would prefer something of the form “show event-logger ... [full-timestamp]” 
to request date/hms/msusns timestamps, and I would prefer the delta format I 
described to tagging each event with a full timestamp. Maybe add 
“[delta|no-delta]” qualifier keywords to the debug CLI command.



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

View/Reply Online (#14439): https://lists.fd.io/g/vpp-dev/message/14439
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: [vpp-dev] cross-compilation support

[Damjan Marion via Lists.Fd.Io]

I slightly modified my patch, so it builds both native packages and cross 
packages out of same makefile.

Native:

$ make pkg
$ ls -la build/native-release
total 99352
drwxrwxr-x  3 damarion damarion 4096 Oct 31 20:00 .
drwxrwxr-x 10 damarion damarion 4096 Oct 31 19:55 ..
drwxrwxr-x 22 damarion damarion 4096 Oct 31 19:59 build
-rw-r--r--  1 damarion damarion   189752 Oct 31 20:00 
libvppinfra_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 damarion damarion   145048 Oct 31 20:00 
libvppinfra-dev_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 damarion damarion23156 Oct 31 20:00 
python3-vpp-api_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-rw-r--  1 damarion damarion10397 Oct 31 20:00 
vpp_20.01-rc0~552-g4e41baf9a_amd64.buildinfo
-rw-rw-r--  1 damarion damarion 4156 Oct 31 20:00 
vpp_20.01-rc0~552-g4e41baf9a_amd64.changes
-rw-r--r--  1 damarion damarion  3671292 Oct 31 20:00 
vpp_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 damarion damarion23104 Oct 31 20:00 
vpp-api-python_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 damarion damarion 90644784 Oct 31 20:00 
vpp-dbg_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 damarion damarion   915336 Oct 31 20:00 
vpp-dev_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 damarion damarion  3043184 Oct 31 20:00 
vpp-plugin-core_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 damarion damarion  3024568 Oct 31 20:00 
vpp-plugin-dpdk_20.01-rc0~552-g4e41baf9a_amd64.deb


Then on the same system, which is ubuntu 19.10, building for 18.04:

$ make TARGET_DISTRO_VER=18.04 cross-env-init
$ make TARGET_DISTRO_VER=18.04 pkg
$ ls -la build/ubuntu-18.04-x86_64-generic-release
total 77796
drwxrwxr-x  3 damarion damarion 4096 Oct 31 20:06 .
drwxrwxr-x  4 damarion damarion 4096 Oct 31 20:05 ..
drwxrwxr-x 22 damarion damarion 4096 Oct 31 20:05 build
-rw-r--r--  1 root root   201324 Oct 31 20:05 
libvppinfra_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 root root   145068 Oct 31 20:05 
libvppinfra-dev_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 root root23140 Oct 31 20:05 
python3-vpp-api_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 root root 8821 Oct 31 20:06 
vpp_20.01-rc0~552-g4e41baf9a_amd64.buildinfo
-rw-r--r--  1 root root 4153 Oct 31 20:06 
vpp_20.01-rc0~552-g4e41baf9a_amd64.changes
-rw-r--r--  1 root root  3479284 Oct 31 20:05 
vpp_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 root root23100 Oct 31 20:05 
vpp-api-python_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 root root 68758448 Oct 31 20:06 
vpp-dbg_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 root root   915508 Oct 31 20:05 
vpp-dev_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 root root  2952812 Oct 31 20:05 
vpp-plugin-core_20.01-rc0~552-g4e41baf9a_amd64.deb
-rw-r--r--  1 root root  3115612 Oct 31 20:05 
vpp-plugin-dpdk_20.01-rc0~552-g4e41baf9a_amd64.deb 


> On 31 Oct 2019, at 17:45, Damjan Marion  wrote:
> 
> 
> So what people think about following approach for cross-compilation:
> 
> Patch: https://gerrit.fd.io/r/c/vpp/+/23153 
> 
> 
> At the moment this is just to show idea, so it works only for x86-to-x86 and 
> between ubuntu versions only but it can be easily
> extended to scenarios like build vpp packages for AArch64 centos7 on ubuntu 
> x86 host.
> 
> export CROSS_DISTRO_NAME=ubuntu
> exprot CROSS_DISTRO_VER=18.04
> export CROSS_ARCH=x86_64
> export CROSS_TARGET=release
> 
> $ make cross-env-init
> 
> this is executed once, it creates docker container named 
> "vpp-dev-env-ubuntu-18.04-x86_64”, install all dependencies including DPDK 
> and other libs”
> 
> $ make cross-env-update
> 
> updates cross-env to latest packages and ext-deps
> 
> $ make cross-shell 
> 
> starts shell inside cross-env
> 
> $ make cross-package
> 
> builds VPP and creates packages:
> 
> ls -la build/ubuntu-18.04-x86_64-release
> total 11716
> drwxr-xr-x  3 root root4096 Oct 31 17:30 .
> drwxrwxr-x  4 damarion damarion4096 Oct 31 17:36 ..
> drwxr-xr-x 22 root root4096 Oct 31 17:30 build
> -rw-r--r--  1 root root  190124 Oct 31 17:30 
> libvppinfra_20.01-rc0~555-g7f980bcfe_amd64.deb
> -rw-r--r--  1 root root  145056 Oct 31 17:30 
> libvppinfra-dev_20.01-rc0~555-g7f980bcfe_amd64.deb
> -rw-r--r--  1 root root   23140 Oct 31 17:30 
> python3-vpp-api_20.01-rc0~555-g7f980bcfe_amd64.deb
> -rw-r--r--  1 root root8815 Oct 31 17:30 
> vpp_20.01-rc0~555-g7f980bcfe_amd64.buildinfo
> -rw-r--r--  1 root root4147 Oct 31 17:30 
> vpp_20.01-rc0~555-g7f980bcfe_amd64.changes
> -rw-r--r--  1 root root 3674024 Oct 31 17:30 
> vpp_20.01-rc0~555-g7f980bcfe_amd64.deb
> -rw-r--r--  1 root root   23104 Oct 31 17:30 
> vpp-api-python_20.01-rc0~555-g7f980bcfe_amd64.deb
> -rw-r--r--  1 root root  719712 Oct 31 17:30 
> 

Re: [vpp-dev] cross-compilation support

[Damjan Marion via Lists.Fd.Io]

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 require docker 
> and/or qemu for compiling an open source project.
> 
> Important in holding this opinion is that it's seems possible to make this 
> work w/o docker/qemu/root, I think someone just has to find the time to make 
> an acceptable to the project working patch.
> 
> I asked internally and it seems that our changes to support x-compile do not 
> go as far as producing debian/ubuntu packages, so they aren't ready for 
> upstreaming, unfortunately.
> 
> Thanks,
> Chris.
> 
>> On Oct 31, 2019, at 2:23 PM, Damjan Marion  wrote:
>> 
>> 
>> That is just copy paste from Ben’s command line.
>> 
>> As. i wrote, this is just about presenting the concept...
>> 
>>> On 31 Oct 2019, at 18:39, Christian Hopps  wrote:
>>> 
>>> Requiring root privileges for building software is pretty atypical and 
>>> limiting, even for x-compiling.
>>> 
>>> Thanks,
>>> Chris.
>>> 
 On Oct 31, 2019, at 12:45 PM, Damjan Marion via Lists.Fd.Io 
  wrote:
 
 
 So what people think about following approach for cross-compilation:
 
 Patch: https://gerrit.fd.io/r/c/vpp/+/23153
 
 At the moment this is just to show idea, so it works only for x86-to-x86 
 and between ubuntu versions only but it can be easily
 extended to scenarios like build vpp packages for AArch64 centos7 on 
 ubuntu x86 host.
 
 export CROSS_DISTRO_NAME=ubuntu
 exprot CROSS_DISTRO_VER=18.04
 export CROSS_ARCH=x86_64
 export CROSS_TARGET=release
 
 $ make cross-env-init
 
 this is executed once, it creates docker container named 
 "vpp-dev-env-ubuntu-18.04-x86_64”, install all dependencies including DPDK 
 and other libs”
 
 $ make cross-env-update
 
 updates cross-env to latest packages and ext-deps
 
 $ make cross-shell 
 
 starts shell inside cross-env
 
 $ make cross-package
 
 builds VPP and creates packages:
 
 ls -la build/ubuntu-18.04-x86_64-release
 total 11716
 drwxr-xr-x  3 root root4096 Oct 31 17:30 .
 drwxrwxr-x  4 damarion damarion4096 Oct 31 17:36 ..
 drwxr-xr-x 22 root root4096 Oct 31 17:30 build
 -rw-r--r--  1 root root  190124 Oct 31 17:30 
 libvppinfra_20.01-rc0~555-g7f980bcfe_amd64.deb
 -rw-r--r--  1 root root  145056 Oct 31 17:30 
 libvppinfra-dev_20.01-rc0~555-g7f980bcfe_amd64.deb
 -rw-r--r--  1 root root   23140 Oct 31 17:30 
 python3-vpp-api_20.01-rc0~555-g7f980bcfe_amd64.deb
 -rw-r--r--  1 root root8815 Oct 31 17:30 
 vpp_20.01-rc0~555-g7f980bcfe_amd64.buildinfo
 -rw-r--r--  1 root root4147 Oct 31 17:30 
 vpp_20.01-rc0~555-g7f980bcfe_amd64.changes
 -rw-r--r--  1 root root 3674024 Oct 31 17:30 
 vpp_20.01-rc0~555-g7f980bcfe_amd64.deb
 -rw-r--r--  1 root root   23104 Oct 31 17:30 
 vpp-api-python_20.01-rc0~555-g7f980bcfe_amd64.deb
 -rw-r--r--  1 root root  719712 Oct 31 17:30 
 vpp-dbg_20.01-rc0~555-g7f980bcfe_amd64.deb
 -rw-r--r--  1 root root  915744 Oct 31 17:30 
 vpp-dev_20.01-rc0~555-g7f980bcfe_amd64.deb
 -rw-r--r--  1 root root 3113820 Oct 31 17:30 
 vpp-plugin-core_20.01-rc0~555-g7f980bcfe_amd64.deb
 -rw-r--r--  1 root root 3144784 Oct 31 17:30 
 vpp-plugin-dpdk_20.01-rc0~555-g7f980bcfe_amd64.deb
 
 
 
 
 
 -=-=-=-=-=-=-=-=-=-=-=-
 Links: You receive all messages sent to this group.
 
 View/Reply Online (#14428): https://lists.fd.io/g/vpp-dev/message/14428
 Mute This Topic: https://lists.fd.io/mt/40199795/1826170
 Group Owner: vpp-dev+ow...@lists.fd.io
 Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [cho...@chopps.org]
 -=-=-=-=-=-=-=-=-=-=-=-
>>> 
>> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#14434): https://lists.fd.io/g/vpp-dev/message/14434
> Mute This Topic: https://lists.fd.io/mt/40199795/675642
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dmar...@me.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#14436): https://lists.fd.io/g/vpp-dev/message/14436

Re: [vpp-dev] Centos 8 and python scripts

[Renato Botelho do Couto via Lists.Fd.Io]

On 31/10/19 13:28, Renato Botelho do Couto wrote:
> On 31/10/19 13:17, Paul Vinciguerra wrote:
>> Speaking for myself only, I would prefer that we didn't introduce per
>> platform changes.  It would seem better to apply a single change that
>> makes it through the CI gates.
> 
> Right, I'll work on a patch changing all shebang lines to python3 and
> submit it before specific CentOS 8 changes.

Sent. https://gerrit.fd.io/r/c/vpp/+/23159

-- 
Renato Botelho do Couto
Software Engineer
Netgate
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[Christian Hopps]

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 require docker 
and/or qemu for compiling an open source project.

Important in holding this opinion is that it's seems possible to make this work 
w/o docker/qemu/root, I think someone just has to find the time to make an 
acceptable to the project working patch.

I asked internally and it seems that our changes to support x-compile do not go 
as far as producing debian/ubuntu packages, so they aren't ready for 
upstreaming, unfortunately.

Thanks,
Chris.

> On Oct 31, 2019, at 2:23 PM, Damjan Marion  wrote:
> 
> 
> That is just copy paste from Ben’s command line.
> 
> As. i wrote, this is just about presenting the concept...
> 
>> On 31 Oct 2019, at 18:39, Christian Hopps  wrote:
>> 
>> Requiring root privileges for building software is pretty atypical and 
>> limiting, even for x-compiling.
>> 
>> Thanks,
>> Chris.
>> 
>>> On Oct 31, 2019, at 12:45 PM, Damjan Marion via Lists.Fd.Io 
>>>  wrote:
>>> 
>>> 
>>> So what people think about following approach for cross-compilation:
>>> 
>>> Patch: https://gerrit.fd.io/r/c/vpp/+/23153
>>> 
>>> At the moment this is just to show idea, so it works only for x86-to-x86 
>>> and between ubuntu versions only but it can be easily
>>> extended to scenarios like build vpp packages for AArch64 centos7 on ubuntu 
>>> x86 host.
>>> 
>>> export CROSS_DISTRO_NAME=ubuntu
>>> exprot CROSS_DISTRO_VER=18.04
>>> export CROSS_ARCH=x86_64
>>> export CROSS_TARGET=release
>>> 
>>> $ make cross-env-init
>>> 
>>> this is executed once, it creates docker container named 
>>> "vpp-dev-env-ubuntu-18.04-x86_64”, install all dependencies including DPDK 
>>> and other libs”
>>> 
>>> $ make cross-env-update
>>> 
>>> updates cross-env to latest packages and ext-deps
>>> 
>>> $ make cross-shell 
>>> 
>>> starts shell inside cross-env
>>> 
>>> $ make cross-package
>>> 
>>> builds VPP and creates packages:
>>> 
>>> ls -la build/ubuntu-18.04-x86_64-release
>>> total 11716
>>> drwxr-xr-x  3 root root4096 Oct 31 17:30 .
>>> drwxrwxr-x  4 damarion damarion4096 Oct 31 17:36 ..
>>> drwxr-xr-x 22 root root4096 Oct 31 17:30 build
>>> -rw-r--r--  1 root root  190124 Oct 31 17:30 
>>> libvppinfra_20.01-rc0~555-g7f980bcfe_amd64.deb
>>> -rw-r--r--  1 root root  145056 Oct 31 17:30 
>>> libvppinfra-dev_20.01-rc0~555-g7f980bcfe_amd64.deb
>>> -rw-r--r--  1 root root   23140 Oct 31 17:30 
>>> python3-vpp-api_20.01-rc0~555-g7f980bcfe_amd64.deb
>>> -rw-r--r--  1 root root8815 Oct 31 17:30 
>>> vpp_20.01-rc0~555-g7f980bcfe_amd64.buildinfo
>>> -rw-r--r--  1 root root4147 Oct 31 17:30 
>>> vpp_20.01-rc0~555-g7f980bcfe_amd64.changes
>>> -rw-r--r--  1 root root 3674024 Oct 31 17:30 
>>> vpp_20.01-rc0~555-g7f980bcfe_amd64.deb
>>> -rw-r--r--  1 root root   23104 Oct 31 17:30 
>>> vpp-api-python_20.01-rc0~555-g7f980bcfe_amd64.deb
>>> -rw-r--r--  1 root root  719712 Oct 31 17:30 
>>> vpp-dbg_20.01-rc0~555-g7f980bcfe_amd64.deb
>>> -rw-r--r--  1 root root  915744 Oct 31 17:30 
>>> vpp-dev_20.01-rc0~555-g7f980bcfe_amd64.deb
>>> -rw-r--r--  1 root root 3113820 Oct 31 17:30 
>>> vpp-plugin-core_20.01-rc0~555-g7f980bcfe_amd64.deb
>>> -rw-r--r--  1 root root 3144784 Oct 31 17:30 
>>> vpp-plugin-dpdk_20.01-rc0~555-g7f980bcfe_amd64.deb
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Links: You receive all messages sent to this group.
>>> 
>>> View/Reply Online (#14428): https://lists.fd.io/g/vpp-dev/message/14428
>>> Mute This Topic: https://lists.fd.io/mt/40199795/1826170
>>> Group Owner: vpp-dev+ow...@lists.fd.io
>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [cho...@chopps.org]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>> 
> 

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

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

[Damjan Marion via Lists.Fd.Io]

That is just copy paste from Ben’s command line.

As. i wrote, this is just about presenting the concept...

> On 31 Oct 2019, at 18:39, Christian Hopps  wrote:
> 
> Requiring root privileges for building software is pretty atypical and 
> limiting, even for x-compiling.
> 
> Thanks,
> Chris.
> 
>> On Oct 31, 2019, at 12:45 PM, Damjan Marion via Lists.Fd.Io 
>>  wrote:
>> 
>> 
>> So what people think about following approach for cross-compilation:
>> 
>> Patch: https://gerrit.fd.io/r/c/vpp/+/23153
>> 
>> At the moment this is just to show idea, so it works only for x86-to-x86 and 
>> between ubuntu versions only but it can be easily
>> extended to scenarios like build vpp packages for AArch64 centos7 on ubuntu 
>> x86 host.
>> 
>> export CROSS_DISTRO_NAME=ubuntu
>> exprot CROSS_DISTRO_VER=18.04
>> export CROSS_ARCH=x86_64
>> export CROSS_TARGET=release
>> 
>> $ make cross-env-init
>> 
>> this is executed once, it creates docker container named 
>> "vpp-dev-env-ubuntu-18.04-x86_64”, install all dependencies including DPDK 
>> and other libs”
>> 
>> $ make cross-env-update
>> 
>> updates cross-env to latest packages and ext-deps
>> 
>> $ make cross-shell 
>> 
>> starts shell inside cross-env
>> 
>> $ make cross-package
>> 
>> builds VPP and creates packages:
>> 
>> ls -la build/ubuntu-18.04-x86_64-release
>> total 11716
>> drwxr-xr-x  3 root root4096 Oct 31 17:30 .
>> drwxrwxr-x  4 damarion damarion4096 Oct 31 17:36 ..
>> drwxr-xr-x 22 root root4096 Oct 31 17:30 build
>> -rw-r--r--  1 root root  190124 Oct 31 17:30 
>> libvppinfra_20.01-rc0~555-g7f980bcfe_amd64.deb
>> -rw-r--r--  1 root root  145056 Oct 31 17:30 
>> libvppinfra-dev_20.01-rc0~555-g7f980bcfe_amd64.deb
>> -rw-r--r--  1 root root   23140 Oct 31 17:30 
>> python3-vpp-api_20.01-rc0~555-g7f980bcfe_amd64.deb
>> -rw-r--r--  1 root root8815 Oct 31 17:30 
>> vpp_20.01-rc0~555-g7f980bcfe_amd64.buildinfo
>> -rw-r--r--  1 root root4147 Oct 31 17:30 
>> vpp_20.01-rc0~555-g7f980bcfe_amd64.changes
>> -rw-r--r--  1 root root 3674024 Oct 31 17:30 
>> vpp_20.01-rc0~555-g7f980bcfe_amd64.deb
>> -rw-r--r--  1 root root   23104 Oct 31 17:30 
>> vpp-api-python_20.01-rc0~555-g7f980bcfe_amd64.deb
>> -rw-r--r--  1 root root  719712 Oct 31 17:30 
>> vpp-dbg_20.01-rc0~555-g7f980bcfe_amd64.deb
>> -rw-r--r--  1 root root  915744 Oct 31 17:30 
>> vpp-dev_20.01-rc0~555-g7f980bcfe_amd64.deb
>> -rw-r--r--  1 root root 3113820 Oct 31 17:30 
>> vpp-plugin-core_20.01-rc0~555-g7f980bcfe_amd64.deb
>> -rw-r--r--  1 root root 3144784 Oct 31 17:30 
>> vpp-plugin-dpdk_20.01-rc0~555-g7f980bcfe_amd64.deb
>> 
>> 
>> 
>> 
>> 
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#14428): https://lists.fd.io/g/vpp-dev/message/14428
>> Mute This Topic: https://lists.fd.io/mt/40199795/1826170
>> Group Owner: vpp-dev+ow...@lists.fd.io
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [cho...@chopps.org]
>> -=-=-=-=-=-=-=-=-=-=-=-
> 

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

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

[vpp-dev] RDMA fix needed in 19.08 also

[Elias Rudberg]

It seems like the rdma plugin is currently not working in the
stable/1908 branch. It stopped working after commit b4c5f16889.

In the master branch, the rdma plugin stopped working in commit
534de8b2a7 but started working again after the fix in commit 386ebb6e2b
with commit message "rdma: build: fix ibverb compilation test".

To make rdma work again in the stable/1908 branch, I think the fix
386ebb6e2b "rdma: build: fix ibverb compilation test" would be needed
in that branch also. The change is quite small, only a few lines in the
file src/plugins/rdma/CMakeLists.txt. Can that change be applied in the
stable/1908 branch?

Best regards,
Elias

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

View/Reply Online (#14432): https://lists.fd.io/g/vpp-dev/message/14432
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] Centos 8 and python scripts

[Renato Botelho do Couto via Lists.Fd.Io]

On 31/10/19 13:39, Andrew  Yourtchenko wrote:
> Renato,
> 
> For my own curiosity sake - would you have a minute to try the following
> patch and instructions within it and tell the result ?

There is a list of good/bad shebangs used by brp-mangle-shebangs script.
 This custom shebang line is not there so it will ignore it.

-- 
Renato Botelho do Couto
Software Engineer
Netgate
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[Christian Hopps]

Requiring root privileges for building software is pretty atypical and 
limiting, even for x-compiling.

Thanks,
Chris.

> On Oct 31, 2019, at 12:45 PM, Damjan Marion via Lists.Fd.Io 
>  wrote:
> 
> 
> So what people think about following approach for cross-compilation:
> 
> Patch: https://gerrit.fd.io/r/c/vpp/+/23153
> 
> At the moment this is just to show idea, so it works only for x86-to-x86 and 
> between ubuntu versions only but it can be easily
> extended to scenarios like build vpp packages for AArch64 centos7 on ubuntu 
> x86 host.
> 
> export CROSS_DISTRO_NAME=ubuntu
> exprot CROSS_DISTRO_VER=18.04
> export CROSS_ARCH=x86_64
> export CROSS_TARGET=release
> 
> $ make cross-env-init
> 
> this is executed once, it creates docker container named 
> "vpp-dev-env-ubuntu-18.04-x86_64”, install all dependencies including DPDK 
> and other libs”
> 
> $ make cross-env-update
> 
> updates cross-env to latest packages and ext-deps
> 
> $ make cross-shell 
> 
> starts shell inside cross-env
> 
> $ make cross-package
> 
> builds VPP and creates packages:
> 
> ls -la build/ubuntu-18.04-x86_64-release
> total 11716
> drwxr-xr-x  3 root root4096 Oct 31 17:30 .
> drwxrwxr-x  4 damarion damarion4096 Oct 31 17:36 ..
> drwxr-xr-x 22 root root4096 Oct 31 17:30 build
> -rw-r--r--  1 root root  190124 Oct 31 17:30 
> libvppinfra_20.01-rc0~555-g7f980bcfe_amd64.deb
> -rw-r--r--  1 root root  145056 Oct 31 17:30 
> libvppinfra-dev_20.01-rc0~555-g7f980bcfe_amd64.deb
> -rw-r--r--  1 root root   23140 Oct 31 17:30 
> python3-vpp-api_20.01-rc0~555-g7f980bcfe_amd64.deb
> -rw-r--r--  1 root root8815 Oct 31 17:30 
> vpp_20.01-rc0~555-g7f980bcfe_amd64.buildinfo
> -rw-r--r--  1 root root4147 Oct 31 17:30 
> vpp_20.01-rc0~555-g7f980bcfe_amd64.changes
> -rw-r--r--  1 root root 3674024 Oct 31 17:30 
> vpp_20.01-rc0~555-g7f980bcfe_amd64.deb
> -rw-r--r--  1 root root   23104 Oct 31 17:30 
> vpp-api-python_20.01-rc0~555-g7f980bcfe_amd64.deb
> -rw-r--r--  1 root root  719712 Oct 31 17:30 
> vpp-dbg_20.01-rc0~555-g7f980bcfe_amd64.deb
> -rw-r--r--  1 root root  915744 Oct 31 17:30 
> vpp-dev_20.01-rc0~555-g7f980bcfe_amd64.deb
> -rw-r--r--  1 root root 3113820 Oct 31 17:30 
> vpp-plugin-core_20.01-rc0~555-g7f980bcfe_amd64.deb
> -rw-r--r--  1 root root 3144784 Oct 31 17:30 
> vpp-plugin-dpdk_20.01-rc0~555-g7f980bcfe_amd64.deb
> 
> 
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#14428): https://lists.fd.io/g/vpp-dev/message/14428
> Mute This Topic: https://lists.fd.io/mt/40199795/1826170
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [cho...@chopps.org]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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

[Damjan Marion via Lists.Fd.Io]

$ git grep -h -B20 VLIB_NODE_FLAG_TRACE_SUPPORTED | grep VLIB_REGISTER_NODE
VLIB_REGISTER_NODE (avf_input_node) = {
VLIB_REGISTER_NODE (dpdk_input_node) = {
VLIB_REGISTER_NODE (dpdk_crypto_input_node) =
VLIB_REGISTER_NODE (ixge_input_node, static) = {
VLIB_REGISTER_NODE (mrvl_pp2_input_node) = {
VLIB_REGISTER_NODE (memif_input_node) = {
VLIB_REGISTER_NODE (rdma_input_node) = {
VLIB_REGISTER_NODE (vmxnet3_input_node) = {
VLIB_REGISTER_NODE (handoff_trace_node, static) =
VLIB_REGISTER_NODE (bond_process_node) = {
VLIB_REGISTER_NODE (af_packet_input_node) = {
VLIB_REGISTER_NODE (netmap_input_node) = {
VLIB_REGISTER_NODE (virtio_input_node) = {
VLIB_REGISTER_NODE (vhost_user_input_node) = {
VLIB_REGISTER_NODE (p2p_ethernet_input_node) = {
VLIB_REGISTER_NODE (punt_socket_rx_node) =
VLIB_REGISTER_NODE (pg_input_node) = {
VLIB_REGISTER_NODE (session_queue_node) =
VLIB_REGISTER_NODE (tuntap_rx_node,static) = {


> On 31 Oct 2019, at 16:45, Paul Vinciguerra  wrote:
> 
> Is there some simple way to identify the nodes that are supported under trace 
> add?
> 
> 
> trace add: node 'ethernet-input' doesn't support per-node tracing. 
> There may be another way to initiate trace on this node.
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#14421): https://lists.fd.io/g/vpp-dev/message/14421
> Mute This Topic: https://lists.fd.io/mt/40184863/675642
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dmar...@me.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

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

[vpp-dev] cross-compilation support

[Damjan Marion via Lists.Fd.Io]

So what people think about following approach for cross-compilation:

Patch: https://gerrit.fd.io/r/c/vpp/+/23153 


At the moment this is just to show idea, so it works only for x86-to-x86 and 
between ubuntu versions only but it can be easily
extended to scenarios like build vpp packages for AArch64 centos7 on ubuntu x86 
host.

export CROSS_DISTRO_NAME=ubuntu
exprot CROSS_DISTRO_VER=18.04
export CROSS_ARCH=x86_64
export CROSS_TARGET=release

$ make cross-env-init

this is executed once, it creates docker container named 
"vpp-dev-env-ubuntu-18.04-x86_64”, install all dependencies including DPDK and 
other libs”

$ make cross-env-update

updates cross-env to latest packages and ext-deps

$ make cross-shell 

starts shell inside cross-env

$ make cross-package

builds VPP and creates packages:

ls -la build/ubuntu-18.04-x86_64-release
total 11716
drwxr-xr-x  3 root root4096 Oct 31 17:30 .
drwxrwxr-x  4 damarion damarion4096 Oct 31 17:36 ..
drwxr-xr-x 22 root root4096 Oct 31 17:30 build
-rw-r--r--  1 root root  190124 Oct 31 17:30 
libvppinfra_20.01-rc0~555-g7f980bcfe_amd64.deb
-rw-r--r--  1 root root  145056 Oct 31 17:30 
libvppinfra-dev_20.01-rc0~555-g7f980bcfe_amd64.deb
-rw-r--r--  1 root root   23140 Oct 31 17:30 
python3-vpp-api_20.01-rc0~555-g7f980bcfe_amd64.deb
-rw-r--r--  1 root root8815 Oct 31 17:30 
vpp_20.01-rc0~555-g7f980bcfe_amd64.buildinfo
-rw-r--r--  1 root root4147 Oct 31 17:30 
vpp_20.01-rc0~555-g7f980bcfe_amd64.changes
-rw-r--r--  1 root root 3674024 Oct 31 17:30 
vpp_20.01-rc0~555-g7f980bcfe_amd64.deb
-rw-r--r--  1 root root   23104 Oct 31 17:30 
vpp-api-python_20.01-rc0~555-g7f980bcfe_amd64.deb
-rw-r--r--  1 root root  719712 Oct 31 17:30 
vpp-dbg_20.01-rc0~555-g7f980bcfe_amd64.deb
-rw-r--r--  1 root root  915744 Oct 31 17:30 
vpp-dev_20.01-rc0~555-g7f980bcfe_amd64.deb
-rw-r--r--  1 root root 3113820 Oct 31 17:30 
vpp-plugin-core_20.01-rc0~555-g7f980bcfe_amd64.deb
-rw-r--r--  1 root root 3144784 Oct 31 17:30 
vpp-plugin-dpdk_20.01-rc0~555-g7f980bcfe_amd64.deb





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

View/Reply Online (#14428): https://lists.fd.io/g/vpp-dev/message/14428
Mute This Topic: https://lists.fd.io/mt/40199795/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] Centos 8 and python scripts

[Andrew Yourtchenko]

Renato,

For my own curiosity sake - would you have a minute to try the following patch 
and instructions within it and tell the result ?

https://gerrit.fd.io/r/#/c/vpp/+/23152/

--a

> On 31 Oct 2019, at 17:28, Renato Botelho do Couto via Lists.Fd.Io 
>  wrote:
> 
> On 31/10/19 13:17, Paul Vinciguerra wrote:
>> Speaking for myself only, I would prefer that we didn't introduce per
>> platform changes.  It would seem better to apply a single change that
>> makes it through the CI gates.
> 
> Right, I'll work on a patch changing all shebang lines to python3 and
> submit it before specific CentOS 8 changes.
> 
> -- 
> Renato Botelho do Couto
> Software Engineer
> Netgate
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#14426): https://lists.fd.io/g/vpp-dev/message/14426
> Mute This Topic: https://lists.fd.io/mt/40145444/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 (#14427): https://lists.fd.io/g/vpp-dev/message/14427
Mute This Topic: https://lists.fd.io/mt/40145444/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] Centos 8 and python scripts

[Renato Botelho do Couto via Lists.Fd.Io]

On 31/10/19 13:17, Paul Vinciguerra wrote:
> Speaking for myself only, I would prefer that we didn't introduce per
> platform changes.  It would seem better to apply a single change that
> makes it through the CI gates.

Right, I'll work on a patch changing all shebang lines to python3 and
submit it before specific CentOS 8 changes.

-- 
Renato Botelho do Couto
Software Engineer
Netgate
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[Balaji Venkatraman via Lists.Fd.Io]

Do you think it would be prudent to publish a ‘warning’ message on its impact 
on packet forwarding when this cmd is used?

Thanks!

--
Regards,
Balaji.


From:  on behalf of Aleksander Djuric 

Date: Thursday, October 31, 2019 at 8:07 AM
To: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] event-logger output format

Hi Dave, Thanks!

Now it looks like this:
> show event-logger [all] [] [delta|no-delta|date-time]

Updated patch:
https://gerrit.fd.io/r/c/vpp/+/23146


On Thu, Oct 31, 2019 at 04:47 PM, Dave Barach wrote:

Yes, we see things differently. I never look at elog data in the debug CLI. I 
save the data and deal with it offline. See 
https://fd.io/docs/vpp/master/gettingstarted/developers/eventviewer.html. We 
often use elog buffer sizes measured in millions of events. The offline tools 
are happy to deal with 1e7 events.



Packet processing comes to a screeching halt while the “show event-logger” 
debug CLI command runs. If folks decide that it’s worth trying to use the “show 
event-logger” debug CLI on a regular basis, the first step should be to make 
and mark the debug CLI command thread-safe. At least when using one or more 
worker threads, packet processing won’t stop in its tracks for the duration...



I would prefer something of the form “show event-logger ... [full-timestamp]” 
to request date/hms/msusns timestamps, and I would prefer the delta format I 
described to tagging each event with a full timestamp. Maybe add 
“[delta|no-delta]” qualifier keywords to the debug CLI command.



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

View/Reply Online (#14425): https://lists.fd.io/g/vpp-dev/message/14425
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: [vpp-dev] Centos 8 and python scripts

[Paul Vinciguerra]

Speaking for myself only, I would prefer that we didn't introduce per
platform changes.  It would seem better to apply a single change that makes
it through the CI gates.

Is it time for a (non-voting) Centos8 CI job?

On Thu, Oct 31, 2019 at 12:06 PM Renato Botelho do Couto 
wrote:

> On 31/10/19 11:09, Paul Vinciguerra wrote:
> > I am aware of the issue.  I would suggest changing them all to python3.
> > We can work through any issues that arise after the code passes the CI
> > gates.  Most of those shebangs are in place for developers using make
> > test-shell, which could be evoking the script via 'python2 '
>
> Since I don't want to break other platforms my idea is to add sed call
> to build/external/rpm/vpp-ext-deps.spec to replace shebang lines that
> are affecting package build only if it's a CentOS 8.
>
> If you say it's acceptable I'll submit a patch.
>
> --
> Renato Botelho do Couto
> Software Engineer
> Netgate
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14424): https://lists.fd.io/g/vpp-dev/message/14424
Mute This Topic: https://lists.fd.io/mt/40145444/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] Centos 8 and python scripts

[Renato Botelho do Couto via Lists.Fd.Io]

On 31/10/19 11:09, Paul Vinciguerra wrote:
> I am aware of the issue.  I would suggest changing them all to python3. 
> We can work through any issues that arise after the code passes the CI
> gates.  Most of those shebangs are in place for developers using make
> test-shell, which could be evoking the script via 'python2 '

Since I don't want to break other platforms my idea is to add sed call
to build/external/rpm/vpp-ext-deps.spec to replace shebang lines that
are affecting package build only if it's a CentOS 8.

If you say it's acceptable I'll submit a patch.

-- 
Renato Botelho do Couto
Software Engineer
Netgate
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[Andrew Yourtchenko]

grep for VLIB_NODE_FLAG_TRACE_SUPPORTED

Cf: Damjan’s commit 29dc11bd

--a

> On 31 Oct 2019, at 16:45, Paul Vinciguerra  wrote:
> 
> 
> Is there some simple way to identify the nodes that are supported under trace 
> add?
> 
> 
> trace add: node 'ethernet-input' doesn't support per-node tracing. 
> There may be another way to initiate trace on this node.
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#14421): https://lists.fd.io/g/vpp-dev/message/14421
> Mute This Topic: https://lists.fd.io/mt/40184863/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 (#14422): https://lists.fd.io/g/vpp-dev/message/14422
Mute This Topic: https://lists.fd.io/mt/40184863/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] per-node tracing

[Paul Vinciguerra]

Is there some simple way to identify the nodes that are supported under trace 
add?

trace add: node 'ethernet-input' doesn't support per-node tracing.
There may be another way to initiate trace on this node.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14421): https://lists.fd.io/g/vpp-dev/message/14421
Mute This Topic: https://lists.fd.io/mt/40184863/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 high cpu usage problem?

[Florin Coras]

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

Sample output:

> 
> vpp# show event-logger 2
> 82 of 131072 events in buffer, logger running
> 19.946551561: api-msg: trace_plugin_msg_ids
> 19.946557011: api-msg-done(mp-safe): trace_plugin_msg_ids
> vpp# show event-logger 2 no-delta
> 82 of 131072 events in buffer, logger running
> 1572533201.2065280: api-msg: trace_plugin_msg_ids
> 1572533201.2065337: api-msg-done(mp-safe): trace_plugin_msg_ids
> vpp# show event-logger 2 date-time
> 82 of 131072 events in buffer, logger running
> 2019/10/31 17:46:41:207: api-msg: trace_plugin_msg_ids
> 2019/10/31 17:46:41:207: api-msg-done(mp-safe): trace_plugin_msg_ids
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14419): https://lists.fd.io/g/vpp-dev/message/14419
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: [vpp-dev] event-logger output format

[Aleksander Djuric]

Hi Dave, Thanks!

Now it looks like this:
> show event-logger [all] [] [delta|no-delta|date-time]

Updated patch:
https://gerrit.fd.io/r/c/vpp/+/23146

On Thu, Oct 31, 2019 at 04:47 PM, Dave Barach wrote:

> 
> 
> 
> Yes, we see things differently. I never look at elog data in the debug
> CLI. I save the data and deal with it offline. See 
> https://fd.io/docs/vpp/master/gettingstarted/developers/eventviewer.html
> ( https://fd.io/docs/vpp/master/gettingstarted/developers/eventviewer.html
> ). We often use elog buffer sizes measured in millions of events. The
> offline tools are happy to deal with 1e7 events.
> 
> 
> 
> 
> 
> 
> 
> Packet processing comes to a screeching halt while the “show event-logger”
> debug CLI command runs. If folks decide that it’s worth trying to use the
> “show event-logger” debug CLI on a regular basis, the first step should be
> to make and mark the debug CLI command thread-safe. At least when using
> one or more worker threads, packet processing won’t stop in its tracks for
> the duration...
> 
> 
> 
> 
> 
> 
> 
> I would prefer something of the form “show event-logger ...
> [full-timestamp]” to request date/hms/msusns timestamps, and I would
> prefer the delta format I described to tagging each event with a full
> timestamp. Maybe add “[delta|no-delta]” qualifier keywords to the debug
> CLI command.
> 
> 
> 
> 
> 
> 
> 
> FWIW... Dave
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14418): https://lists.fd.io/g/vpp-dev/message/14418
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: [vpp-dev] Centos 8 and python scripts

[Andrew Yourtchenko]

Why not delete them altogether then?

--a

> On 31 Oct 2019, at 15:09, Paul Vinciguerra  wrote:
> 
> 
> I am aware of the issue.  I would suggest changing them all to python3.  We 
> can work through any issues that arise after the code passes the CI gates.  
> Most of those shebangs are in place for developers using make test-shell, 
> which could be evoking the script via 'python2 '
> 
>> On Thu, Oct 31, 2019 at 9:46 AM Renato Botelho do Couto via Lists.Fd.Io 
>>  wrote:
>> I've been working to build VPP on CentOS 8 and rpmbuild is complaining
>> about using '#!/usr/bin/env python' or '#!/usr/bin/python' on scripts'
>> shebang line.  It says it must to define explicitly if it's using
>> python2 or python3.
>> 
>> # git grep 'env python$' | wc -l
>> 117
>> 
>> There are several scripts with this invalid shebang line and I'm not
>> sure about what to do with them.  Could you give me some help about how
>> to proceed with it?
>> 
>> Thanks!
>> -- 
>> Renato Botelho do Couto
>> Software Engineer
>> Netgate
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> 
>> View/Reply Online (#14414): https://lists.fd.io/g/vpp-dev/message/14414
>> Mute This Topic: https://lists.fd.io/mt/40145444/1594641
>> Group Owner: vpp-dev+ow...@lists.fd.io
>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
>> [pvi...@vinciconsulting.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#14416): https://lists.fd.io/g/vpp-dev/message/14416
> Mute This Topic: https://lists.fd.io/mt/40145444/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 (#14417): https://lists.fd.io/g/vpp-dev/message/14417
Mute This Topic: https://lists.fd.io/mt/40145444/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] Centos 8 and python scripts

[Paul Vinciguerra]

I am aware of the issue.  I would suggest changing them all to python3.  We
can work through any issues that arise after the code passes the CI gates.
Most of those shebangs are in place for developers using make test-shell,
which could be evoking the script via 'python2 '

On Thu, Oct 31, 2019 at 9:46 AM Renato Botelho do Couto via Lists.Fd.Io
 wrote:

> I've been working to build VPP on CentOS 8 and rpmbuild is complaining
> about using '#!/usr/bin/env python' or '#!/usr/bin/python' on scripts'
> shebang line.  It says it must to define explicitly if it's using
> python2 or python3.
>
> # git grep 'env python$' | wc -l
> 117
>
> There are several scripts with this invalid shebang line and I'm not
> sure about what to do with them.  Could you give me some help about how
> to proceed with it?
>
> Thanks!
> --
> Renato Botelho do Couto
> Software Engineer
> Netgate
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#14414): https://lists.fd.io/g/vpp-dev/message/14414
> Mute This Topic: https://lists.fd.io/mt/40145444/1594641
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [
> pvi...@vinciconsulting.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[Dave Barach via Lists.Fd.Io]

Yes, we see things differently. I never look at elog data in the debug CLI. I 
save the data and deal with it offline. See 
https://fd.io/docs/vpp/master/gettingstarted/developers/eventviewer.html. We 
often use elog buffer sizes measured in millions of events. The offline tools 
are happy to deal with 1e7 events.

Packet processing comes to a screeching halt while the “show event-logger” 
debug CLI command runs. If folks decide that it’s worth trying to use the “show 
event-logger” debug CLI on a regular basis, the first step should be to make 
and mark the debug CLI command thread-safe. At least when using one or more 
worker threads, packet processing won’t stop in its tracks for the duration...

I would prefer something of the form “show event-logger ... [full-timestamp]” 
to request date/hms/msusns timestamps, and I would prefer the delta format I 
described to tagging each event with a full timestamp. Maybe add 
“[delta|no-delta]” qualifier keywords to the debug CLI command.

FWIW... Dave


From: vpp-dev@lists.fd.io  On Behalf Of Aleksander Djuric
Sent: Thursday, October 31, 2019 8:42 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] event-logger output format

Hi Dave,

Thank you very much for your reply. I think it can be useful to discuss this 
patch here at first. As I see, we looks at these things little bit differently )
I'm use event-logger mostly for registering such fast events as ACL filter 
matching. I think that the human-readable format is better suitable for such 
purpose. Because for technical use you still can save elog file. Isn't it?
If I understand you correctly,  you suggest the case in which the both modes 
supported, maybe somethig like the following:

show event-logger [all] [] [detail] ?

where "detail" means show elog with nanoseconds timestamp. Would it be usefull?

Regards,

Aleksander

On Thu, Oct 31, 2019 at 02:48 PM, Dave Barach wrote:

Please see 
https://fd.io/docs/vpp/master/gettingstarted/developers/gitreview.html.



Event log entry timestamps have nanosecond granularity. It might work out to do 
something like the following:



2019/10/31 09:18:36:937:123:895   ## initial full timestamp

 +0: api-msg: trace_plugin_msg_ids

+1.2us: api-msg-done(mp-safe): trace_plugin_msg_ids

 +30us: api-msg: trace_plugin_msg_ids

+1.1us: api-msg-done(mp-safe): trace_plugin_msg_ids



If delta exceeds 100ms (or some such), emit another full timestamp.



This will reduce the average output width considerably, and reduce the 
subtrahend / minuend widths when asking questions of the form “how long does 
the XYZ API message handler take?”



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

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

[vpp-dev] Centos 8 and python scripts

[Renato Botelho do Couto via Lists.Fd.Io]

I've been working to build VPP on CentOS 8 and rpmbuild is complaining
about using '#!/usr/bin/env python' or '#!/usr/bin/python' on scripts'
shebang line.  It says it must to define explicitly if it's using
python2 or python3.

# git grep 'env python$' | wc -l
117

There are several scripts with this invalid shebang line and I'm not
sure about what to do with them.  Could you give me some help about how
to proceed with it?

Thanks!
-- 
Renato Botelho do Couto
Software Engineer
Netgate
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Can "use_mq_eventfd" solve epoll_wait high cpu usage problem?

[wanghanlin]

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 (>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/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] Change in vpp[master]: ebuild: Cross compilation aarch64 Ubuntu support

[Damjan Marion via Lists.Fd.Io]

> On 31 Oct 2019, at 13:18, Benoit Ganne (bganne)  wrote:
> 
>> I was going to remain silent, but since there's now multiple people saying
>> this sounds good -- I think this sounds horrible. :)
>> To wit, it seems too complex and too much setup/overhead. I'll try and
>> look closer at this soon to see if I can feed back our local changes that
>> seem to be working.
> 
> It is not that bad in my opinion [1] :
> 1) add support for multiarch (must be done once after reboot)
> ~# docker run --rm --privileged multiarch/qemu-user-static --reset 
> --persistent yes --credential yes
> 2) create your chroot (must be done once - I am sharing my homedir with my 
> chroot and same UID/GID)
> ~# docker run --name aarch64_u1804 --privileged --net host -v $HOME:$HOME -v 
> /dev:/dev -v/lib/modules:/lib/modules/host:ro -td arm64v8/ubuntu:18.04 
> /bin/bash
> ~# docker container exec aarch64_u1804 sh -c "apt -qy update && apt 
> dist-upgrade -qy && apt install -qy vim sudo make git && groupadd -g $(id 
> -rg) $USER && useradd -u $(id -ru) -g $(id -rg) -M -d $HOME -s /bin/bash 
> $USER && echo '$USER ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers && echo 
> aarch64_u1804 > /etc/debian_chroot"
> 3) compile vpp (I already checked out VPP in $HOME/src/vpp but you can 
> checkout it there too if you prefer)
> ~# docker container exec aarch64_u1804 su "$USER" -l -c "UNATTENTED=y make -C 
> src/vpp install-dep install-ext-deps pkg-deb"
> [...]
> dpkg-deb: building package 'libvppinfra-dev' in 
> '../libvppinfra-dev_20.01-rc0~538-gbb41ee925_arm64.deb'.
> dpkg-deb: building package 'vpp-dbg' in 
> '../vpp-dbg_20.01-rc0~538-gbb41ee925_arm64.deb'.
> dpkg-deb: building package 'libvppinfra' in 
> '../libvppinfra_20.01-rc0~538-gbb41ee925_arm64.deb'.
> dpkg-deb: building package 'vpp-api-python' in 
> '../vpp-api-python_20.01-rc0~538-gbb41ee925_arm64.deb'.
> dpkg-deb: building package 'vpp' in 
> '../vpp_20.01-rc0~538-gbb41ee925_arm64.deb'.
> dpkg-deb: building package 'vpp-plugin-dpdk' in 
> '../vpp-plugin-dpdk_20.01-rc0~538-gbb41ee925_arm64.deb'.
> dpkg-deb: building package 'python3-vpp-api' in 
> '../python3-vpp-api_20.01-rc0~538-gbb41ee925_arm64.deb'.
> dpkg-deb: building package 'vpp-dev' in 
> '../vpp-dev_20.01-rc0~538-gbb41ee925_arm64.deb'.
> dpkg-deb: building package 'vpp-plugin-core' in 
> '../vpp-plugin-core_20.01-rc0~538-gbb41ee925_arm64.deb'.
> make[2]: Leaving directory 
> '/home/bganne/src/vpp/build-root/build-vpp-native/vpp'
> dpkg-genbuildinfo --build=binary
> dpkg-genchanges --build=binary >../vpp_20.01-rc0~538-gbb41ee925_arm64.changes
> dpkg-genchanges: info: binary-only upload (no source code included)
> dpkg-source --after-build vpp
> dpkg-buildpackage: info: binary-only upload (no source included)
> make[1]: Leaving directory '/home/bganne/src/vpp/build-root'
> make: Leaving directory '/home/bganne/src/vpp'
> 
> Enjoy :)

This is so cool :) I wanted to invest time to investigate how to do exactly 
this, so thanks for saving my time 

Only nice thing will be to find way to run x86 version of  
aarch64-linux-gnu-gcc instead of aarch64 version of gcc so it runs faster…




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

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

Hi Dave,

Thank you very much for your reply. I think it can be useful to discuss this 
patch here at first. As I see, we looks at these things little bit differently )
I'm use event-logger mostly for registering such fast events as ACL filter 
matching. I think that the human-readable format is better suitable for such 
purpose. Because for technical use you still can save elog file. Isn't it?
If I understand you correctly,  you suggest the case in which the both modes 
supported, maybe somethig like the following:

show event-logger [all] [] [detail] ?

where "detail" means show elog with nanoseconds timestamp. Would it be usefull?

Regards,

Aleksander

On Thu, Oct 31, 2019 at 02:48 PM, Dave Barach wrote:

> 
> 
> 
> Please see 
> https://fd.io/docs/vpp/master/gettingstarted/developers/gitreview.html
> ( https://fd.io/docs/vpp/master/gettingstarted/developers/gitreview.html )
> .
> 
> 
> 
> 
> 
> 
> 
> Event log entry timestamps have nanosecond granularity. It might work out
> to do something like the following:
> 
> 
> 
> 
> 
> 
> 
> 2019/10/31 09:18:36:937:123:895   ## initial full timestamp
> 
> 
> 
> +0: api-msg: trace_plugin_msg_ids
> 
> 
> 
> +1.2us: api-msg-done(mp-safe): trace_plugin_msg_ids
> 
> 
> 
> +30us: api-msg: trace_plugin_msg_ids
> 
> 
> 
> +1.1us: api-msg-done(mp-safe): trace_plugin_msg_ids
> 
> 
> 
> 
> 
> 
> 
> If delta exceeds 100ms (or some such), emit another full timestamp.
> 
> 
> 
> 
> 
> 
> 
> This will reduce the average output width considerably, and reduce the
> subtrahend / minuend widths when asking questions of the form “how long
> does the XYZ API message handler take?”
> 
> 
> 
> 
> 
> 
> 
> FWIW... Dave
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14411): https://lists.fd.io/g/vpp-dev/message/14411
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: [vpp-dev] Change in vpp[master]: ebuild: Cross compilation aarch64 Ubuntu support

[Benoit Ganne (bganne) via Lists.Fd.Io]

> I was going to remain silent, but since there's now multiple people saying
> this sounds good -- I think this sounds horrible. :)
> To wit, it seems too complex and too much setup/overhead. I'll try and
> look closer at this soon to see if I can feed back our local changes that
> seem to be working.

It is not that bad in my opinion [1] :
 1) add support for multiarch (must be done once after reboot)
~# docker run --rm --privileged multiarch/qemu-user-static --reset --persistent 
yes --credential yes
 2) create your chroot (must be done once - I am sharing my homedir with my 
chroot and same UID/GID)
~# docker run --name aarch64_u1804 --privileged --net host -v $HOME:$HOME -v 
/dev:/dev -v/lib/modules:/lib/modules/host:ro -td arm64v8/ubuntu:18.04 /bin/bash
~# docker container exec aarch64_u1804 sh -c "apt -qy update && apt 
dist-upgrade -qy && apt install -qy vim sudo make git && groupadd -g $(id -rg) 
$USER && useradd -u $(id -ru) -g $(id -rg) -M -d $HOME -s /bin/bash $USER && 
echo '$USER ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers && echo aarch64_u1804 > 
/etc/debian_chroot"
 3) compile vpp (I already checked out VPP in $HOME/src/vpp but you can 
checkout it there too if you prefer)
~# docker container exec aarch64_u1804 su "$USER" -l -c "UNATTENTED=y make -C 
src/vpp install-dep install-ext-deps pkg-deb"
[...]
dpkg-deb: building package 'libvppinfra-dev' in 
'../libvppinfra-dev_20.01-rc0~538-gbb41ee925_arm64.deb'.
dpkg-deb: building package 'vpp-dbg' in 
'../vpp-dbg_20.01-rc0~538-gbb41ee925_arm64.deb'.
dpkg-deb: building package 'libvppinfra' in 
'../libvppinfra_20.01-rc0~538-gbb41ee925_arm64.deb'.
dpkg-deb: building package 'vpp-api-python' in 
'../vpp-api-python_20.01-rc0~538-gbb41ee925_arm64.deb'.
dpkg-deb: building package 'vpp' in '../vpp_20.01-rc0~538-gbb41ee925_arm64.deb'.
dpkg-deb: building package 'vpp-plugin-dpdk' in 
'../vpp-plugin-dpdk_20.01-rc0~538-gbb41ee925_arm64.deb'.
dpkg-deb: building package 'python3-vpp-api' in 
'../python3-vpp-api_20.01-rc0~538-gbb41ee925_arm64.deb'.
dpkg-deb: building package 'vpp-dev' in 
'../vpp-dev_20.01-rc0~538-gbb41ee925_arm64.deb'.
dpkg-deb: building package 'vpp-plugin-core' in 
'../vpp-plugin-core_20.01-rc0~538-gbb41ee925_arm64.deb'.
make[2]: Leaving directory 
'/home/bganne/src/vpp/build-root/build-vpp-native/vpp'
 dpkg-genbuildinfo --build=binary
 dpkg-genchanges --build=binary >../vpp_20.01-rc0~538-gbb41ee925_arm64.changes
dpkg-genchanges: info: binary-only upload (no source code included)
 dpkg-source --after-build vpp
dpkg-buildpackage: info: binary-only upload (no source included)
make[1]: Leaving directory '/home/bganne/src/vpp/build-root'
make: Leaving directory '/home/bganne/src/vpp'

Enjoy :)

ben

[1] https://github.com/multiarch/qemu-user-static/blob/master/README.md

> > On Oct 30, 2019, at 1:38 PM, Benoit Ganne (bganne) 
> wrote:
> >
> > Yeah I agree it is probably the best way to x-compile. x-compilation
> toolchain is a pain to use with a pile of corner-cases. Using qemu
> emulation, it just becomes native compilation again...
> >
> > ben
> >
> >> -Original Message-
> >> From: Damjan Marion 
> >> Sent: mercredi 30 octobre 2019 18:16
> >> To: Benoit Ganne (bganne) 
> >> Cc: Christian Hopps ; Stanislav Chlebec
> >> ; vpp-dev@lists.fd.io
> >> Subject: Re: [vpp-dev] Change in vpp[master]: ebuild: Cross compilation
> >> aarch64 Ubuntu support
> >>
> >>
> >>On 30 Oct 2019, at 16:56, Benoit Ganne (bganne)  >>  > wrote:
> >>
> >>I used qemu + chroot + Linux binfmt support with great success for
> >> x-compilation, such as described here:
> >> https://wiki.ubuntu.com/UbuntuDevelopment/Ports
> >>
> >>The basic steps are:
> >>- prepare a chroot mirroring your target (eg. using debootstrap)
> >>- setup Linux binfmt to call qemu-arm-static for ARM binaries and
> >> copy qemu-arm-static into the chroot
> >>- chroot
> >>- compile as usual
> >>
> >>The magic is the kernel will automatically call qemu-arm-static each
> >> time you try to run an ARM binary, so you transparently execute ARM
> >> binaries on your x86 host. That will probably not work to run a full-
> >> fledge VPP but it usually works great for compilation.
> >>
> >>I guess that's what Damjan refers to?
> >>
> >>
> >>
> >> exactly :)
> >>
> >>
> >>
> >>
> >>ben
> >>
> >>
> >>
> >>-Original Message-
> >>From: vpp-dev@lists.fd.io    >> d...@lists.fd.io  > On Behalf Of Christian
> >>Hopps
> >>Sent: mercredi 30 octobre 2019 16:48
> >>To: Damjan Marion mailto:dmar...@me.com> >
> >>Cc: Christian Hopps  >>  >; Stanislav Chlebec
> >> >>  >; vpp-dev@lists.fd.io
> >> 
> >>Subject: Re: [vpp-dev] Change in vpp[master]: ebuild: Cross
> >> compilation
> >>aarch64 Ubuntu 

[vpp-dev] mildly off-topic: non-member posts to vpp dev list

[Dave Barach via Lists.Fd.Io]

Folks,

Behind the scenes, the vpp dev mailing list receives a lot of spam from 
non-list-member accounts. I delete them from the moderation queue periodically, 
roughly twice a week.

At cleanup time, legitimate emails stuck in the moderation queue will appear on 
the dev list. Anyone who might read this email is encouraged to join the dev 
list, to avoid having message stuck in the moderation queue for several days.

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

View/Reply Online (#14409): https://lists.fd.io/g/vpp-dev/message/14409
Mute This Topic: https://lists.fd.io/mt/40109730/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] how to update openssl in the vpp

[zhangsh...@chinatelecom.cn]

Thank you very much for your reply:
Our system uses centos7, vpp-based ipsec wants to use the encryption 
algorithm sm4.
but the current centos7 openssl version 1.0.2k, but the sm4 algorithm is in the 
higher openssl version 1.1.1.
we try to compile the openssl 1.1.1 version code, replace 1.0.2k.so, the module 
such as ssh can not find the link symbol, 
how to upgrade the openssl version to 1.1.1 based on centos7, so that we can 
use the sm4 algorithm?

Thanks



张帅 
中国电信股份有限公司云计算分公司 研发部 
邮件：zhangsh...@chinatelecom.cn 
地址：北京市海淀区中关村软件园2期新兴产业联盟大厦1层
 
From: Damjan Marion
Date: 2019-10-28 18:35
To: zhangshuai
CC: vpp-dev
Subject: Re: [vpp-dev] how to update openssl in the vpp


On 24 Oct 2019, at 04:46, zhangsh...@chinatelecom.cn wrote:

Hello:
how to update openssl in the vpp?

We uses system openssl, so whatever you have installed VPP will use…


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

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

[Dave Barach via Lists.Fd.Io]

Please see 
https://fd.io/docs/vpp/master/gettingstarted/developers/gitreview.html.

Event log entry timestamps have nanosecond granularity. It might work out to do 
something like the following:

2019/10/31 09:18:36:937:123:895   ## initial full timestamp
 +0: api-msg: trace_plugin_msg_ids
+1.2us: api-msg-done(mp-safe): trace_plugin_msg_ids
 +30us: api-msg: trace_plugin_msg_ids
+1.1us: api-msg-done(mp-safe): trace_plugin_msg_ids

If delta exceeds 100ms (or some such), emit another full timestamp.

This will reduce the average output width considerably, and reduce the 
subtrahend / minuend widths when asking questions of the form “how long does 
the XYZ API message handler take?”

FWIW... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Aleksander Djuric
Sent: Thursday, October 31, 2019 2:56 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] event-logger output format

Hi all,

In my opinion, the event-logger cli command has uncomfortable format of output. 
I have small suggestion about it. I think that the event-logger output should 
be printed in following manner:

vpp# show event-logger
72 of 131072 events in buffer, logger running
2019/10/31 09:18:36:937: api-msg: trace_plugin_msg_ids
2019/10/31 09:18:36:937: api-msg-done(mp-safe): trace_plugin_msg_ids
2019/10/31 09:18:36:937: api-msg: trace_plugin_msg_ids
2019/10/31 09:18:36:937: api-msg-done(mp-safe): trace_plugin_msg_ids
2019/10/31 09:18:36:937: api-msg: trace_plugin_msg_ids

I propose a small patch, which makes human-readable the output format of the 
event-logger cli command. Please look at the patch below, is it acceptable?

Any comments and suggestions are welcome.

Thanks in advance,

Aleksander

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

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

[Guo, Ruijing]

Good catch, neale I will check why it use 192.168.1.1.

From: Neale Ranns (nranns) 
Sent: Thursday, October 31, 2019 4:39 PM
To: Guo, Ruijing ; Ni, Hongjun ; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] vpp with gtpu


Hi Ruijing,

Comments inline.

/neale

From: mailto:vpp-dev@lists.fd.io>> on behalf of "Guo, 
Ruijing" mailto:ruijing@intel.com>>
Date: Thursday 31 October 2019 at 09:29
To: "Ni, Hongjun" mailto:hongjun...@intel.com>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] vpp with gtpu

Hi, Hongjun

After adding the configuration, ping still failed as:

Packet 14

00:02:10:052842: af-packet-input
  af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
  status 0x81 len 146 snaplen 146 mac 66 net 80
  sec 0x5dbb241d nsec 0x2a83d8a6 vlan 0 vlan_tpid 0
00:02:10:052858: ethernet-input
  IP4: 52:54:00:43:88:63 -> 52:54:00:12:ab:01
00:02:10:052867: ip4-input
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:02:10:052878: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  UDP: 192.168.1.1 -> 192.168.1.22

^^ the packet is not sourced from the end-point address of the tunnel, hence 
does not classify to a tunnel …

tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:02:10:052888: ip4-local
UDP: 192.168.1.1 -> 192.168.1.22
  tos 0x00, ttl 253, length 132, checksum 0x3a01
  fragment id 0x
UDP: 24445 -> 2152
  length 112, checksum 0x
00:02:10:052892: ip4-udp-lookup
  UDP: src-port 24445 dst-port 2152
00:02:10:052894: gtpu4-input
  GTPU decap error - tunnel for teid 13 does not exist

… here ^^^.

Check the sender to see why it uses 192.168.1.1 as a source address.

/neale

00:02:10:052900: error-drop
  rx:host-eth1
00:02:10:052901: drop
  gtpu4-input: no such tunnel packets

From: Ni, Hongjun mailto:hongjun...@intel.com>>
Sent: Thursday, October 31, 2019 4:22 PM
To: Guo, Ruijing mailto:ruijing@intel.com>>; 
vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi Ruijing,

It seems that GTPU did not failed on the fib check.

Please add below items on your configuration:
sudo vppctl create gtpu tunnel src 192.168.1.22 dst 192.168.1.21 teid 13 
encap-vrf-id 0 decap-next ip4

Thanks,
Hongjun

From: Guo, Ruijing mailto:ruijing@intel.com>>
Sent: Thursday, October 31, 2019 3:23 PM
To: Ni, Hongjun mailto:hongjun...@intel.com>>; 
vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi, Hongjun

Packets are attached

Thanks,
-Ruijing

From: Ni, Hongjun mailto:hongjun...@intel.com>>
Sent: Thursday, October 31, 2019 3:12 PM
To: Guo, Ruijing mailto:ruijing@intel.com>>; 
vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi Ruijing,

It seems that there may be some issue on the gtpu decapsulation.

Could you help to capture the traffic between the vpp1 side and  vpp2 side?

Thanks,
Hongjun

From: Guo, Ruijing mailto:ruijing@intel.com>>
Sent: Thursday, October 31, 2019 2:57 PM
To: vpp-dev@lists.fd.io
Cc: Ni, Hongjun mailto:hongjun...@intel.com>>
Subject: vpp with gtpu

Hi,

I tried vpp (18.04-release, 19.08.1-release) with gtpu. it cannot work. Could 
you pls help?

Vpp1 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int mac address host-eth1 52:54:00:43:88:63
sudo vppctl set int ip add host-eth1 192.168.1.21/24
sudo vppctl show ip arp
sudo vppctl create gtpu tunnel src 192.168.1.21 dst 192.168.1.22 teid 13
sudo vppctl set int ip address gtpu_tunnel0  10.10.1.1/24
sudo vppctl set int stat gtpu_tunnel0 up

Vpp2 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int ip add host-eth1 192.168.1.22/24
sudo vppctl set int mac address host-eth1 52:54:00:12:ab:01
sudo vppctl create gtpu tunnel src 192.168.1.22 dst 192.168.1.21 teid 13
sudo vppctl set int  ip address gtpu_tunnel0  10.10.1.2/24
sudo vppctl set int stat gtpu_tunnel0 up


vpp1:
vagrant@vpp1:/vagrant$ sudo vppctl ping 192.168.1.22
116 bytes from 192.168.1.22: icmp_seq=1 ttl=64 time=3.8251 ms (<<< expect)

vagrant@vpp1:/vagrant$ sudo vppctl ping 10.10.1.2

Statistics: 5 sent, 0 received, 100% packet loss  (<<< expect ping can work)

I use wiresharp to decode the packets. TEID = 13 (exepct)


Vpp2:

Packet 13

00:18:42:156858: af-packet-input
  af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
  status 0x81 len 146 snaplen 146 mac 66 net 80
  sec 0x5dbb0dcd nsec 0x15b67ed8 vlan 0 vlan_tpid 0
00:18:42:156873: ethernet-input
  IP4: 52:54:00:43:88:63 -> 52:54:00:12:ab:01
00:18:42:156883: ip4-input
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, 

Re: [vpp-dev] vpp with gtpu

[Neale Ranns via Lists.Fd.Io]

Hi Ruijing,

Comments inline.

/neale

From:  on behalf of "Guo, Ruijing" 
Date: Thursday 31 October 2019 at 09:29
To: "Ni, Hongjun" , "vpp-dev@lists.fd.io" 

Subject: Re: [vpp-dev] vpp with gtpu

Hi, Hongjun

After adding the configuration, ping still failed as:

Packet 14

00:02:10:052842: af-packet-input
  af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
  status 0x81 len 146 snaplen 146 mac 66 net 80
  sec 0x5dbb241d nsec 0x2a83d8a6 vlan 0 vlan_tpid 0
00:02:10:052858: ethernet-input
  IP4: 52:54:00:43:88:63 -> 52:54:00:12:ab:01
00:02:10:052867: ip4-input
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:02:10:052878: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  UDP: 192.168.1.1 -> 192.168.1.22

^^ the packet is not sourced from the end-point address of the tunnel, hence 
does not classify to a tunnel …

tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:02:10:052888: ip4-local
UDP: 192.168.1.1 -> 192.168.1.22
  tos 0x00, ttl 253, length 132, checksum 0x3a01
  fragment id 0x
UDP: 24445 -> 2152
  length 112, checksum 0x
00:02:10:052892: ip4-udp-lookup
  UDP: src-port 24445 dst-port 2152
00:02:10:052894: gtpu4-input
  GTPU decap error - tunnel for teid 13 does not exist

… here ^^^.

Check the sender to see why it uses 192.168.1.1 as a source address.

/neale

00:02:10:052900: error-drop
  rx:host-eth1
00:02:10:052901: drop
  gtpu4-input: no such tunnel packets

From: Ni, Hongjun 
Sent: Thursday, October 31, 2019 4:22 PM
To: Guo, Ruijing ; vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi Ruijing,

It seems that GTPU did not failed on the fib check.

Please add below items on your configuration:
sudo vppctl create gtpu tunnel src 192.168.1.22 dst 192.168.1.21 teid 13 
encap-vrf-id 0 decap-next ip4

Thanks,
Hongjun

From: Guo, Ruijing mailto:ruijing@intel.com>>
Sent: Thursday, October 31, 2019 3:23 PM
To: Ni, Hongjun mailto:hongjun...@intel.com>>; 
vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi, Hongjun

Packets are attached

Thanks,
-Ruijing

From: Ni, Hongjun mailto:hongjun...@intel.com>>
Sent: Thursday, October 31, 2019 3:12 PM
To: Guo, Ruijing mailto:ruijing@intel.com>>; 
vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi Ruijing,

It seems that there may be some issue on the gtpu decapsulation.

Could you help to capture the traffic between the vpp1 side and  vpp2 side?

Thanks,
Hongjun

From: Guo, Ruijing mailto:ruijing@intel.com>>
Sent: Thursday, October 31, 2019 2:57 PM
To: vpp-dev@lists.fd.io
Cc: Ni, Hongjun mailto:hongjun...@intel.com>>
Subject: vpp with gtpu

Hi,

I tried vpp (18.04-release, 19.08.1-release) with gtpu. it cannot work. Could 
you pls help?

Vpp1 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int mac address host-eth1 52:54:00:43:88:63
sudo vppctl set int ip add host-eth1 192.168.1.21/24
sudo vppctl show ip arp
sudo vppctl create gtpu tunnel src 192.168.1.21 dst 192.168.1.22 teid 13
sudo vppctl set int ip address gtpu_tunnel0  10.10.1.1/24
sudo vppctl set int stat gtpu_tunnel0 up

Vpp2 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int ip add host-eth1 192.168.1.22/24
sudo vppctl set int mac address host-eth1 52:54:00:12:ab:01
sudo vppctl create gtpu tunnel src 192.168.1.22 dst 192.168.1.21 teid 13
sudo vppctl set int  ip address gtpu_tunnel0  10.10.1.2/24
sudo vppctl set int stat gtpu_tunnel0 up


vpp1:
vagrant@vpp1:/vagrant$ sudo vppctl ping 192.168.1.22
116 bytes from 192.168.1.22: icmp_seq=1 ttl=64 time=3.8251 ms (<<< expect)

vagrant@vpp1:/vagrant$ sudo vppctl ping 10.10.1.2

Statistics: 5 sent, 0 received, 100% packet loss  (<<< expect ping can work)

I use wiresharp to decode the packets. TEID = 13 (exepct)


Vpp2:

Packet 13

00:18:42:156858: af-packet-input
  af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
  status 0x81 len 146 snaplen 146 mac 66 net 80
  sec 0x5dbb0dcd nsec 0x15b67ed8 vlan 0 vlan_tpid 0
00:18:42:156873: ethernet-input
  IP4: 52:54:00:43:88:63 -> 52:54:00:12:ab:01
00:18:42:156883: ip4-input
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:18:42:156892: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:18:42:156901: ip4-local
UDP: 192.168.1.1 -> 192.168.1.22
  tos 0x00, ttl 253, length 132, checksum 0x3a01
  fragment id 0x
UDP: 24445 -> 2152
  length 112, checksum 0x

Re: [vpp-dev] vpp with gtpu

[Guo, Ruijing]

Hi, Hongjun

After adding the configuration, ping still failed as:

Packet 14

00:02:10:052842: af-packet-input
  af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
  status 0x81 len 146 snaplen 146 mac 66 net 80
  sec 0x5dbb241d nsec 0x2a83d8a6 vlan 0 vlan_tpid 0
00:02:10:052858: ethernet-input
  IP4: 52:54:00:43:88:63 -> 52:54:00:12:ab:01
00:02:10:052867: ip4-input
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:02:10:052878: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:02:10:052888: ip4-local
UDP: 192.168.1.1 -> 192.168.1.22
  tos 0x00, ttl 253, length 132, checksum 0x3a01
  fragment id 0x
UDP: 24445 -> 2152
  length 112, checksum 0x
00:02:10:052892: ip4-udp-lookup
  UDP: src-port 24445 dst-port 2152
00:02:10:052894: gtpu4-input
  GTPU decap error - tunnel for teid 13 does not exist
00:02:10:052900: error-drop
  rx:host-eth1
00:02:10:052901: drop
  gtpu4-input: no such tunnel packets

From: Ni, Hongjun 
Sent: Thursday, October 31, 2019 4:22 PM
To: Guo, Ruijing ; vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi Ruijing,

It seems that GTPU did not failed on the fib check.

Please add below items on your configuration:
sudo vppctl create gtpu tunnel src 192.168.1.22 dst 192.168.1.21 teid 13 
encap-vrf-id 0 decap-next ip4

Thanks,
Hongjun

From: Guo, Ruijing mailto:ruijing@intel.com>>
Sent: Thursday, October 31, 2019 3:23 PM
To: Ni, Hongjun mailto:hongjun...@intel.com>>; 
vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi, Hongjun

Packets are attached

Thanks,
-Ruijing

From: Ni, Hongjun mailto:hongjun...@intel.com>>
Sent: Thursday, October 31, 2019 3:12 PM
To: Guo, Ruijing mailto:ruijing@intel.com>>; 
vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi Ruijing,

It seems that there may be some issue on the gtpu decapsulation.

Could you help to capture the traffic between the vpp1 side and  vpp2 side?

Thanks,
Hongjun

From: Guo, Ruijing mailto:ruijing@intel.com>>
Sent: Thursday, October 31, 2019 2:57 PM
To: vpp-dev@lists.fd.io
Cc: Ni, Hongjun mailto:hongjun...@intel.com>>
Subject: vpp with gtpu

Hi,

I tried vpp (18.04-release, 19.08.1-release) with gtpu. it cannot work. Could 
you pls help?

Vpp1 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int mac address host-eth1 52:54:00:43:88:63
sudo vppctl set int ip add host-eth1 192.168.1.21/24
sudo vppctl show ip arp
sudo vppctl create gtpu tunnel src 192.168.1.21 dst 192.168.1.22 teid 13
sudo vppctl set int ip address gtpu_tunnel0  10.10.1.1/24
sudo vppctl set int stat gtpu_tunnel0 up

Vpp2 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int ip add host-eth1 192.168.1.22/24
sudo vppctl set int mac address host-eth1 52:54:00:12:ab:01
sudo vppctl create gtpu tunnel src 192.168.1.22 dst 192.168.1.21 teid 13
sudo vppctl set int  ip address gtpu_tunnel0  10.10.1.2/24
sudo vppctl set int stat gtpu_tunnel0 up


vpp1:
vagrant@vpp1:/vagrant$ sudo vppctl ping 192.168.1.22
116 bytes from 192.168.1.22: icmp_seq=1 ttl=64 time=3.8251 ms (<<< expect)

vagrant@vpp1:/vagrant$ sudo vppctl ping 10.10.1.2

Statistics: 5 sent, 0 received, 100% packet loss  (<<< expect ping can work)

I use wiresharp to decode the packets. TEID = 13 (exepct)


Vpp2:

Packet 13

00:18:42:156858: af-packet-input
  af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
  status 0x81 len 146 snaplen 146 mac 66 net 80
  sec 0x5dbb0dcd nsec 0x15b67ed8 vlan 0 vlan_tpid 0
00:18:42:156873: ethernet-input
  IP4: 52:54:00:43:88:63 -> 52:54:00:12:ab:01
00:18:42:156883: ip4-input
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:18:42:156892: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:18:42:156901: ip4-local
UDP: 192.168.1.1 -> 192.168.1.22
  tos 0x00, ttl 253, length 132, checksum 0x3a01
  fragment id 0x
UDP: 24445 -> 2152
  length 112, checksum 0x
00:18:42:156905: ip4-udp-lookup
  UDP: src-port 24445 dst-port 2152
00:18:42:156907: gtpu4-input
  GTPU decap error - tunnel for teid 13 does not exist
00:18:42:156913: error-drop
  rx:host-eth1
00:18:42:156914: drop
  gtpu4-input: no such tunnel packets

vagrant@vpp2:~$ sudo vppctl show error
   CountNode  Reason
32   gtpu4-input  no such 

Re: [vpp-dev] vpp with gtpu

[Ni, Hongjun]

Hi Ruijing,

It seems that GTPU did not failed on the fib check.

Please add below items on your configuration:
sudo vppctl create gtpu tunnel src 192.168.1.22 dst 192.168.1.21 teid 13 
encap-vrf-id 0 decap-next ip4

Thanks,
Hongjun

From: Guo, Ruijing 
Sent: Thursday, October 31, 2019 3:23 PM
To: Ni, Hongjun ; vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi, Hongjun

Packets are attached

Thanks,
-Ruijing

From: Ni, Hongjun mailto:hongjun...@intel.com>>
Sent: Thursday, October 31, 2019 3:12 PM
To: Guo, Ruijing mailto:ruijing@intel.com>>; 
vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi Ruijing,

It seems that there may be some issue on the gtpu decapsulation.

Could you help to capture the traffic between the vpp1 side and  vpp2 side?

Thanks,
Hongjun

From: Guo, Ruijing mailto:ruijing@intel.com>>
Sent: Thursday, October 31, 2019 2:57 PM
To: vpp-dev@lists.fd.io
Cc: Ni, Hongjun mailto:hongjun...@intel.com>>
Subject: vpp with gtpu

Hi,

I tried vpp (18.04-release, 19.08.1-release) with gtpu. it cannot work. Could 
you pls help?

Vpp1 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int mac address host-eth1 52:54:00:43:88:63
sudo vppctl set int ip add host-eth1 192.168.1.21/24
sudo vppctl show ip arp
sudo vppctl create gtpu tunnel src 192.168.1.21 dst 192.168.1.22 teid 13
sudo vppctl set int ip address gtpu_tunnel0  10.10.1.1/24
sudo vppctl set int stat gtpu_tunnel0 up

Vpp2 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int ip add host-eth1 192.168.1.22/24
sudo vppctl set int mac address host-eth1 52:54:00:12:ab:01
sudo vppctl create gtpu tunnel src 192.168.1.22 dst 192.168.1.21 teid 13
sudo vppctl set int  ip address gtpu_tunnel0  10.10.1.2/24
sudo vppctl set int stat gtpu_tunnel0 up


vpp1:
vagrant@vpp1:/vagrant$ sudo vppctl ping 192.168.1.22
116 bytes from 192.168.1.22: icmp_seq=1 ttl=64 time=3.8251 ms (<<< expect)

vagrant@vpp1:/vagrant$ sudo vppctl ping 10.10.1.2

Statistics: 5 sent, 0 received, 100% packet loss  (<<< expect ping can work)

I use wiresharp to decode the packets. TEID = 13 (exepct)


Vpp2:

Packet 13

00:18:42:156858: af-packet-input
  af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
  status 0x81 len 146 snaplen 146 mac 66 net 80
  sec 0x5dbb0dcd nsec 0x15b67ed8 vlan 0 vlan_tpid 0
00:18:42:156873: ethernet-input
  IP4: 52:54:00:43:88:63 -> 52:54:00:12:ab:01
00:18:42:156883: ip4-input
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:18:42:156892: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:18:42:156901: ip4-local
UDP: 192.168.1.1 -> 192.168.1.22
  tos 0x00, ttl 253, length 132, checksum 0x3a01
  fragment id 0x
UDP: 24445 -> 2152
  length 112, checksum 0x
00:18:42:156905: ip4-udp-lookup
  UDP: src-port 24445 dst-port 2152
00:18:42:156907: gtpu4-input
  GTPU decap error - tunnel for teid 13 does not exist
00:18:42:156913: error-drop
  rx:host-eth1
00:18:42:156914: drop
  gtpu4-input: no such tunnel packets

vagrant@vpp2:~$ sudo vppctl show error
   CountNode  Reason
32   gtpu4-input  no such tunnel packets
 6arp-reply   ARP replies sent
 8ip4-input   ip4 source lookup miss
 2 ip4-icmp-input echo replies sent
   601llc-input   unknown llc ssap/dsap
17 ethernet-input no error
74 ethernet-input l3 mac mismatch

vagrant@vpp2:~$ sudo vppctl show gtpu tunnel
[0] src 192.168.1.22 dst 192.168.1.21 teid 13 fib-idx 0 sw-if-idx 2 
encap-dpo-idx 13 decap-next-l2


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

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

Re: [vpp-dev] vpp with gtpu

[Guo, Ruijing]

Hi, Hongjun

Packets are attached

Thanks,
-Ruijing

From: Ni, Hongjun 
Sent: Thursday, October 31, 2019 3:12 PM
To: Guo, Ruijing ; vpp-dev@lists.fd.io
Subject: RE: vpp with gtpu

Hi Ruijing,

It seems that there may be some issue on the gtpu decapsulation.

Could you help to capture the traffic between the vpp1 side and  vpp2 side?

Thanks,
Hongjun

From: Guo, Ruijing mailto:ruijing@intel.com>>
Sent: Thursday, October 31, 2019 2:57 PM
To: vpp-dev@lists.fd.io
Cc: Ni, Hongjun mailto:hongjun...@intel.com>>
Subject: vpp with gtpu

Hi,

I tried vpp (18.04-release, 19.08.1-release) with gtpu. it cannot work. Could 
you pls help?

Vpp1 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int mac address host-eth1 52:54:00:43:88:63
sudo vppctl set int ip add host-eth1 192.168.1.21/24
sudo vppctl show ip arp
sudo vppctl create gtpu tunnel src 192.168.1.21 dst 192.168.1.22 teid 13
sudo vppctl set int ip address gtpu_tunnel0  10.10.1.1/24
sudo vppctl set int stat gtpu_tunnel0 up

Vpp2 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int ip add host-eth1 192.168.1.22/24
sudo vppctl set int mac address host-eth1 52:54:00:12:ab:01
sudo vppctl create gtpu tunnel src 192.168.1.22 dst 192.168.1.21 teid 13
sudo vppctl set int  ip address gtpu_tunnel0  10.10.1.2/24
sudo vppctl set int stat gtpu_tunnel0 up


vpp1:
vagrant@vpp1:/vagrant$ sudo vppctl ping 192.168.1.22
116 bytes from 192.168.1.22: icmp_seq=1 ttl=64 time=3.8251 ms (<<< expect)

vagrant@vpp1:/vagrant$ sudo vppctl ping 10.10.1.2

Statistics: 5 sent, 0 received, 100% packet loss  (<<< expect ping can work)

I use wiresharp to decode the packets. TEID = 13 (exepct)


Vpp2:

Packet 13

00:18:42:156858: af-packet-input
  af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
  status 0x81 len 146 snaplen 146 mac 66 net 80
  sec 0x5dbb0dcd nsec 0x15b67ed8 vlan 0 vlan_tpid 0
00:18:42:156873: ethernet-input
  IP4: 52:54:00:43:88:63 -> 52:54:00:12:ab:01
00:18:42:156883: ip4-input
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:18:42:156892: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:18:42:156901: ip4-local
UDP: 192.168.1.1 -> 192.168.1.22
  tos 0x00, ttl 253, length 132, checksum 0x3a01
  fragment id 0x
UDP: 24445 -> 2152
  length 112, checksum 0x
00:18:42:156905: ip4-udp-lookup
  UDP: src-port 24445 dst-port 2152
00:18:42:156907: gtpu4-input
  GTPU decap error - tunnel for teid 13 does not exist
00:18:42:156913: error-drop
  rx:host-eth1
00:18:42:156914: drop
  gtpu4-input: no such tunnel packets

vagrant@vpp2:~$ sudo vppctl show error
   CountNode  Reason
32   gtpu4-input  no such tunnel packets
 6arp-reply   ARP replies sent
 8ip4-input   ip4 source lookup miss
 2 ip4-icmp-input echo replies sent
   601llc-input   unknown llc ssap/dsap
17 ethernet-input no error
74 ethernet-input l3 mac mismatch

vagrant@vpp2:~$ sudo vppctl show gtpu tunnel
[0] src 192.168.1.22 dst 192.168.1.21 teid 13 fib-idx 0 sw-if-idx 2 
encap-dpo-idx 13 decap-next-l2


Thanks,
-Ruijing


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

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

Re: [vpp-dev] vpp with gtpu

[Ni, Hongjun]

Hi Ruijing,

It seems that there may be some issue on the gtpu decapsulation.

Could you help to capture the traffic between the vpp1 side and  vpp2 side?

Thanks,
Hongjun

From: Guo, Ruijing 
Sent: Thursday, October 31, 2019 2:57 PM
To: vpp-dev@lists.fd.io
Cc: Ni, Hongjun 
Subject: vpp with gtpu

Hi,

I tried vpp (18.04-release, 19.08.1-release) with gtpu. it cannot work. Could 
you pls help?

Vpp1 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int mac address host-eth1 52:54:00:43:88:63
sudo vppctl set int ip add host-eth1 192.168.1.21/24
sudo vppctl show ip arp
sudo vppctl create gtpu tunnel src 192.168.1.21 dst 192.168.1.22 teid 13
sudo vppctl set int ip address gtpu_tunnel0  10.10.1.1/24
sudo vppctl set int stat gtpu_tunnel0 up

Vpp2 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int ip add host-eth1 192.168.1.22/24
sudo vppctl set int mac address host-eth1 52:54:00:12:ab:01
sudo vppctl create gtpu tunnel src 192.168.1.22 dst 192.168.1.21 teid 13
sudo vppctl set int  ip address gtpu_tunnel0  10.10.1.2/24
sudo vppctl set int stat gtpu_tunnel0 up


vpp1:
vagrant@vpp1:/vagrant$ sudo vppctl ping 192.168.1.22
116 bytes from 192.168.1.22: icmp_seq=1 ttl=64 time=3.8251 ms (<<< expect)

vagrant@vpp1:/vagrant$ sudo vppctl ping 10.10.1.2

Statistics: 5 sent, 0 received, 100% packet loss  (<<< expect ping can work)

I use wiresharp to decode the packets. TEID = 13 (exepct)


Vpp2:

Packet 13

00:18:42:156858: af-packet-input
  af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
  status 0x81 len 146 snaplen 146 mac 66 net 80
  sec 0x5dbb0dcd nsec 0x15b67ed8 vlan 0 vlan_tpid 0
00:18:42:156873: ethernet-input
  IP4: 52:54:00:43:88:63 -> 52:54:00:12:ab:01
00:18:42:156883: ip4-input
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:18:42:156892: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:18:42:156901: ip4-local
UDP: 192.168.1.1 -> 192.168.1.22
  tos 0x00, ttl 253, length 132, checksum 0x3a01
  fragment id 0x
UDP: 24445 -> 2152
  length 112, checksum 0x
00:18:42:156905: ip4-udp-lookup
  UDP: src-port 24445 dst-port 2152
00:18:42:156907: gtpu4-input
  GTPU decap error - tunnel for teid 13 does not exist
00:18:42:156913: error-drop
  rx:host-eth1
00:18:42:156914: drop
  gtpu4-input: no such tunnel packets

vagrant@vpp2:~$ sudo vppctl show error
   CountNode  Reason
32   gtpu4-input  no such tunnel packets
 6arp-reply   ARP replies sent
 8ip4-input   ip4 source lookup miss
 2 ip4-icmp-input echo replies sent
   601llc-input   unknown llc ssap/dsap
17 ethernet-input no error
74 ethernet-input l3 mac mismatch

vagrant@vpp2:~$ sudo vppctl show gtpu tunnel
[0] src 192.168.1.22 dst 192.168.1.21 teid 13 fib-idx 0 sw-if-idx 2 
encap-dpo-idx 13 decap-next-l2


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

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

[vpp-dev] vpp with gtpu

[Guo, Ruijing]

Hi,

I tried vpp (18.04-release, 19.08.1-release) with gtpu. it cannot work. Could 
you pls help?

Vpp1 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int mac address host-eth1 52:54:00:43:88:63
sudo vppctl set int ip add host-eth1 192.168.1.21/24
sudo vppctl show ip arp
sudo vppctl create gtpu tunnel src 192.168.1.21 dst 192.168.1.22 teid 13
sudo vppctl set int ip address gtpu_tunnel0  10.10.1.1/24
sudo vppctl set int stat gtpu_tunnel0 up

Vpp2 setup:
sudo vppctl create host-interface name eth1
sudo vppctl set inter stat host-eth1 up
sudo vppctl set int ip add host-eth1 192.168.1.22/24
sudo vppctl set int mac address host-eth1 52:54:00:12:ab:01
sudo vppctl create gtpu tunnel src 192.168.1.22 dst 192.168.1.21 teid 13
sudo vppctl set int  ip address gtpu_tunnel0  10.10.1.2/24
sudo vppctl set int stat gtpu_tunnel0 up


vpp1:
vagrant@vpp1:/vagrant$ sudo vppctl ping 192.168.1.22
116 bytes from 192.168.1.22: icmp_seq=1 ttl=64 time=3.8251 ms (<<< expect)

vagrant@vpp1:/vagrant$ sudo vppctl ping 10.10.1.2

Statistics: 5 sent, 0 received, 100% packet loss  (<<< expect ping can work)

I use wiresharp to decode the packets. TEID = 13 (exepct)


Vpp2:

Packet 13

00:18:42:156858: af-packet-input
  af_packet: hw_if_index 1 next-index 4
tpacket2_hdr:
  status 0x81 len 146 snaplen 146 mac 66 net 80
  sec 0x5dbb0dcd nsec 0x15b67ed8 vlan 0 vlan_tpid 0
00:18:42:156873: ethernet-input
  IP4: 52:54:00:43:88:63 -> 52:54:00:12:ab:01
00:18:42:156883: ip4-input
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:18:42:156892: ip4-lookup
  fib 0 dpo-idx 5 flow hash: 0x
  UDP: 192.168.1.1 -> 192.168.1.22
tos 0x00, ttl 253, length 132, checksum 0x3a01
fragment id 0x
  UDP: 24445 -> 2152
length 112, checksum 0x
00:18:42:156901: ip4-local
UDP: 192.168.1.1 -> 192.168.1.22
  tos 0x00, ttl 253, length 132, checksum 0x3a01
  fragment id 0x
UDP: 24445 -> 2152
  length 112, checksum 0x
00:18:42:156905: ip4-udp-lookup
  UDP: src-port 24445 dst-port 2152
00:18:42:156907: gtpu4-input
  GTPU decap error - tunnel for teid 13 does not exist
00:18:42:156913: error-drop
  rx:host-eth1
00:18:42:156914: drop
  gtpu4-input: no such tunnel packets

vagrant@vpp2:~$ sudo vppctl show error
   CountNode  Reason
32   gtpu4-input  no such tunnel packets
 6arp-reply   ARP replies sent
 8ip4-input   ip4 source lookup miss
 2 ip4-icmp-input echo replies sent
   601llc-input   unknown llc ssap/dsap
17 ethernet-input no error
74 ethernet-input l3 mac mismatch

vagrant@vpp2:~$ sudo vppctl show gtpu tunnel
[0] src 192.168.1.22 dst 192.168.1.21 teid 13 fib-idx 0 sw-if-idx 2 
encap-dpo-idx 13 decap-next-l2


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

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

[vpp-dev] event-logger output format

[Aleksander Djuric]

Hi all,

In my opinion, the event-logger cli command has uncomfortable format of
output. I have small suggestion about it. I think that the event-logger
output should be printed in following manner:

vpp# show event-logger
> 72 of 131072 events in buffer, logger running
> 2019/10/31 09:18:36:937: api-msg: trace_plugin_msg_ids
> 2019/10/31 09:18:36:937: api-msg-done(mp-safe): trace_plugin_msg_ids
> 2019/10/31 09:18:36:937: api-msg: trace_plugin_msg_ids
> 2019/10/31 09:18:36:937: api-msg-done(mp-safe): trace_plugin_msg_ids
> 2019/10/31 09:18:36:937: api-msg: trace_plugin_msg_ids


I propose a small patch, which makes human-readable the output format of
the event-logger cli command. Please look at the patch below, is it
acceptable?

Any comments and suggestions are welcome.

Thanks in advance,

Aleksander
diff --git a/src/vlib/main.c b/src/vlib/main.c
index dc11128..7e256ac 100644
--- a/src/vlib/main.c
+++ b/src/vlib/main.c
@@ -849,7 +849,10 @@ elog_show_buffer_internal (vlib_main_t * vm, u32 n_events_to_show)
 {
   elog_main_t *em = >elog_main;
   elog_event_t *e, *es;
-  f64 dt;
+  f64 it, dt;
+
+  /* Initial time */
+  it = em->init_time.os_nsec / 1e9 + 1490885108;
 
   /* Show events in VLIB time since log clock starts after VLIB clock. */
   dt = (em->init_time.cpu - vm->clib_time.init_cpu_time)
@@ -860,10 +863,13 @@ elog_show_buffer_internal (vlib_main_t * vm, u32 n_events_to_show)
 		   em->event_ring_size,
 		   em->n_total_events < em->n_total_events_disable_limit ?
 		   "running" : "stopped");
+
   vec_foreach (e, es)
   {
-vlib_cli_output (vm, "%18.9f: %U",
-		 e->time + dt, format_elog_event, em, e);
+f64 t = it + (e->time + dt);
+vlib_cli_output (vm, "%U: %U",
+		 format_time_float, "y/m/d H:M:S:F", t,
+		 format_elog_event, em, e);
 n_events_to_show--;
 if (n_events_to_show == 0)
   break;
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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