[vpp-dev] NOTIFICATION: VPP 1801 verify and merge jobs

The 1801 VPP verify and merge jobs in production have been configured to run on the CPOC nodes.  Please run the necessary steps to produce new artifacts.  Once the artifacts have been published, please let me know so I can change the jobs in production to build on the LF nodes. Thank you, Vanessa

Re: [vpp-dev] VXLAN Tunnel IF Names

John, On Mon, Feb 5, 2018 at 2:14 PM, John Lo (loj) wrote: > Thanks Jon. Seems we have an agreed upon an approach now. Just to be > sure, let me list the specifics: > > > > 1. We will get rid of custom_instance_by_real_instance vector in > vxlan_main_t > See #3 below. >

Re: [vpp-dev] VXLAN Tunnel IF Names

Thanks Jon. Seems we have an agreed upon an approach now. Just to be sure, let me list the specifics: 1. We will get rid of custom_instance_by_real_instance vector in vxlan_main_t. 2. We will add something like user_instance_by_real_instance hash in vxlan_main_t to track instance

Re: [vpp-dev] VXLAN Tunnel IF Names

On Mon, Feb 5, 2018 at 11:48 AM, John Lo (loj) wrote: > One more thang, I would prefer to have a u32 instance number instead of > the 64 bytes if_name in the vxlan_tunnel_details API. -John > Hi John, I'll work up a patch re-spin using a hash-table, and I will include the

Re: [vpp-dev] VXLAN Tunnel IF Names

One more thang, I would prefer to have a u32 instance number instead of the 64 bytes if_name in the vxlan_tunnel_details API. -John From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of John Lo (loj) Sent: Monday, February 05, 2018 12:43 PM To: Jon Loeliger

Re: [vpp-dev] VXLAN Tunnel IF Names

Hi Jon, I think a good approach would be to store the insurance number in the tunnel struct and use a hash table to track instance number usage. This is a more effective way to not waste memory even for user who like to use big numbers for instance while not using that many tunnels. The

Re: [vpp-dev] VXLAN Tunnel IF Names

On Mon, Feb 5, 2018 at 9:55 AM, Jon Loeliger wrote: > > > >> I think we must check and reject instance misuse for this to be >> acceptable. I doubt the renumber is really used much for vhost and tap >> interface (others please correct me if not true). >> > > We do use them on

[vpp-dev] 18.04 tentative release plan

All, For any who didn't hear, somehow I've ended up the release manager for 18.04, following in the footsteps of others whose notes Dave Wallace has done a sterling job coalescing into something I think even I can grok. I've posted the tentative release plan for 18.04 in the usual place

Re: [vpp-dev] VXLAN Tunnel IF Names

On Mon, Feb 5, 2018 at 9:29 AM, John Lo (loj) wrote: > Hi Jon, > Hi John, > I don’t think the renumber scheme, as used by vhost and tap interfaces, is > foolproof and can cause problems if used extensively for vxlan. On > creating an interface with renumber, it does not check

Re: [vpp-dev] Calling a C function in one plugin from another plugin?

Perfect, that seems like a much easier solution :) Thanks /Michael From: "Dave Barach (dbarach)" Sent: Monday, 5 February 2018, 4.17 PM To: Michael Lilja; vpp-dev@lists.fd.io Subject: RE: Calling a C function in one plugin from another plugin? You can

Re: [vpp-dev] VXLAN Tunnel IF Names

Hi Jon, I don’t think the renumber scheme, as used by vhost and tap interfaces, is foolproof and can cause problems if used extensively for vxlan. On creating an interface with renumber, it does not check if the instance being requested is already used by another device. On creating an

Re: [vpp-dev] Calling a C function in one plugin from another plugin?

You can ask vlib_get_plugin_symbol ("plugin_name", "function_name") for the address of a function... Returns NULL if e.g. the plugin in question isn't loaded or the symbol is missing. HTH... D. -Original Message- From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io]

[vpp-dev] Calling a C function in one plugin from another plugin?

Hi, I'm looking at using DPDK rte_flow (generic flow API) for ACL offloading. From what I can see the only option I have is to implement a v1_msg_* receiver in the DPDK plugin to accept commands from ACL via the SHMEM rings. The concern I have is that this might be in conflict with the design