Re: [vpp-dev] mpls tunnel

Hi, This: XXX via via 1.1.1.1 ip4-lookup-in-table 0 out-labels 33 is not a valid path. If you want packets to follow the same path as for 1.1.1.1 (i.e. the path is recursive via 1.1.1.1, and you’ll need a route in the fib for 1.1.1.1) and have label 33 imposed, do: XXX via via 1.1.1.1

[vpp-dev] vlib_buffer_clone and vlib_buffer_clone_attach #vpp

Hi, Please help me out in understanding the usage of vlib_buffer_clone and  vlib_buffer_clone_attach. Is there a packet copy involved in vlib_buffer_clone, internally it calls  vlib_buffer_copy. Can we retains the packet buffer for some other node processing, something like ref_count logic but

Re: [vpp-dev] gerrit.fd.io very slow?

It’s slow on my end as well. Florin > On Jun 20, 2018, at 8:21 AM, Dave Barach via Lists.Fd.Io > wrote: > > Before I start bugging the LF: is anyone else noticing bad performance w/ > gerrit.fd.io ? > > Thanks... Dave > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive

Re: [vpp-dev] gerrit.fd.io very slow?

On Wed, Jun 20, 2018 at 5:22 PM Dave Barach via Lists.Fd.Io wrote: > Before I start bugging the LF: is anyone else noticing bad performance w/ > gerrit.fd.io? > Their status page shows an LDAP issue: https://status.linuxfoundation.org -Lori > > > Thanks... Dave > > > > >

[vpp-dev] gerrit.fd.io very slow?

Before I start bugging the LF: is anyone else noticing bad performance w/ gerrit.fd.io? Thanks... Dave -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9659): https://lists.fd.io/g/vpp-dev/message/9659 Mute This Topic:

Re: [vpp-dev] FD.io Docs Working Group

Folks, Apologies, one minor correction to my last mail. The meeting is at 7am PST on Fridays, on even week numbers. Thanks, Ray K -Original Message- From: Kinsella, Ray Sent: Wednesday 20 June 2018 11:15 To: vpp-dev@lists.fd.io; t...@lists.fd.io; csit-...@lists.fd.io;

Re: [vpp-dev] tcp connection

I found the problem. I was using the loopback interface of linux as loopback of VPP which is not correct, since it is not recognized in VPP. So packet are dropped in ip4-lookup node. I thought that it is the problem in tcp because I was sending tcp SYN without VPP's awareness of this sending. But

[vpp-dev] mpls tunnel

Hi, My topology is: *R1 (192.168.1.1/24 )* <-->* R2 (192.168.1.2/24 )* and *R1 loopback interface* has IP address of *1.1.1.1/32 * == I have configured VPP's mpls tunnel as

Re: [vpp-dev] new anomaly detection

> we are planning to replace the old graphs by new graphs > (and delete [1]) some time next week, > depending on the feedback we get. The feedback was non-negative, so we are going ahead. Expect the new content to appear on the old URL [0] around one hour from now. Vratko. From: Vratko Polak

Re: [vpp-dev] Mutex Deadlock

Thank you Dave! Your reply sounds good. On Wed, Jun 20, 2018 at 5:00 PM, Dave Barach (dbarach) wrote: > If either vpp or client dies with the svm mutex held, the condition you > show can occur. Even marginally well-behaved code won’t cause this > condition, so I’d suggest that you fix the

Re: [vpp-dev] Mutex Deadlock

If either vpp or client dies with the svm mutex held, the condition you show can occur. Even marginally well-behaved code won’t cause this condition, so I’d suggest that you fix the underlying problem. To get going again: “rm /dev/shm/{global_vm,vpe-api}” to clean up the mess. Note that the

[vpp-dev] Review of DPDK no-hugetbl configuration patch

Hello, I submitted a patch a few weeks ago to fix an issue where configuring VPP would fail to start with this configuration: dpdk { no-hugetbl } I'm wondering if someone would mind reviewing my patch for me? The issues is: https://jira.fd.io/browse/VPP-1042. Also I'm wondering if there

[vpp-dev] Mutex Deadlock

Hi , I am facing some mutex deadlock between Client application and vpp. So for example we see Client App attempt the connect and invoke vl_client_connect grabs the pthread_mutex_lock (>mutex); then subsequently dies later due to some reason. We then have VPP hanging in dead_client_scan and

[vpp-dev] FD.io Docs Working Group

Hi all, A number of us are collaborating in a working group to improve the overall quality of FD.io documentation. The documentation working group is intended to supplement, but not to replace the documentation efforts in individual subprojects. It is an effort to address some key gaps we have