Re: [vpp-dev] User-space TCP Stack

Hi Stephen, The goal is to have a complete userspace stack, i.e., a session layer accessible over VPP’s binary API, a transport layer, a POSIX-like wrapper library for interacting with the stack and a shared memory mechanism to pass data between apps and VPP. We have support for pluggable

Re: [vpp-dev] Spurious make test failure (container POC)

klement, ok…ill think about how to do that without too much trouble in its current state.. in the meantime…blowing out the cpu and memory a bit changed the error…… 21:49:42 create 1k of p2p subifs OK 21:49:42

[vpp-dev] Load-balancer plugin Question

Hi, We are using VPP 1707 and the load balancer plugin. We have only one public IP available for the load balancer VM and we use this IP as VIP. In the VPP 1609, we were able to assign the same VIP to the public interface and everything worked fine. However, in VPP 1707, the behaviour has

Re: [vpp-dev] https://gerrit.fd.io/r/#/c/7856/ Review gerrit please

I saw it. Thanks, --Tom On 08/08/2017 11:29 AM, Neale Ranns (nranns) wrote: Merged. Thanks, neale *From: * on behalf of Thomas F Herbert *Date: *Tuesday, 8 August 2017 at 16:05 *To: *vpp-dev

Re: [vpp-dev] Spurious make test failure (container POC)

Ed, it'd help if you could collect log.txt from a failed run so we could peek under the hood... please see my other email in this thread... Thanks, Klement Quoting Ed Kern (ejk) (2017-08-09 20:48:46) >this is not you…or this patch… >the make test-debug has had a 90+% failure rate (read

Re: [vpp-dev] Spurious make test failure (container POC)

Hi Dave, this looks like something got stuck - and the only thing I know which can get the framework stuck like this is if vpp coredumps mid-API, in which case, python gets stuck doing unix_shared_memory_queue_sub(). I actually pushed a patch today, which makes the test framework to fork at start

Re: [vpp-dev] Spurious make test failure (container POC)

this is not you…or this patch… the make test-debug has had a 90+% failure rate (read not 100%) for at least the last 100 builds (far back as my current logs go but will probably blow that out a bit now) you hit the one that is seen most often… on that create 1k of p2p subifs the other much

Re: [vpp-dev] Configuring multiple VFRs

Hi Neale, Indeed, it worked in 1707! I used 1609 previously. Thanks a lot! Michael. On Wed, Aug 9, 2017 at 2:20 PM, Neale Ranns (nranns) wrote: > Hi Michael, > > > > Those configs will work with newer versions of VPP. Are you able to > upgrade to 17.07? > > > > Thanks, > >

Re: [vpp-dev] Configuring multiple VFRs

Hi Michael, Those configs will work with newer versions of VPP. Are you able to upgrade to 17.07? Thanks, neale From: on behalf of Michael Borokhovich Date: Wednesday, 9 August 2017 at 18:50 To: "vpp-dev@lists.fd.io"

Re: [vpp-dev] [csit-dev] API Change: Dedicated SW interface Event

+1 On 8/9/2017 1:49 PM, Luke, Chris wrote: Yeah, I suspect the API was simple enough back at the beginning that it just made sense to do it that way. This message, and presumably others, suffer from legacy cruft. Assuming the downstream consumers are okay with it, I fully support blowing out

[vpp-dev] Spurious make test failure (container POC)

Please see https://gerrit.fd.io/r/#/c/7927, and http://jenkins.ejkern.net:8080/job/vpp-test-debug-master-ubuntu1604/1056/con sole The patch in question is highly unlikely to cause this failure... 14:37:11

[vpp-dev] node.js

Hi, I am doing the accounting on required packages for downstream builds. Does anyone know why epel-rpm-macros are included in our dependencies. This RPM provides an rpm macro which overrides another macro that defines the arch's on which node.js runs? What is the history as to this being

[vpp-dev] Configuring multiple VFRs

Hi, We have 3 interfaces. First two belong to different VRFs and the third one is a global interface (GigabitEthernet0/6/0). How we can configure VPP so that the packets received through any of the first two interfaces will be sent to the global interface (GigabitEthernet0/6/0). The default GW

Re: [vpp-dev] [csit-dev] API Change: Dedicated SW interface Event

Yeah, I suspect the API was simple enough back at the beginning that it just made sense to do it that way. This message, and presumably others, suffer from legacy cruft. Assuming the downstream consumers are okay with it, I fully support blowing out the cruft. Chris. > -Original

Re: [vpp-dev] [csit-dev] API Change: Dedicated SW interface Event

Hi Chris, I don’t know the history. Convenience probably. In the absence of our attempt at auto-generating/auto-detecting event-notify pairs, the message re-use is understandable. I’m just trying to avoid the special cases in those generators (like-wise with the recent ACL dump addition).

Re: [vpp-dev] [csit-dev] API Change: Dedicated SW interface Event

Hi All, Any objections or support for this proposal? Thanks, neale -Original Message- From: on behalf of "Neale Ranns (nranns)" Date: Monday, 7 August 2017 at 16:02 To: "vpp-dev@lists.fd.io" ,