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

2020-01-14 Thread 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

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

2020-01-14 Thread 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

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

2020-01-14 Thread 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

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

2020-01-14 Thread 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

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

2020-01-14 Thread 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):

[vpp-dev] Arm verify job broken

2020-01-14 Thread 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:

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

2020-01-14 Thread 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 >

[vpp-dev] VPP / Calico integration announcement

2020-01-14 Thread 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

Re: [vpp-dev] Arm verify job broken

2020-01-14 Thread 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:

Re: [vpp-dev] Arm verify job broken

2020-01-14 Thread 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.

Re: [vpp-dev] Arm verify job broken

2020-01-14 Thread 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) >

[vpp-dev] Reminder: 20.01 RC1 is tomorrow

2020-01-14 Thread 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

Re: [vpp-dev] Arm verify job broken

2020-01-14 Thread 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

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

2020-01-14 Thread 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 =

Re: [vpp-dev] Arm verify job broken

2020-01-14 Thread 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

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

2020-01-14 Thread 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,

Re: [vpp-dev] Arm verify job broken

2020-01-14 Thread 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

[vpp-dev] vnet_gso_header_offset_parser error if vlib_buffer_t without ethernet_header_t

2020-01-14 Thread 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 >

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

2020-01-14 Thread 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]

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

2020-01-14 Thread 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

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

2020-01-14 Thread 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

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

2020-01-14 Thread 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

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

2020-01-14 Thread 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