Re: [vpp-dev] python api over tcp?

[Ole Troan]

Hi Paul,

> Where can we find the Telegraf plugin?

It might be that it wasn't published.k

There is this for gnmi:
https://github.com/vpp-telemetry-pfe/gnmi-grpc
And I think the sweetcomb project offers a northbound interface based on that.

Best regards,
Ole


> 
> On Thu, Jan 9, 2020 at 5:44 AM Ole Troan  wrote:
> Christian,
> 
> >> For exporting data out of the stats segment, I believe there is already 
> >> quite a few solutions.
> >> There's the (naive) prometheus example in the repo, vpp_get_stats, there 
> >> is a Telegraf plugin, a simple gNMI/gRPC plugin.
> > 
> > Right I've used vpp_get_stats and may run that with ssh and awk. I guess it 
> > just seems odd on first encountering this that the CLI provided the data, 
> > but the binary API didn't. I suppose the view is that exposing the stats 
> > segment in shared memory *is* the binary API. :)
> 
> What certainly would make sense to do, is to put a wrapper on top of 
> vpp_stats.py that gives you a higher level API of accessing the stats.
> E.g. a get_interface_counters(). The stat segment also contains the name to 
> interface index mapping (/if/names).
> Want to have a go?
> 
> I am also exploring putting much more information into the stat segment, 
> essentially making it into an operational data store (RFC8342). Don't hold 
> your breath. But any help appreciated.
> 
> Cheers,
> Ole
> 

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

View/Reply Online (#15157): https://lists.fd.io/g/vpp-dev/message/15157
Mute This Topic: https://lists.fd.io/mt/69538850/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] python api over tcp?

[Ole Troan]

Hi Vratko,


> In my eyes, this e-mail thread contains two largely independent questions.
>  
> The first question is how we can make stats available over a "wire".
> Remote user asks over the wire, the request is seen on VPP side of the wire
> as a byte sequence.
> Some (currently missing) VPP code parses that request,
> looks into the shared memory, and serializes the requested stats
> into a response (sequence of bytes), put to the wire for user to read from.
>  
> Ssh + vpp_get_stats acts as a wire, but the format is human (not machine) 
> friendly.
> Similarly to how CLI is less machine friendly than binary API.
>  
> I expect the first implementation of machine friendly "stats over wire"
> to use Unix Domain Socket as the wire, just because VPP already has
> a dispatcher for handling binary messages of prescribed type there.
> Also, UDS has smaller overhead than other wires,
> especially if VPP is in a container.
>  
> A sub-question is whether to support explicit polling,
> or subscribing for notifications (or both).
> In CSIT we want explicit polling.
>  
> The second question is what wire is the best for stats transport.
> (And whether we should add support for more wire types.)
> > There's the (naive) prometheus example in the repo, vpp_get_stats,
> > there is a Telegraf plugin, a simple gNMI/gRPC plugin.
>  
> I suspect the Prometheus example is for publish/subscribe,
> and vpp_get_stats is for explicit polling.
> Not sure about the others.

This should be done as an intermediate agent.

E.g. like:
https://github.com/vpp-telemetry-pfe/gnmi-grpc

Or the example Prometheus server.

I'd imagine both push and pull would have to be supported. But I don't think 
this should go into the main VPP executable.


Best regards,
Ole-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15158): https://lists.fd.io/g/vpp-dev/message/15158
Mute This Topic: https://lists.fd.io/mt/69538850/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] python api over tcp?

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io]

> This should be done as an intermediate agent.

I have a hypothetical question.
(I am not trying to be cheeky.
I feel there may be a difference,
I just do not see it.)

Imagine a world where VPP supports
(CLI via vppctl and) binary API only over shared memory.
No support for binary API over Unix Domain Socket.
(Sockets are only used for getting file descriptors,
so interaction via shared memory can start.)

And imagine there is a discussion on how to make
binary API available for remote users.
Somebody suggests adding UDS as the new way
to exchange binary API messages (in network byte order).

Would that suggestion also result in
"This should be done as an intermediate agent." and
"I don't think this should go into the main VPP executable."?

Vratko.

From: vpp-dev@lists.fd.io  On Behalf Of Ole Troan
Sent: Tuesday, January 14, 2020 12:29 PM
To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) 
Cc: Paul Vinciguerra ; Christian Hopps 
; vpp-dev 
Subject: Re: [vpp-dev] python api over tcp?

Hi Vratko,


> In my eyes, this e-mail thread contains two largely independent questions.
>
> The first question is how we can make stats available over a "wire".
> Remote user asks over the wire, the request is seen on VPP side of the wire
> as a byte sequence.
> Some (currently missing) VPP code parses that request,
> looks into the shared memory, and serializes the requested stats
> into a response (sequence of bytes), put to the wire for user to read from.
>
> Ssh + vpp_get_stats acts as a wire, but the format is human (not machine) 
> friendly.
> Similarly to how CLI is less machine friendly than binary API.
>
> I expect the first implementation of machine friendly "stats over wire"
> to use Unix Domain Socket as the wire, just because VPP already has
> a dispatcher for handling binary messages of prescribed type there.
> Also, UDS has smaller overhead than other wires,
> especially if VPP is in a container.
>
> A sub-question is whether to support explicit polling,
> or subscribing for notifications (or both).
> In CSIT we want explicit polling.
>
> The second question is what wire is the best for stats transport.
> (And whether we should add support for more wire types.)
> > There's the (naive) prometheus example in the repo, vpp_get_stats,
> > there is a Telegraf plugin, a simple gNMI/gRPC plugin.
>
> I suspect the Prometheus example is for publish/subscribe,
> and vpp_get_stats is for explicit polling.
> Not sure about the others.

This should be done as an intermediate agent.

E.g. like:
https://github.com/vpp-telemetry-pfe/gnmi-grpc

Or the example Prometheus server.

I'd imagine both push and pull would have to be supported. But I don't think 
this should go into the main VPP executable.


Best regards,
Ole

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

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

[vpp-dev] Rejecting large frequency change of +infinity%

[Artem Belov]

Hello

I am running vpp (latest stable/1908) on kubernetes pod. Sometimes I get a
warning

> clib_time_verify_frequency:249: Rejecting large frequency change of
> +infinity%

WIth the warning vpp stops sending and receiving any packets of all
interfaces. This warning logged by vpp a lot of times by each run.

Removing next block of code helps, but I think it is not correct way to
resolve this issue.

>   /*
>* Reject large frequency changes, another consequence of
>* system clock changes particularly with old kernels.
>*/
>   new_clocks_per_second =
> flt_round_nearest ((f64) dtc / (dtr * c->round_to_units))
> * c->round_to_units;
>   delta = new_clocks_per_second - c->clocks_per_second;
>   if (delta < 0.0)
> delta = -delta;
>   if (PREDICT_FALSE ((delta / c->clocks_per_second) > .01))
> {
>   clib_warning ("Rejecting large frequency change of %.2f%%",
>(delta / c->clocks_per_second) * 100.0);
>   c->log2_clocks_per_frequency_verify = c->log2_clocks_per_second;
>   return;
> }


Could you please help to find a root cause of an issue and resolve it.

Thanks

--
*Artem Belov* 
Software Engineer
Email: artem.be...@xored.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Coverity run FAILED as of 2020-01-14 14:00:24 UTC

[Noreply Jenkins]

Coverity run failed today.

Current number of outstanding issues are 2
Newly detected: 0
Eliminated: 0
More details can be found at  
https://scan.coverity.com/projects/fd-io-vpp/view_defects
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15161): https://lists.fd.io/g/vpp-dev/message/15161
Mute This Topic: https://lists.fd.io/mt/69693543/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-hoststack - Issue with UDP receiver application using VCL library

[raj . gautam25]

Hi ,
I am trying some host application tests ( using LD_PRELOAD) .  TCP rx and tx 
both work fine. UDP tx also works fine.
The issue is only with UDP rx .  In some discussion it was mentioned that 
session layer does not support connection-less transports so protocols like udp 
still need to accept connections and only afterwards read from the fifos.
So, I changed the UDP receiver application to use listen() and accept() before 
read() . But , I am still having issue to make it run.
After I started, udp traffic from other server it seems to accept the 
connection but never returns from the vppcom_session_accept() function.
VPP release is 19.08.

vpp# sh app server
Connection                              App                          Wrk
[0:0][CT:U] 0.0.0.0:8090->0.0.0.0:0     ldp-36646-app[shm]            0
[#0][U] 0.0.0.0:8090->0.0.0.0:0         ldp-36646-app[shm]            0
vpp#

[root@orc01 testcode]#  VCL_DEBUG=2 LDP_DEBUG=2 
LD_PRELOAD=/opt/vpp/build-root/install-vpp-native/vpp/lib/libvcl_ldpreload.so  
VCL_CONFIG=/etc/vpp/vcl.cfg ./udp_rx
VCL<36646>: configured VCL debug level (2) from VCL_DEBUG!
VCL<36646>: allocated VCL heap = 0x7f77e5309010, size 268435456 (0x1000)
VCL<36646>: configured rx_fifo_size 400 (0x3d0900)
VCL<36646>: configured tx_fifo_size 400 (0x3d0900)
VCL<36646>: configured app_scope_local (1)
VCL<36646>: configured app_scope_global (1)
VCL<36646>: configured api-socket-name (/tmp/vpp-api.sock)
VCL<36646>: completed parsing vppcom config!
vppcom_connect_to_vpp:549: vcl<36646:0>: app (ldp-36646-app) is connected to 
VPP!
vppcom_app_create:1067: vcl<36646:0>: sending session enable
vppcom_app_create:1075: vcl<36646:0>: sending app attach
vppcom_app_create:1084: vcl<36646:0>: app_name 'ldp-36646-app', my_client_index 
0 (0x0)
ldp_init:209: ldp<36646>: configured LDP debug level (2) from env var LDP_DEBUG!
ldp_init:282: ldp<36646>: LDP initialization: done!
ldp_constructor:2490: LDP<36646>: LDP constructor: done!
socket:974: ldp<36646>: calling vls_create: proto 1 (UDP), is_nonblocking 0
vppcom_session_create:1142: vcl<36646:0>: created session 0
Socket successfully created..
bind:1086: ldp<36646>: fd 32: calling vls_bind: vlsh 0, addr 0x7fff3f3c1040, 
len 16
vppcom_session_bind:1280: vcl<36646:0>: session 0 handle 0: binding to local 
IPv4 address 0.0.0.0 port 8090, proto UDP
vppcom_session_listen:1312: vcl<36646:0>: session 0: sending vpp listen 
request...
vcl_session_bound_handler:610: vcl<36646:0>: session 0 [0x1]: listen succeeded!
bind:1102: ldp<36646>: fd 32: returning 0
Socket successfully binded..
listen:2005: ldp<36646>: fd 32: calling vls_listen: vlsh 0, n 5
vppcom_session_listen:1308: vcl<36646:0>: session 0 [0x1]: already in listen 
state!
listen:2020: ldp<36646>: fd 32: returning 0
Server listening..
ldp_accept4:2043: ldp<36646>: listen fd 32: calling vppcom_session_accept: 
listen sid 0, ep 0x0, flags 0x3f3c0fc0
vppcom_session_accept:1478: vcl<36646:0>: discarded event: 0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] VPP / Calico integration announcement

[Aloys Augustin (aloaugus) via Lists.Fd.Io]

Hello VPP devs,

We have recently released an alpha version of an integration between Calico 
 and VPP for Kubernetes: 
https://github.com/calico-vpp/calico-vpp/wiki 
. The goal is mainly to 
accelerate Calico’s networking by using VPP instead of the kernel to process 
container communications.
Many features are still missing, but the core pod networking should be 
functional. Feel free to test it, any feedback is welcome!

Best,
Aloÿs

smime.p7s
Description: S/MIME cryptographic signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Arm verify job broken

[Florin Coras]

Hi, 

Jobs have been failing since yesterday. Did anybody try to look into it?

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

View/Reply Online (#15164): https://lists.fd.io/g/vpp-dev/message/15164
Mute This Topic: https://lists.fd.io/mt/69698855/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-hoststack - Issue with UDP receiver application using VCL library

[Florin Coras]

Hi Raj,

Session layer does support connection-less transports but udp does not raise 
accept notifications to vcl. UDPC might, but we haven’t tested udpc with vcl in 
a long time so it might not work properly. 

What was the problem you were hitting in the non-connected case?

Regards,
Florin

> On Jan 14, 2020, at 7:13 AM, raj.gauta...@gmail.com wrote:
> 
> Hi ,
> I am trying some host application tests ( using LD_PRELOAD) .  TCP rx and tx 
> both work fine. UDP tx also works fine. 
> The issue is only with UDP rx .  In some discussion it was mentioned that 
> session layer does not support connection-less transports so protocols like 
> udp still need to accept connections and only afterwards read from the fifos.
> So, I changed the UDP receiver application to use listen() and accept() 
> before read() . But , I am still having issue to make it run. 
> After I started, udp traffic from other server it seems to accept the 
> connection but never returns from the vppcom_session_accept() function.
> VPP release is 19.08.
> 
> vpp# sh app server
> Connection  App  Wrk
> [0:0][CT:U] 0.0.0.0:8090->0.0.0.0:0 ldp-36646-app[shm]0
> [#0][U] 0.0.0.0:8090->0.0.0.0:0 ldp-36646-app[shm]0
> vpp#
>
>
> [root@orc01 testcode]#  VCL_DEBUG=2 LDP_DEBUG=2 
> LD_PRELOAD=/opt/vpp/build-root/install-vpp-native/vpp/lib/libvcl_ldpreload.so 
>  VCL_CONFIG=/etc/vpp/vcl.cfg ./udp_rx
> VCL<36646>: configured VCL debug level (2) from VCL_DEBUG!
> VCL<36646>: allocated VCL heap = 0x7f77e5309010, size 268435456 (0x1000)
> VCL<36646>: configured rx_fifo_size 400 (0x3d0900)
> VCL<36646>: configured tx_fifo_size 400 (0x3d0900)
> VCL<36646>: configured app_scope_local (1)
> VCL<36646>: configured app_scope_global (1)
> VCL<36646>: configured api-socket-name (/tmp/vpp-api.sock)
> VCL<36646>: completed parsing vppcom config!
> vppcom_connect_to_vpp:549: vcl<36646:0>: app (ldp-36646-app) is connected to 
> VPP!
> vppcom_app_create:1067: vcl<36646:0>: sending session enable
> vppcom_app_create:1075: vcl<36646:0>: sending app attach
> vppcom_app_create:1084: vcl<36646:0>: app_name 'ldp-36646-app', 
> my_client_index 0 (0x0)
> ldp_init:209: ldp<36646>: configured LDP debug level (2) from env var 
> LDP_DEBUG!
> ldp_init:282: ldp<36646>: LDP initialization: done!
> ldp_constructor:2490: LDP<36646>: LDP constructor: done!
> socket:974: ldp<36646>: calling vls_create: proto 1 (UDP), is_nonblocking 0
> vppcom_session_create:1142: vcl<36646:0>: created session 0
> Socket successfully created..
> bind:1086: ldp<36646>: fd 32: calling vls_bind: vlsh 0, addr 0x7fff3f3c1040, 
> len 16
> vppcom_session_bind:1280: vcl<36646:0>: session 0 handle 0: binding to local 
> IPv4 address 0.0.0.0 port 8090, proto UDP
> vppcom_session_listen:1312: vcl<36646:0>: session 0: sending vpp listen 
> request...
> vcl_session_bound_handler:610: vcl<36646:0>: session 0 [0x1]: listen 
> succeeded!
> bind:1102: ldp<36646>: fd 32: returning 0
> Socket successfully binded..
> listen:2005: ldp<36646>: fd 32: calling vls_listen: vlsh 0, n 5
> vppcom_session_listen:1308: vcl<36646:0>: session 0 [0x1]: already in listen 
> state!
> listen:2020: ldp<36646>: fd 32: returning 0
> Server listening..
> ldp_accept4:2043: ldp<36646>: listen fd 32: calling vppcom_session_accept: 
> listen sid 0, ep 0x0, flags 0x3f3c0fc0
> vppcom_session_accept:1478: vcl<36646:0>: discarded event: 0
>
> 

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

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

[vpp-dev] Reminder: 20.01 RC1 is tomorrow

[Andrew Yourtchenko]

Hi all,

Just a gentle reminder tomorrow (if ARM jobs are working by then that is), we 
will pull the stable/2001 branch and when that is done, the master will reopen 
for “risky” commits.

--a (your friendly 20.01 release manager)-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15166): https://lists.fd.io/g/vpp-dev/message/15166
Mute This Topic: https://lists.fd.io/mt/69699930/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] Arm verify job broken

[Ed Kern via Lists.Fd.Io]

looking into it now…..

its a strange one ill tell you that up front…failures are all over the place 
inside the build and even some hitting the 120 min timeout….

more as i dig hopefully

thanks for the ping

Ed



On Jan 14, 2020, at 11:40 AM, Florin Coras 
mailto:fcoras.li...@gmail.com>> wrote:

Hi,

Jobs have been failing since yesterday. Did anybody try to look into it?

Regards,
Florin


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

View/Reply Online (#15167): https://lists.fd.io/g/vpp-dev/message/15167
Mute This Topic: https://lists.fd.io/mt/69698855/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] Arm verify job broken

[Florin Coras]

Thanks, Ed!

Florin

> On Jan 14, 2020, at 11:53 AM, Ed Kern (ejk)  wrote:
> 
> looking into it now…..
> 
> its a strange one ill tell you that up front…failures are all over the place 
> inside the build and even some hitting the 120 min timeout….
> 
> more as i dig hopefully
> 
> thanks for the ping
> 
> Ed
> 
> 
> 
>> On Jan 14, 2020, at 11:40 AM, Florin Coras > > wrote:
>> 
>> Hi, 
>> 
>> Jobs have been failing since yesterday. Did anybody try to look into it?
>> 
>> Regards,
>> Florin
>> 
> 

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

View/Reply Online (#15168): https://lists.fd.io/g/vpp-dev/message/15168
Mute This Topic: https://lists.fd.io/mt/69698855/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] Arm verify job broken

[Ed Kern via Lists.Fd.Io]

ok FOR THE MOST PART…  build times haven’t changed  (@20 min)

make test portion has gone off the chain and is often hitting the 120 min build 
timeout threshold.

Ive currently got several jobs running on sandbox testing

a. without any timeouts (just to see if we are still passing on master)
b. three different memory and disk profiles (just in case someone/thing got 
messy and we have had another memory spike)

the bad news is that it will be at least a couple of hours more than likely 
before I get any results that I feel are actionable.


Having said that im happy to shoot the build timeout for the time being if 
committers feel that is warranted to ‘keep the train rolling’

Ed




On Jan 14, 2020, at 1:07 PM, Florin Coras 
mailto:fcoras.li...@gmail.com>> wrote:

Thanks, Ed!

Florin

On Jan 14, 2020, at 11:53 AM, Ed Kern (ejk) 
mailto:e...@cisco.com>> wrote:

looking into it now…..

its a strange one ill tell you that up front…failures are all over the place 
inside the build and even some hitting the 120 min timeout….

more as i dig hopefully

thanks for the ping

Ed



On Jan 14, 2020, at 11:40 AM, Florin Coras 
mailto:fcoras.li...@gmail.com>> wrote:

Hi,

Jobs have been failing since yesterday. Did anybody try to look into it?

Regards,
Florin




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

View/Reply Online (#15169): https://lists.fd.io/g/vpp-dev/message/15169
Mute This Topic: https://lists.fd.io/mt/69698855/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] Arm verify job broken

[Andrew Yourtchenko]

better to debug some before changing anything.

With my RM hat on I would rather understand what is going on, if it is 24 hours 
before the RC1 milestone ;-) 

--a

> On 14 Jan 2020, at 21:28, Ed Kern via Lists.Fd.Io  
> wrote:
> 
>  ok FOR THE MOST PART…  build times haven’t changed  (@20 min)
> 
> make test portion has gone off the chain and is often hitting the 120 min 
> build timeout threshold.
> 
> Ive currently got several jobs running on sandbox testing
> 
> a. without any timeouts (just to see if we are still passing on master)
> b. three different memory and disk profiles (just in case someone/thing got 
> messy and we have had another memory spike)
> 
> the bad news is that it will be at least a couple of hours more than likely 
> before I get any results that I feel are actionable.
> 
> 
> Having said that im happy to shoot the build timeout for the time being if 
> committers feel that is warranted to ‘keep the train rolling’
> 
> Ed
> 
> 
> 
> 
>>> On Jan 14, 2020, at 1:07 PM, Florin Coras  wrote:
>>> 
>>> Thanks, Ed!
>>> 
>>> Florin
>>> 
>>> On Jan 14, 2020, at 11:53 AM, Ed Kern (ejk)  wrote:
>>> 
>>> looking into it now…..
>>> 
>>> its a strange one ill tell you that up front…failures are all over the 
>>> place inside the build and even some hitting the 120 min timeout….
>>> 
>>> more as i dig hopefully
>>> 
>>> thanks for the ping
>>> 
>>> Ed
>>> 
>>> 
>>> 
 On Jan 14, 2020, at 11:40 AM, Florin Coras  wrote:
 
 Hi, 
 
 Jobs have been failing since yesterday. Did anybody try to look into it?
 
 Regards,
 Florin
 
>>> 
>> 
> 
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15170): https://lists.fd.io/g/vpp-dev/message/15170
Mute This Topic: https://lists.fd.io/mt/69698855/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-hoststack - Issue with UDP receiver application using VCL library

[Raj Kumar]

Hi Florin,
Thanks! for the reply.

I realized the issue with the non-connected case.  For receiving datagrams,
I was using recvfrom() with DONOT_WAIT flag because of
that  vppcom_session_recvfrom() api was failing. It expects either 0 or
MSG_PEEK flag.
  if (flags == 0)
rv = vppcom_session_read (session_handle, buffer, buflen);
  else if (flags & MSG_PEEK) 0x2
rv = vppcom_session_peek (session_handle, buffer, buflen);
  else
{
  VDBG (0, "Unsupport flags for recvfrom %d", flags);
  return VPPCOM_EAFNOSUPPORT;
}

 I changed the flag to 0 in recvfrom() , after that UDP rx is working fine
but only for IPv4.

I am facing a different issue with IPv6/UDP receiver.  I am getting "no
listener for dst port" error.

Please let me know if I am doing something wrong.
Here are the traces : -

[root@orc01 testcode]# VCL_DEBUG=2 LDP_DEBUG=2
LD_PRELOAD=/opt/vpp/build-root/install-vpp-native/vpp/lib/libvcl_ldpreload.so
 VCL_CONFIG=/etc/vpp/vcl.cfg ./udp6_rx
VCL<1164>: configured VCL debug level (2) from VCL_DEBUG!
VCL<1164>: allocated VCL heap = 0x7ff877439010, size 268435456 (0x1000)
VCL<1164>: configured rx_fifo_size 400 (0x3d0900)
VCL<1164>: configured tx_fifo_size 400 (0x3d0900)
VCL<1164>: configured app_scope_local (1)
VCL<1164>: configured app_scope_global (1)
VCL<1164>: configured api-socket-name (/tmp/vpp-api.sock)
VCL<1164>: completed parsing vppcom config!
vppcom_connect_to_vpp:549: vcl<1164:0>: app (ldp-1164-app) is connected to
VPP!
vppcom_app_create:1067: vcl<1164:0>: sending session enable
vppcom_app_create:1075: vcl<1164:0>: sending app attach
vppcom_app_create:1084: vcl<1164:0>: app_name 'ldp-1164-app',
my_client_index 0 (0x0)
ldp_init:209: ldp<1164>: configured LDP debug level (2) from env var
LDP_DEBUG!
ldp_init:282: ldp<1164>: LDP initialization: done!
ldp_constructor:2490: LDP<1164>: LDP constructor: done!
socket:974: ldp<1164>: calling vls_create: proto 1 (UDP), is_nonblocking 0
vppcom_session_create:1142: vcl<1164:0>: created session 0
bind:1086: ldp<1164>: fd 32: calling vls_bind: vlsh 0, addr 0x7fff9a93efe0,
len 28
vppcom_session_bind:1280: vcl<1164:0>: session 0 handle 0: binding to local
IPv6 address :: port 8092, proto UDP
vppcom_session_listen:1312: vcl<1164:0>: session 0: sending vpp listen
request...
vcl_session_bound_handler:610: vcl<1164:0>: session 0 [0x1]: listen
succeeded!
bind:1102: ldp<1164>: fd 32: returning 0

vpp# sh app server
Connection  App  Wrk
[0:0][CT:U] :::8092->:::0   ldp-1164-app[shm] 0
[#0][U] :::8092->:::0   ldp-1164-app[shm] 0

vpp# sh err
   CountNode  Reason
 7   dpdk-input   no error
  2606 ip6-udp-lookup no listener for dst port
 8arp-reply   ARP replies sent
 1  arp-disabled  ARP Disabled on this
interface
13ip6-glean   neighbor solicitations
sent
  2606ip6-input   valid ip6 packets
 4  ip6-local-hop-by-hop  Unknown protocol ip6
local h-b-h packets dropped
  2606 ip6-icmp-error destination unreachable
response sent
40 ip6-icmp-input valid packets
 1 ip6-icmp-input neighbor solicitations
from source not on link
12 ip6-icmp-input neighbor solicitations
for unknown targets
 1 ip6-icmp-input neighbor advertisements
sent
 1 ip6-icmp-input neighbor advertisements
received
40 ip6-icmp-input router advertisements sent
40 ip6-icmp-input router advertisements
received
 1 ip4-icmp-input echo replies sent
89   lldp-input   lldp packets received on
disabled interfaces
  1328llc-input   unknown llc ssap/dsap
vpp#

vpp# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:23:39:401354: dpdk-input
  HundredGigabitEthernet12/0/0 rx queue 0
  buffer 0x8894e: current data 0, length 1516, buffer-pool 0, ref-count 1,
totlen-nifb 0, trace handle 0x0
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 0, nb_segs 1, pkt_len 1516
buf_len 2176, data_len 1516, ol_flags 0x180, data_off 128, phys_addr
0x75025400
packet_type 0x2e1 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Offload Flags
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
  RTE_PTYPE_L3_IPV6_EXT_UNKNOWN (0x00e

Re: [vpp-dev] vpp crashes on deleting route 0.0.0.0/0 via interface #vpp

[Neale Ranns via Lists.Fd.Io]

Hi,

Thanks for the bug report, I’ll fix the crash.

A question for you.

DBGvpp# ip route add 0.0.0.0/0 table 10 via gre0


Says “all destinations in table 10 are reachable via an interface in table 0”. 
It implies therefore that all addresses in table 10 refer to the same device in 
table 0, i.e. there is no difference, or separation, between table 10 and 0. In 
other words it’s not something one normally does 😊
What’s your use case for this config?

Thanks,
Neale


From:  on behalf of "elantse...@yandex.ru" 

Date: Tuesday 14 January 2020 at 17:35
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] vpp crashes on deleting route 0.0.0.0/0 via interface #vpp


Hello Everyone!

I've encountered an issue with deleting route to 0.0.0.0/0 via some virtual 
interface: vpp crashed with a SIGABRT. This issue can be reproduced with gre 
interface on the current master 1c6486f7b8a00a1358d5c8f4ea1d874073bbcd6c:

DBGvpp# ip table add 10

DBGvpp# create gre tunnel src 1.1.1.1 dst 2.2.2.2

gre0



DBGvpp# ip route add 0.0.0.0/0 table 10 via gre0

DBGvpp# sh ip fib table 10

ipv4-VRF:10, fib_index:1, flow hash:[src dst sport dport proto ] epoch:0 
flags:none locks:[CLI:1, ]

0.0.0.0/0

  unicast-ip4-chain

  [@0]: dpo-load-balance: [proto:ip4 index:9 buckets:1 uRPF:12 to:[0:0]]

[0] [@0]: dpo-drop ip4

0.0.0.0/32

  unicast-ip4-chain

  [@0]: dpo-load-balance: [proto:ip4 index:10 buckets:1 uRPF:8 to:[0:0]]

[0] [@0]: dpo-drop ip4

224.0.0.0/4

  unicast-ip4-chain

  [@0]: dpo-load-balance: [proto:ip4 index:12 buckets:1 uRPF:10 to:[0:0]]

[0] [@0]: dpo-drop ip4

240.0.0.0/4

  unicast-ip4-chain

  [@0]: dpo-load-balance: [proto:ip4 index:11 buckets:1 uRPF:9 to:[0:0]]

[0] [@0]: dpo-drop ip4

255.255.255.255/32

  unicast-ip4-chain

  [@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:11 to:[0:0]]

[0] [@0]: dpo-drop ip4



/home/elantsev/vpp/src/vnet/fib/fib_attached_export.c:367 
(fib_attached_export_purge) assertion `NULL != fed' fails



Thread 1 "vpp_main" received signal SIGABRT, Aborted.

__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51

51   ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.



(gdb) bt

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51

#1  0x75ac9801 in __GI_abort () at abort.c:79

#2  0xbe0b in os_panic () at 
/home/elantsev/vpp/src/vpp/vnet/main.c:355

#3  0x75eacde9 in debugger () at 
/home/elantsev/vpp/src/vppinfra/error.c:84

#4  0x75ead1b8 in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0, fmt=0x77743bb8 "%s:%d (%s) assertion `%s' fails") at 
/home/elantsev/vpp/src/vppinfra/error.c:143

#5  0x774cbbe0 in fib_attached_export_purge (fib_entry=0x7fffb4bd2dd0) 
at /home/elantsev/vpp/src/vnet/fib/fib_attached_export.c:367

#6  0x774919de in fib_entry_post_flag_update_actions 
(fib_entry=0x7fffb4bd2dd0, old_flags=(FIB_ENTRY_FLAG_ATTACHED | 
FIB_ENTRY_FLAG_IMPORT)) at /home/elantsev/vpp/src/vnet/fib/fib_entry.c:674

#7  0x77491a3c in fib_entry_post_install_actions 
(fib_entry=0x7fffb4bd2dd0, source=FIB_SOURCE_DEFAULT_ROUTE, 
old_flags=(FIB_ENTRY_FLAG_ATTACHED | FIB_ENTRY_FLAG_IMPORT))

at /home/elantsev/vpp/src/vnet/fib/fib_entry.c:709

#8  0x77491d78 in fib_entry_post_update_actions 
(fib_entry=0x7fffb4bd2dd0, source=FIB_SOURCE_DEFAULT_ROUTE, 
old_flags=(FIB_ENTRY_FLAG_ATTACHED | FIB_ENTRY_FLAG_IMPORT))

at /home/elantsev/vpp/src/vnet/fib/fib_entry.c:804

#9  0x774923f9 in fib_entry_source_removed (fib_entry=0x7fffb4bd2dd0, 
old_flags=(FIB_ENTRY_FLAG_ATTACHED | FIB_ENTRY_FLAG_IMPORT)) at 
/home/elantsev/vpp/src/vnet/fib/fib_entry.c:992

#10 0x774925e7 in fib_entry_path_remove (fib_entry_index=7, 
source=FIB_SOURCE_CLI, rpaths=0x7fffb83a3520) at 
/home/elantsev/vpp/src/vnet/fib/fib_entry.c:1072

#11 0x7747980b in fib_table_entry_path_remove2 (fib_index=1, 
prefix=0x7fffb8382b00, source=FIB_SOURCE_CLI, rpaths=0x7fffb83a3520) at 
/home/elantsev/vpp/src/vnet/fib/fib_table.c:680

#12 0x76fb870c in vnet_ip_route_cmd (vm=0x766b6680 
, main_input=0x7fffb8382f00, cmd=0x7fffb50373b8) at 
/home/elantsev/vpp/src/vnet/ip/lookup.c:449

#13 0x763d402f in vlib_cli_dispatch_sub_commands (vm=0x766b6680 
, cm=0x766b68b0 , 
input=0x7fffb8382f00, parent_command_index=431)

at /home/elantsev/vpp/src/vlib/cli.c:568

#14 0x763d3ead in vlib_cli_dispatch_sub_commands (vm=0x766b6680 
, cm=0x766b68b0 , 
input=0x7fffb8382f00, parent_command_index=0)

at /home/elantsev/vpp/src/vlib/cli.c:528

#15 0x763d4434 in vlib_cli_input (vm=0x766b6680 , 
input=0x7fffb8382f00, function=0x7646dc89 , 
function_arg=0) at /home/elantsev/vpp/src/vlib/cli.c:667

#16 0x7647476d in unix_cli_process_input (cm=0x766b7020 
, cli_file_index=0) at 
/home/elantsev/vpp/src/vlib/unix/cli.c:2572

#17 0x7647540e in unix_cli_process (vm=0x766b6680 
, rt=0x7fffb8342000

Re: [vpp-dev] Arm verify job broken

[Ed Kern via Lists.Fd.Io]

short answer: fixed..


longer answer:  a ci-management patch which did a whole bunch of cleanup and 
readability improvements accidentally
separated two scripts that had to stay together.  Having the script apart meant 
arm was using only 1 core instead
of the correct number of 16 cores.

This lead to all arm jobs answering the question ‘what does a yellow light 
mean’  (apologies to those that miss the taxi reference)

ci-man patch being merged now…all subsequent jobs should be back to normal 
timing.

Ed



On Jan 14, 2020, at 1:54 PM, Andrew 👽 Yourtchenko 
mailto:ayour...@gmail.com>> wrote:

better to debug some before changing anything.

With my RM hat on I would rather understand what is going on, if it is 24 hours 
before the RC1 milestone ;-)

--a

On 14 Jan 2020, at 21:28, Ed Kern via Lists.Fd.Io 
mailto:ejk=cisco@lists.fd.io>> wrote:

 ok FOR THE MOST PART…  build times haven’t changed  (@20 min)

make test portion has gone off the chain and is often hitting the 120 min build 
timeout threshold.

Ive currently got several jobs running on sandbox testing

a. without any timeouts (just to see if we are still passing on master)
b. three different memory and disk profiles (just in case someone/thing got 
messy and we have had another memory spike)

the bad news is that it will be at least a couple of hours more than likely 
before I get any results that I feel are actionable.


Having said that im happy to shoot the build timeout for the time being if 
committers feel that is warranted to ‘keep the train rolling’

Ed




On Jan 14, 2020, at 1:07 PM, Florin Coras 
mailto:fcoras.li...@gmail.com>> wrote:

Thanks, Ed!

Florin

On Jan 14, 2020, at 11:53 AM, Ed Kern (ejk) 
mailto:e...@cisco.com>> wrote:

looking into it now…..

its a strange one ill tell you that up front…failures are all over the place 
inside the build and even some hitting the 120 min timeout….

more as i dig hopefully

thanks for the ping

Ed



On Jan 14, 2020, at 11:40 AM, Florin Coras 
mailto:fcoras.li...@gmail.com>> wrote:

Hi,

Jobs have been failing since yesterday. Did anybody try to look into it?

Regards,
Florin






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

View/Reply Online (#15173): https://lists.fd.io/g/vpp-dev/message/15173
Mute This Topic: https://lists.fd.io/mt/69698855/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] Arm verify job broken

[Christian Hopps]

> On Jan 14, 2020, at 6:27 PM, Ed Kern via Lists.Fd.Io 
>  wrote:
> 
> short answer: fixed..
> 
> 
> longer answer:  a ci-management patch which did a whole bunch of cleanup and 
> readability improvements accidentally 
> separated two scripts that had to stay together.  Having the script apart 
> meant arm was using only 1 core instead
> of the correct number of 16 cores.
> 
> This lead to all arm jobs answering the question ‘what does a yellow light 
> mean’  (apologies to those that miss the taxi reference)

Now that's a blast from the past... :)

Thanks,
Chris.


> 
> ci-man patch being merged now…all subsequent jobs should be back to normal 
> timing.
> 
> Ed
> 
> 
> 
>> On Jan 14, 2020, at 1:54 PM, Andrew 👽 Yourtchenko  wrote:
>> 
>> better to debug some before changing anything.
>> 
>> With my RM hat on I would rather understand what is going on, if it is 24 
>> hours before the RC1 milestone ;-) 
>> 
>> --a
>> 
>>> On 14 Jan 2020, at 21:28, Ed Kern via Lists.Fd.Io 
>>>  wrote:
>>> 
>>>  ok FOR THE MOST PART…  build times haven’t changed  (@20 min)
>>> 
>>> make test portion has gone off the chain and is often hitting the 120 min 
>>> build timeout threshold.
>>> 
>>> Ive currently got several jobs running on sandbox testing
>>> 
>>> a. without any timeouts (just to see if we are still passing on master)
>>> b. three different memory and disk profiles (just in case someone/thing got 
>>> messy and we have had another memory spike)
>>> 
>>> the bad news is that it will be at least a couple of hours more than likely 
>>> before I get any results that I feel are actionable.
>>> 
>>> 
>>> Having said that im happy to shoot the build timeout for the time being if 
>>> committers feel that is warranted to ‘keep the train rolling’
>>> 
>>> Ed
>>> 
>>> 
>>> 
>>> 
 On Jan 14, 2020, at 1:07 PM, Florin Coras  wrote:
 
 Thanks, Ed!
 
 Florin
 
> On Jan 14, 2020, at 11:53 AM, Ed Kern (ejk)  wrote:
> 
> looking into it now…..
> 
> its a strange one ill tell you that up front…failures are all over the 
> place inside the build and even some hitting the 120 min timeout….
> 
> more as i dig hopefully
> 
> thanks for the ping
> 
> Ed
> 
> 
> 
>> On Jan 14, 2020, at 11:40 AM, Florin Coras  
>> wrote:
>> 
>> Hi, 
>> 
>> Jobs have been failing since yesterday. Did anybody try to look into it?
>> 
>> Regards,
>> Florin
>> 
> 
 
>>> 
>>> 
> 
> 

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

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

[vpp-dev] vnet_gso_header_offset_parser error if vlib_buffer_t without ethernet_header_t

[jiangxiaoming]

vlib_buffer_t has no ethernet_header_t, *vnet_gso_header_offset_parser* ** will 
failed.
I think if vlib_buffer_t valid l2 header, vnet_gso_header_offset_parser should 
skip *ethernet_header_t* parse.
Below is the VPP crash message:

> 
> 0: /home/dev/code/net-base/build/vpp/src/vnet/ip/ip.h:205
> (ip_calculate_l4_checksum) assertion `ip_header_size' fails
> 
> Program received signal SIGABRT, Aborted.
> 0x74a1d337 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:55
> 55    return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
> (gdb) bt
> #0  0x74a1d337 in __GI_raise (sig=sig@entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:55
> #1  0x74a1ea28 in __GI_abort () at abort.c:90
> #2  0x00407458 in os_panic () at
> /home/dev/code/net-base/build/vpp/src/vpp/vnet/main.c:355
> #3  0x75864d1f in debugger () at
> /home/dev/code/net-base/build/vpp/src/vppinfra/error.c:84
> #4  0x758650ee in _clib_error (how_to_die=2, function_name=0x0,
> line_number=0, fmt=0x776abc88 "%s:%d (%s) assertion `%s' fails") at
> /home/dev/code/net-base/build/vpp/src/vppinfra/error.c:143
> #5  0x76ed5472 in ip_calculate_l4_checksum (vm=0x766aa640
> , p0=0x103fdada00, sum0=189151184350281389,
> payload_length=2560, iph=0x103fdadb5e "", ip_header_size=0, l4h=0x0) at
> /home/dev/code/net-base/build/vpp/src/vnet/ip/ip.h:205
> #6  0x76edd92f in ip4_tcp_udp_compute_checksum (vm=0x766aa640
> , p0=0x103fdada00, ip0=0x103fdadb5e) at
> /home/dev/code/net-base/build/vpp/src/vnet/ip/ip4_forward.c:1328
> #7  0x76ca5772 in calc_checksums (vm=0x766aa640
> , b=0x103fdada00) at
> /home/dev/code/net-base/build/vpp/src/vnet/interface_output.c:189
> #8  0x76ca64fc in vnet_interface_output_node_inline
> (vm=0x766aa640 , node=0x7fffd71a3cc0,
> frame=0x7fffd7936b40, vnm=0x77b6a9c0 , hi=0x7fffd78848c0,
> do_tx_offloads=1) at
> /home/dev/code/net-base/build/vpp/src/vnet/interface_output.c:450
> #9  0x76ca67ff in vnet_interface_output_node (vm=0x766aa640
> , node=0x7fffd71a3cc0, frame=0x7fffd7936b40) at
> /home/dev/code/net-base/build/vpp/src/vnet/interface_output.c:542
> #10 0x76408776 in dispatch_node (vm=0x766aa640
> , node=0x7fffd71a3cc0, type=VLIB_NODE_TYPE_INTERNAL,
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7fffd7936b40,
> last_time_stamp=64570511102008) at
> /home/dev/code/net-base/build/vpp/src/vlib/main.c:1208
> #11 0x76408f37 in dispatch_pending_node (vm=0x766aa640
> , pending_frame_index=2, last_time_stamp=64570511102008)
> at /home/dev/code/net-base/build/vpp/src/vlib/main.c:1376
> #12 0x7640ab9a in vlib_main_or_worker_loop (vm=0x766aa640
> , is_main=1) at
> /home/dev/code/net-base/build/vpp/src/vlib/main.c:1833
> #13 0x7640b3df in vlib_main_loop (vm=0x766aa640
> ) at
> /home/dev/code/net-base/build/vpp/src/vlib/main.c:1934
> #14 0x7640c0a7 in vlib_main (vm=0x766aa640 ,
> input=0x7fffd6c8afb0) at
> /home/dev/code/net-base/build/vpp/src/vlib/main.c:2151
> #15 0x76471bdc in thread0 (arg=140737327572544) at
> /home/dev/code/net-base/build/vpp/src/vlib/unix/main.c:650
> #16 0x75884ef4 in clib_calljmp () at
> /home/dev/code/net-base/build/vpp/src/vppinfra/longjmp.S:123
> #17 0x7fffd070 in ?? ()
> #18 0x76472152 in vlib_unix_main (argc=181, argv=0x700fa0) at
> /home/dev/code/net-base/build/vpp/src/vlib/unix/main.c:720
> #19 0x00406dcc in main (argc=181, argv=0x700fa0) at
> /home/dev/code/net-base/build/vpp/src/vpp/vnet/main.c:280
> (gdb) up 7
> (gdb) l
> 194   else if (is_ip6)
> 195     {
> 196       int bogus;
> 197       ip6_header_t *ip6;
> 198
> 199       ip6 =
> 200     (ip6_header_t *) (vlib_buffer_get_current (b) +
> gho.l3_hdr_offset);
> 201       if (b->flags & VNET_BUFFER_F_OFFLOAD_TCP_CKSUM)
> 202     {
> 203       th->checksum = 0;
> (gdb)
> 204       th->checksum =
> 205         ip6_tcp_udp_icmp_compute_checksum (vm, b, ip6, &bogus);
> 206     }
> 207       else if (b->flags & VNET_BUFFER_F_OFFLOAD_UDP_CKSUM)
> 208     {
> 209       uh->checksum = 0;
> 210       uh->checksum =
> 211         ip6_tcp_udp_icmp_compute_checksum (vm, b, ip6, &bogus);
> 212     }
> 213     }
> (gdb)
> 214   b->flags &= ~VNET_BUFFER_F_OFFLOAD_TCP_CKSUM;
> 215   b->flags &= ~VNET_BUFFER_F_OFFLOAD_UDP_CKSUM;
> 216   b->flags &= ~VNET_BUFFER_F_OFFLOAD_IP_CKSUM;
> 217 }
> 218
> 219 static_always_inline uword
> 220 vnet_interface_output_node_inline (vlib_main_t * vm,
> 221                    vlib_node_runtime_t * node,
> 222                    vlib_frame_t * frame,
> 223                    vnet_main_t * vnm,
> (gdb) print b[0]
> $20 = {{cacheline0 = 0x103fdada00 "P", current_data = 80, current_length =
> 60, flags = 23265280, flow_id = 0, ref_count = 1 '\001', buffer_pool_index
> = 0 '\000', error = 0, next_buffer = 0, {current_config_index = 0,
> punt_reason = 0}, opaque = {0, 3, 5242880, 100, 0, 3, 0, 0, 0, 0},
> templat

Re: [vpp-dev] #vpp-hoststack - Issue with UDP receiver application using VCL library

[Florin Coras]

Hi Raj, 

First of all, with this [1], the vcl test app/client can establish a udpc 
connection. Note that udp will most probably lose packets, so large exchanges 
with those apps may not work. 

As for the second issue, does [2] solve it?

Regards, 
Florin

[1] https://gerrit.fd.io/r/c/vpp/+/24332 
[2] https://gerrit.fd.io/r/c/vpp/+/24334 

> On Jan 14, 2020, at 12:59 PM, Raj Kumar  wrote:
> 
> Hi Florin,
> Thanks! for the reply. 
> 
> I realized the issue with the non-connected case.  For receiving datagrams, I 
> was using recvfrom() with DONOT_WAIT flag because of that  
> vppcom_session_recvfrom() api was failing. It expects either 0 or MSG_PEEK 
> flag.
>   if (flags == 0)
> rv = vppcom_session_read (session_handle, buffer, buflen);
>   else if (flags & MSG_PEEK) 0x2
> rv = vppcom_session_peek (session_handle, buffer, buflen);
>   else
> {
>   VDBG (0, "Unsupport flags for recvfrom %d", flags);
>   return VPPCOM_EAFNOSUPPORT;
> }
> 
>  I changed the flag to 0 in recvfrom() , after that UDP rx is working fine 
> but only for IPv4.
> 
> I am facing a different issue with IPv6/UDP receiver.  I am getting "no 
> listener for dst port" error.
>
> Please let me know if I am doing something wrong. 
> Here are the traces : -
> 
> [root@orc01 testcode]# VCL_DEBUG=2 LDP_DEBUG=2 
> LD_PRELOAD=/opt/vpp/build-root/install-vpp-native/vpp/lib/libvcl_ldpreload.so 
>  VCL_CONFIG=/etc/vpp/vcl.cfg ./udp6_rx
> VCL<1164>: configured VCL debug level (2) from VCL_DEBUG!
> VCL<1164>: allocated VCL heap = 0x7ff877439010, size 268435456 (0x1000)
> VCL<1164>: configured rx_fifo_size 400 (0x3d0900)
> VCL<1164>: configured tx_fifo_size 400 (0x3d0900)
> VCL<1164>: configured app_scope_local (1)
> VCL<1164>: configured app_scope_global (1)
> VCL<1164>: configured api-socket-name (/tmp/vpp-api.sock)
> VCL<1164>: completed parsing vppcom config!
> vppcom_connect_to_vpp:549: vcl<1164:0>: app (ldp-1164-app) is connected to 
> VPP!
> vppcom_app_create:1067: vcl<1164:0>: sending session enable
> vppcom_app_create:1075: vcl<1164:0>: sending app attach
> vppcom_app_create:1084: vcl<1164:0>: app_name 'ldp-1164-app', my_client_index 
> 0 (0x0)
> ldp_init:209: ldp<1164>: configured LDP debug level (2) from env var 
> LDP_DEBUG!
> ldp_init:282: ldp<1164>: LDP initialization: done!
> ldp_constructor:2490: LDP<1164>: LDP constructor: done!
> socket:974: ldp<1164>: calling vls_create: proto 1 (UDP), is_nonblocking 0
> vppcom_session_create:1142: vcl<1164:0>: created session 0
> bind:1086: ldp<1164>: fd 32: calling vls_bind: vlsh 0, addr 0x7fff9a93efe0, 
> len 28
> vppcom_session_bind:1280: vcl<1164:0>: session 0 handle 0: binding to local 
> IPv6 address :: port 8092, proto UDP
> vppcom_session_listen:1312: vcl<1164:0>: session 0: sending vpp listen 
> request...
> vcl_session_bound_handler:610: vcl<1164:0>: session 0 [0x1]: listen succeeded!
> bind:1102: ldp<1164>: fd 32: returning 0
> 
> vpp# sh app server
> Connection  App  Wrk
> [0:0][CT:U] :::8092->:::0   ldp-1164-app[shm] 0
> [#0][U] :::8092->:::0   ldp-1164-app[shm] 0
> 
> vpp# sh err
>CountNode  Reason
>  7   dpdk-input   no error
>   2606 ip6-udp-lookup no listener for dst port
>  8arp-reply   ARP replies sent
>  1  arp-disabled  ARP Disabled on this 
> interface
> 13ip6-glean   neighbor solicitations sent
>   2606ip6-input   valid ip6 packets
>  4  ip6-local-hop-by-hop  Unknown protocol ip6 local 
> h-b-h packets dropped
>   2606 ip6-icmp-error destination unreachable 
> response sent
> 40 ip6-icmp-input valid packets
>  1 ip6-icmp-input neighbor solicitations from 
> source not on link
> 12 ip6-icmp-input neighbor solicitations for 
> unknown targets
>  1 ip6-icmp-input neighbor advertisements sent
>  1 ip6-icmp-input neighbor advertisements 
> received
> 40 ip6-icmp-input router advertisements sent
> 40 ip6-icmp-input router advertisements 
> received
>  1 ip4-icmp-input echo replies sent
> 89   lldp-input   lldp packets received on 
> disabled interfaces
>   1328llc-input   unknown llc ssap/dsap
> vpp#
> 
> vpp# show trace
> --- Start of thread 0 vpp_main ---
> Packet 1
> 
> 00:23:39:401354: dpdk-input
>   HundredGigabitEthernet12/0/0 rx queue

[vpp-dev] Packet not going to Classifier & action #classify #vpp #flowprobe #vppwithoutdpdk

[cspoyau]

Hi Everyone,

I would like to use vpp classifier to classify the packet (l3 ip4 src & dst, l4 
port) and deliver to desired destination by defined rules.

1. iPerf traffic (vpp1) ---memory interface-> vpp2
2. vpp2 classify the src port of the traffic. src port 12300 goes to TAP 0, src 
port 12399 goes to vpp3 via memif 0/3

Topology as below,

Packet dropped in vpp2 & not going anywhere..

Trace as below

Packet 1

00:04:30:392423: memif-input
memif: hw_if_index 2 next-index 4
slot: ring 0
00:04:30:392444: ethernet-input
IP4: b2:5f:84:5e:0b:43 -> 9e:db:96:ff:25:fa
00:04:30:392460: error-drop
rx:memif0/2
00:04:30:392462: drop
ethernet-input: l3 mac mismatch

vpp# show ip fib
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] 
locks:[src:plugin-hi:2, src:default-route:1, ]
0.0.0.0/0
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:1 buckets:1 uRPF:0 to:[0:0]]
[0] [@0]: dpo-drop ip4
0.0.0.0/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:2 buckets:1 uRPF:1 to:[0:0]]
[0] [@0]: dpo-drop ip4
10.10.2.0/24
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:22 buckets:1 uRPF:20 to:[0:0]]
[0] [@12]: ip4-classify:[0]:table:0
10.10.2.1/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:21 buckets:1 uRPF:19 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.2.1 memif0/2
224.0.0.0/4
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:4 buckets:1 uRPF:3 to:[0:0]]
[0] [@0]: dpo-drop ip4
240.0.0.0/4
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:3 buckets:1 uRPF:2 to:[0:0]]
[0] [@0]: dpo-drop ip4
255.255.255.255/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:5 buckets:1 uRPF:4 to:[0:0]]
[0] [@0]: dpo-drop ip4
ipv4-VRF:100, fib_index:1, flow hash:[src dst sport dport proto ] 
locks:[src:classify:1, ]
0.0.0.0/0
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:9 buckets:1 uRPF:7 to:[0:0]]
[0] [@0]: dpo-drop ip4
0.0.0.0/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:10 buckets:1 uRPF:8 to:[0:0]]
[0] [@0]: dpo-drop ip4
10.10.2.2/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:19 buckets:1 uRPF:17 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.2.2 memif0/3
224.0.0.0/4
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:12 buckets:1 uRPF:10 to:[0:0]]
[0] [@0]: dpo-drop ip4
240.0.0.0/4
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:11 buckets:1 uRPF:9 to:[0:0]]
[0] [@0]: dpo-drop ip4
255.255.255.255/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:11 to:[0:0]]
[0] [@0]: dpo-drop ip4
ipv4-VRF:200, fib_index:2, flow hash:[src dst sport dport proto ] 
locks:[src:classify:1, ]
0.0.0.0/0
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:14 buckets:1 uRPF:12 to:[0:0]]
[0] [@0]: dpo-drop ip4
0.0.0.0/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:15 buckets:1 uRPF:13 to:[0:0]]
[0] [@0]: dpo-drop ip4
10.10.2.2/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:20 buckets:1 uRPF:18 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.2.2 tap0
224.0.0.0/4
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:17 buckets:1 uRPF:15 to:[0:0]]
[0] [@0]: dpo-drop ip4
240.0.0.0/4
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:16 buckets:1 uRPF:14 to:[0:0]]
[0] [@0]: dpo-drop ip4
255.255.255.255/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:18 buckets:1 uRPF:16 to:[0:0]]
[0] [@0]: dpo-drop ip4
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Re: [vpp-dev] Packet not going to Classifier & action #classify #vpp #flowprobe #vppwithoutdpdk

[Neale Ranns via Lists.Fd.Io]

Hi,

[snip]

Trace as below
Packet 1

00:04:30:392423: memif-input
  memif: hw_if_index 2 next-index 4
slot: ring 0
00:04:30:392444: ethernet-input
  IP4: b2:5f:84:5e:0b:43 -> 9e:db:96:ff:25:fa
00:04:30:392460: error-drop
  rx:memif0/2
00:04:30:392462: drop
  ethernet-input: l3 mac mismatch

the packet was dropped because its destination MAC does not match the MAC 
configured on the ingress interface.
/neale

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

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

Re: [vpp-dev] Packet not going to Classifier & action #classify #vpp #flowprobe #vppwithoutdpdk

[Po]

Hi neale,

I set the memif0/2 as the arp proxy, with addr: 10.10.2.0/24.
It goes to "ip4-flow-classify" but becomes misses...

vpp# create tap id 0
tap0
vpp# create interface memif id 2 slave
vpp# create interface memif id 3 slave
vpp# set interface state memif0/2 up
vpp# set interface state memif0/3 up
vpp# set int state tap0 up
vpp# classify table mask hex 
00ff buckets 16
vpp# classify session opaque-index 0 table-index 0 match hex 
00060a0a02010a0a0202300c action 
set-ip4-fib-id 100
vpp# classify session opaque-index 1 table-index 0 match hex 
00060a0a02010a0a0202306f action 
set-ip4-fib-id 200
vpp# ip route add 10.10.2.2/32 table 100 via memif0/3
vpp# ip route add 10.10.2.2/32 table 200 via tap0
vpp# ip route add 10.10.2.1/32 via memif0/2
vpp# ip route add 10.10.2.0/24 via classify 0
vpp# set flow classify interface memif0/2 ip4-table 0

vpp# set int ip address memif0/2 10.10.2.0/24

vpp# set ip arp proxy 10.10.2.1 - 10.10.2.11
vpp# set interface proxy-arp memif0/2 enable

vpp# trace add memif-input 20
vpp#

#
ip addr add dev tap0 10.10.2.2/24

 Before test
vpp# show err
Count                    Node                  Reason
8                arp-proxy               ARP replies sent
117             ethernet-input             no error

 After test
vpp# show err
Count                    Node                  Reason
9                arp-proxy               ARP replies sent
6                ip4-glean               ARP requests sent
6 *ip4-flow-classify           Flow classify misses*
117             ethernet-input             no error

vpp# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:26:33:904177: memif-input
memif: hw_if_index 2 next-index 4
slot: ring 0
00:26:33:904194: ethernet-input
IP4: b2:5f:84:5e:0b:43 -> 02:fe:5f:e8:9a:43
00:26:33:904204: ip4-input
TCP: 10.10.2.1 -> 10.10.2.2
tos 0x00, ttl 64, length 60, checksum 0xaa35
fragment id 0x7870, flags DONT_FRAGMENT
TCP: 12399 -> 12345
seq. 0xdb5ba86d ack 0x
flags 0x02 SYN, tcp header: 40 bytes
window 29200, checksum 0x712e
00:26:33:913725: *ip4-flow-classify*
FLOW_CLASSIFY: sw_if_index 2 next 1 table 0 offset -1
00:26:33:913764: ip4-lookup
fib 0 dpo-idx 3 flow hash: 0x
TCP: 10.10.2.1 -> 10.10.2.2
tos 0x00, ttl 64, length 60, checksum 0xaa35
fragment id 0x7870, flags DONT_FRAGMENT
TCP: 12399 -> 12345
seq. 0xdb5ba86d ack 0x
flags 0x02 SYN, tcp header: 40 bytes
window 29200, checksum 0x712e
00:26:33:948054: ip4-glean
TCP: 10.10.2.1 -> 10.10.2.2
tos 0x00, ttl 64, length 60, checksum 0xaa35
fragment id 0x7870, flags DONT_FRAGMENT
TCP: 12399 -> 12345
seq. 0xdb5ba86d ack 0x
flags 0x02 SYN, tcp header: 40 bytes
window 29200, checksum 0x712e
00:26:33:948069: memif0/2-output
memif0/2
ARP: 02:fe:5f:e8:9a:43 -> ff:ff:ff:ff:ff:ff
request, type ethernet/IP4, address size 6/4
02:fe:5f:e8:9a:43/10.10.2.0 -> 00:00:00:00:00:00/10.10.2.2
00:26:33:948072: error-drop
rx:memif0/2
00:26:33:948076: drop
ip4-glean: ARP requests sent

Packet 2

00:26:34:893852: memif-input
memif: hw_if_index 2 next-index 4
slot: ring 0
00:26:34:893859: ethernet-input
IP4: b2:5f:84:5e:0b:43 -> 02:fe:5f:e8:9a:43
00:26:34:893863: ip4-input
TCP: 10.10.2.1 -> 10.10.2.2
tos 0x00, ttl 64, length 60, checksum 0xaa34
fragment id 0x7871, flags DONT_FRAGMENT
TCP: 12399 -> 12345
seq. 0xdb5ba86d ack 0x
flags 0x02 SYN, tcp header: 40 bytes
window 29200, checksum 0x6d44
00:26:34:893867: ip4-flow-classify
FLOW_CLASSIFY: sw_if_index 2 next 1 table 0 offset -1
00:26:34:893873: ip4-lookup
fib 0 dpo-idx 3 flow hash: 0x
TCP: 10.10.2.1 -> 10.10.2.2
tos 0x00, ttl 64, length 60, checksum 0xaa34
fragment id 0x7871, flags DONT_FRAGMENT
TCP: 12399 -> 12345
seq. 0xdb5ba86d ack 0x
flags 0x02 SYN, tcp header: 40 bytes
window 29200, checksum 0x6d44
00:26:34:893876: ip4-glean
TCP: 10.10.2.1 -> 10.10.2.2
tos 0x00, ttl 64, length 60, checksum 0xaa34
fragment id 0x7871, flags DONT_FRAGMENT
TCP: 12399 -> 12345
seq. 0xdb5ba86d ack 0x
flags 0x02 SYN, tcp header: 40 bytes
window 29200, checksum 0x6d44
00:26:34:893879: memif0/2-output
memif0/2
ARP: 02:fe:5f:e8:9a:43 -> ff:ff:ff:ff:ff:ff
request, type ethernet/IP4, address size 6/4
02:fe:5f:e8:9a:43/10.10.2.0 -> 00:00:00:00:00:00/10.10.2.2
00:26:34:893880: error-drop
rx:memif0/2
00:26:34:893883: drop
ip4-glean: ARP requests sent

Packet 3

00:26:36:921068: memif-input
memif: hw_if_index 2 next-index 4
slot: ring 0
00:26:36:921077: ethernet-input
IP4: b2:5f:84:5e:0b:43 -> 02:fe:5f:e8:9a:43
00:26:36:921081: ip4-input
TCP: 10.10.2.1 -> 10.10.2.2
tos 0x00, ttl 64, length 60, checksum 0xaa33
fragment id 0x7872, flags DONT_FRAGMENT
TCP: 12399 -> 12345
seq. 0xdb5ba86d ack 0x
flags 0x02 SYN, tcp header: 40 bytes
window 29200, checksum 0x6564
00:26:36:921085: ip4-flow-classify
FLOW_CLASSIFY: sw_if_index 2 next 1 table 0 offset -1
00:2