Re: [vpp-dev] CSIT test failure

[Jon Loeliger]

On Fri, Feb 3, 2017 at 10:01 AM, Rybalchenko, Kirill <
kirill.rybalche...@intel.com> wrote:

> Hi Jon,
>
>
>
> Yes, I think it is somehow related.
>
> Here is more detailed info:
>
>
>
> VPP – current master branch (commit e0cb0ccee10f1ce0e29c94acb3b486
> 1f46c0879d)
>
> CSIT – not related.
>
>
>
> Just build fresh new master branch:
>
>
> csit@dut1:~/dev2/vpp_t$ sudo ./build-root/build-vpp-native/vpp/vpp_api_test
> json <<< sw_interface_dump
>
> vat#
>
> …
>
> (Paused here for about 1 sec, probably because of timeout)
>
> …
>
> sw_interface_dump error: Misc
>
> vat# csit@dut1:~/dev2/vpp_t$
>
>
>
> master branch cloned yesterday morning works fine
>
>
>
> Thanks,
>
> Kirill.
>

OK.

I can explain the "sw_interface_dump: Misc" error as it pertains to the
CONTROL_PING.
It's subtle, but I didn't really cause the underlying problem.  I exposed a
lingering issue, I believe.
Here is what the last "working" code (56c7b01e16) looked like at the tai
end of the api_sw_interface_dump() function:
  /* and IPSEC tunnel interfaces */
 M (SW_INTERFACE_DUMP, mp);
 mp->name_filter_valid = 1;
 strncpy ((char *) mp->name_filter, "ipsec", sizeof (mp->name_filter) - 1);
 S (mp);

 /* Use a control ping for synchronization */
 {
   vl_api_control_ping_t *mp;
   M (CONTROL_PING, mp);
   S (mp);
 }
 W (ret);
 return ret;

Pop quiz:  What ret value is actually returned here?

The (somewhat surprising) answer is: The value from IPSEC tunnel message.

When I removed the braces around the CONTROL_PING block, I caused W() to
wait for the PING message to complete, and to reap *its* return code.  Now
that is what is returned.

  /* and IPSEC tunnel interfaces */
  M (SW_INTERFACE_DUMP, mp);
  mp->name_filter_valid = 1;
  strncpy ((char *) mp->name_filter, "ipsec", sizeof (mp->name_filter) - 1);
  S (mp);

  /* Use a control ping for synchronization */
  M (CONTROL_PING, mp_ping);
  S (mp_ping);

  W (ret);
  return ret;

The return from the CONTROL_PING has always been -99 (Misc), but no one
ever knew that.

Question:  What is "wait" (W) supposed to do?  Wait for the last message
sent to clear the queue and return its result?
If so, that's what we have after my changes, but not before.

Any easy fix that ignores the error codes is simply to "return 0;" at the
end of the function.  I will submit that patch if that is believed to be
the right way to fix it.  But more likely, we should figure out why the
PING says -99.

HTH,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Add dpdk development packaging

[Jon Loeliger]

On Mon, Jan 23, 2017 at 10:28 PM, Alexander Popovsky (apopovsk) <
apopo...@cisco.com> wrote:

> Damjan,
>
> After this change, ‘pkg-rpm’ target on the CentOS host seems to be failing
> (on master):
>
> $ git clean -xfd
> $ make bootstrap pkg-rpm
> ...
> error: Installed (but unpackaged) file(s) found:
>/usr/bin/dpdk-pdump
>/usr/bin/dpdk-pmdinfo
>/usr/bin/dpdk-procinfo
>/usr/bin/testpmd
> ...
> make[1]: *** [install-rpm] Error 1
> make[1]: Leaving directory `/mnt/thesource/git/vpp/build-root'
> make: *** [pkg-rpm] Error 2
>
> However, running with the additional dpdk-install-dev target succeeds:
>
> $ git clean -xfd
> $ make bootstrap dpdk-install-dev pkg-rpm
>
>
> Also, it looks like for the ‘pkg-deb’ target on the Ubuntu host the extra
> DPDK binaries (similar to the list above) are added to the vpp.deb package
> after:
>
> $ git clean -xfd
> $ make bootstrap pkg-deb
> $ grep testpmd ./build-root/deb/debian/vpp.install
> ..  /install-vpp-native/dpdk/bin/testpmd /usr/bin
>
> Regards,
> Alex
>

Yes, I see this happening now as well.

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Building DPDK Packages

[Jon Loeliger]

Hi Folks,

So, I recently used the "make dpdk-install-dev" target at the top
of the VPP build and was surprised to see:

==
 Up-to-date DPDK package already installed
==

But I shouldn't have been surprised.  The word "install" is in the target
name.

What I really wanted was "make dpdk-build-rpms", expecting a bunch of RPM
packages to be left at the top next to vpp-*.rpms.

I need to build an installable set of packages.  Not install a set of
packages.

So, is there a way to get to the "build-rpm" target in that DPDK Makefile?
That is, like "dpdk-install-dev", but "dpdk-build-rpms"

I did this obvious patch to the top-level Makefile:

$ git diff
diff --git a/Makefile b/Makefile
index 2af6340..8776af5 100644
--- a/Makefile
+++ b/Makefile
@@ -91,6 +91,7 @@ help:
@echo " pkg-deb - build DEB packages"
@echo " pkg-rpm - build RPM packages"
@echo " dpdk-install-dev- install DPDK development packages"
+   @echo " dpdk-build-pkg  - build DPDK development packages"
@echo " ctags   - (re)generate ctags database"
@echo " gtags   - (re)generate gtags database"
@echo " cscope  - (re)generate cscope database"
@@ -305,6 +306,9 @@ pkg-rpm: dist
 dpdk-install-dev:
make -C dpdk install-$(PKG)

+dpdk-build-pkg:
+   make -C dpdk build-$(PKG)
+
 ctags: ctags.files
@ctags --totals --tag-relative -L $<
@rm $<

But that *rebuilt* the DPDK a second time.  Can it instead be
integrated into a notion of the top-level "pkg-rpm" target so that
it is built only once, and also collects the built package,
./dpdk/vpp-dpdk-devel-16.11-vpp1.x86_64.rpm
and copies it up to build-root/ with the rest of the *.rpm files?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] SNAT Plugin Use

[Jon Loeliger]

On Thu, Jan 26, 2017 at 4:38 PM, Jon Loeliger <j...@netgate.com> wrote:
>
>
> Does this same mechanism hold true for the VPE messages?  Is the collection
> of the VPE message considered "a plugin", or "a base onto which plugins
> will
> be added"?  There are currently 20 or 21 include files' worth of msg ids
> here.
>
> Specifically, I'm trying to resolve an understanding of what I was told to
> do
> last week (Use a msg_id based on a lookup of "_") versus this
> use a msg_id obtained by "base + enum-value".
>
> Is there a plugin name for the VPE collection of API msg ids?  (I don't
> think so.)
> Will these msg_ids always be 0-based so no base offset need be looked-up
> nor added?
>
> Thanks,
> jdl
>

Dave,

So, I feel like I may be a day late and a dollar short each time I ask
a question.  Like above.  So I just couldn't see where this base msg_id
addition was taking place...  And about the time I was trying to figure
it out, this commit happened:

author Dave Barach <d...@barachs.net> 2017-01-25 16:32:08 -0500
commit 2d6b2d6d1bbb130921ec525a1cc6e88f42717c79 (patch)

Repair plugin binary API message numbering
Change-Id: I422a3f168bd483e011cfaf54af022cb79b78db02
Signed-off-by: Dave Barach <d...@barachs.net>

Which pretty much answers my question.

Are my questions the forcing function here? :-)
Or am I just on the bleeding edge?

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] SNAT Plugin Use

[Jon Loeliger]

On Wed, Jan 25, 2017 at 10:49 AM, Dave Barach (dbarach) 
wrote:

> Dear Jon,
>
>
>
> Sorry for the delayed response.
>
>
>
> Anyhow, the constant VL_MSG_FIRST_AVAILABLE is a historical name for a
> simple thing: the number of binary API messages defined by a given plugin.
>

Understood.


> I’m not sure what you’re trying to do, but it’s actually just as well that
> you ran into a compile error. I need to explain a number of details so you
> won’t end up seriously annoyed after wasting a bunch of your time.
>

Hrm.  Maybe too late for that... :-)

So, let me give a bit of insight into what I am doing, because I think
my intent may be being misunderstood a little.

I am doing what I suspect might be the obvious Use Case for the C API
to VPP lib.  Effectively we are are writing a totally different CLI
front-end
to VPP through the VPP lib API.  We are strictly *using* vlib -- we are not,
at this time, writing any new plugin to VPP, nor are we extending VPP's
functionality via a new plugin.

However, we have need to use multiple plugins.  If you consider the "vpe"
pieces one plugin, then currently our next plug we need is SNAT.

When the vpp data-plane loads plugins, each plugin which defines a binary
> API is expected to do something like the following:
>
>
>
>   name = format (0, "snat_%08x%c", api_version, 0);
>
>
>
>   /* Ask for a correctly-sized block of API message decode slots */
>
>   sm->msg_id_base = vl_msg_api_get_msg_ids
>
>   ((char *) name, VL_MSG_FIRST_AVAILABLE);
>
>
>
> The data-plane plugin asks for a block of message-ID’s.
> vl_msg_api_get_msg_ids(...) makes a string-hash entry, to map the string
> _ to the base of the message-id block.
>

OK, good.  I get that, I believe.


> When it comes time to send binary API messages to a given plugin, the
> control-plane agent recovers msg_id_base like so:
>
>
>
>   /* Ask the vpp engine for the first assigned message-id */
>
>   name = format (0, "snat_%08x%c", api_version, 0);
>
>   sm->msg_id_base = vl_client_get_first_plugin_msg_id ((char *) name);
>
>
>
> and adds it to the enumerated message id values:
>
>
>
>   mp->_vl_msg_id = ntohs (msg_id_base + VL_API_some_msg_id);
>

This is the code that we can't currently write.  I have need of both the
interface and SNAT APIs in one C source file.  In that case, I had intended
to make both interface and SNAT API message calls.  I'm happy to offset
the number scheme for one of these sets, or both, by an offset.  But I
can't include both of the msg_id enumberations in the same C file because
they collide on the definition of the VL_MSG_FIRST_AVAILABLE as found
in the enum definitions.

Are we expected to have to interface to each plugin from a separate C
source file?  I can add an extra set of routines to hide all this in an
additional
C source file if needed, I guess.

Would it make more sense for these enums to provide VL_MSG_ID_SNAT_N_MSGS
or something unique to that enum?

Also, is there an API call to "load" a plugin that I missed somewhere?
How does
my main-line code tell VLIB that the SNAT plugin will need to be loaded?


Since the set of plugins can change between runs, absolute message ID’s
> can’t be guaranteed.
>

Yep, I get that too.  Where is all this plugin stuff described?  I see, for
example,
the "sample" plugin src/examples/sample-plugin/sample/.  However, I think
that
describes how to write a new plugin to extend VPP's functionality.   That's
not
what I'm doing.

Please let me know if there are other questions I could answer to help
clarify what I'm trying to do here!

Thanks… Dave
>

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] SNAT Plugin Use

[Jon Loeliger]

On Wed, Jan 25, 2017 at 10:49 AM, Dave Barach (dbarach) 
wrote:
>
>
>
> When it comes time to send binary API messages to a given plugin, the
> control-plane agent recovers msg_id_base like so:
>
>
>
>   /* Ask the vpp engine for the first assigned message-id */
>
>   name = format (0, "snat_%08x%c", api_version, 0);
>
>   sm->msg_id_base = vl_client_get_first_plugin_msg_id ((char *) name);
>
>
>
> and adds it to the enumerated message id values:
>
>
>
>   mp->_vl_msg_id = ntohs (msg_id_base + VL_API_some_msg_id);
>
>
>
> Since the set of plugins can change between runs, absolute message ID’s
> can’t be guaranteed.
>
>
>
> Thanks… Dave
>

Does this same mechanism hold true for the VPE messages?  Is the collection
of the VPE message considered "a plugin", or "a base onto which plugins will
be added"?  There are currently 20 or 21 include files' worth of msg ids
here.

Specifically, I'm trying to resolve an understanding of what I was told to
do
last week (Use a msg_id based on a lookup of "_") versus this
use a msg_id obtained by "base + enum-value".

Is there a plugin name for the VPE collection of API msg ids?  (I don't
think so.)
Will these msg_ids always be 0-based so no base offset need be looked-up
nor added?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] SNAT Plugin Use

[Jon Loeliger]

Folks,

What is the expected method to use the SNAT plugin within the
framework of the rest of a VPP system?

Specifically, what is the expected use of VL_MSG_FIRST_AVAILABLE?
It is several (4) enum include files, and they conflict if two or more are
used in the same source file.  Here is a terse example.

Did I miss some documentation that shows how to use the SNAT plugin?
I don't think I need to use the "plugin-ness" of SNAT, as we will always
need to have it present in our app.

Thanks,
jdl


CC interface.c
In file included from interface.c:13:0:
/usr/include/vpp_plugins/snat/snat_msg_enum.h:27:5: error: redeclaration of
enumerator ‘VL_MSG_FIRST_AVAILABLE’
 VL_MSG_FIRST_AVAILABLE,
 ^
In file included from interface.c:12:0:
/usr/include/vpp/api/vpe_msg_enum.h:25:3: note: previous definition of
‘VL_MSG_FIRST_AVAILABLE’ was here
   VL_MSG_FIRST_AVAILABLE,
   ^
In file included from interface.c:13:0:
/usr/include/vpp_plugins/snat/snat_msg_enum.h:28:3: error: conflicting
types for ‘vl_msg_id_t’
 } vl_msg_id_t;
   ^
In file included from interface.c:12:0:
/usr/include/vpp/api/vpe_msg_enum.h:26:3: note: previous declaration of
‘vl_msg_id_t’ was here
 } vl_msg_id_t;
   ^
make: *** [interface.o] Error 1
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] SNAT API Question

[Jon Loeliger]

Hi Matus,

Thanks for your answers here.

On Sat, Feb 18, 2017 at 12:36 AM, Matus Fabian -X (matfabia - PANTHEON
TECHNOLOGIES at Cisco)  wrote:

> If external_sw_if_index value is ~0 (-1) external_ip_address is ussed from
> API (snat.c line 363).
>

OK, I see that in the code, but it is nowhere described in the API itself.
That is my issue here.  Magic values like this *are* part of the API as they
will affect changes on the VPP-side of the API interface.


> snat_add_address_range – add address range to SNAT address pool
>
> snat_add_del_interface_addr – add address of the interface to SNAT address
> pool (address is added/removed automatically when interface address is
> changed by configuration or DHCP)
>

So one could use either or both, as they wish?

I guess I'm having a bit of hard time trying to figure out what the
canonical API call sequence would be to set up various useful
and standard NAT situations.  Yes, I've read the Wiki page; No it
isn't clear on the proper, expected sequence of the API calls.

How does those API sequences change for the different values of the config
variables "static_mapping_only" and "static_mapping_connection_tracking"?

And on that note -- How do you change the value of those config varaibles
at run time?  I know how to alter the config file and re-read them in VAT.
I'm not using VAT.  I'm writing a totally different system.  Can those
values
be changed at run-time?  There is no API to do so, so at this point in time
the answer must be "no."  Is it expected that the sequence to change these
configuration values at run time is to: 1) Stop VPP, 2) write a new config
file
with the new desired values, 3) restart VPP?  That seems bad to me.


I think 1024 is not significant, it's just a warning that you add a lot of
> addresses to SNAT address pool, it was here before I started work on SNAT
> plugin.
>

Well, 1024 is arbitrary.  Who is to say that I don't need 2048 and don't
care
about the warning in my environment?   To be clear, I'm not blaming you
(Matus),
or anyone for that matter.  I'm merely pointing out that it is an arbitrary
and
undocumented limit in the current system.


> Matus
>

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] SNAT API Question

[Jon Loeliger]

On Tue, Feb 14, 2017 at 11:52 PM, Matus Fabian -X (matfabia - PANTHEON
TECHNOLOGIES at Cisco)  wrote:

> Hi Jon,
>
>
>
> snat_static_mapping_dump list only static mappings with resolved outside
> address so snat_static_mapping_details doesn’t contain
> external_sw_if_index. But we missing read API for static mappigs with
> unresolved outside address, I will add those to snat_static_mapping_dump
> too.
>
>
>
> Thanks,
>
> Matus
>
>
>
How does the API handler know which of the external_ip_address
or the external_id_index to honor?  Is there an invalid value that
should be supplied in the other field when making the API call
to snat_add_static_mapping?  Or is the API user expected to
resolve the external_ip_address and supply its sw_if_index too?

Also, another question.  When placing a range of addresses on
an external interface for dynamic mappings, is the expected use
case to first use snat_add_address_range on the external IF,
then when they are all "added", issue a snat_add_del_interface_addr
to make it effective (add) or remove them (del)?

Finally, one last API implementation question.

In snat_test.c, we find this snippet of code:

static int api_snat_add_address_range (vat_main_t * vam)
{
...
start_host_order = clib_host_to_net_u32 (start_addr.as_u32);
end_host_order = clib_host_to_net_u32 (end_addr.as_u32);
...
count = (end_host_order - start_host_order) + 1;

if (count > 1024) {
errmsg ("%U - %U, %d addresses...\n",
  format_ip4_address, _addr,
  format_ip4_address, _addr,
  count);
}


Is that 1024 significant or arbitrary?  Is there some limit in the VPP
implementation that is being guarded here?  Or is that an arbitrary
UI-imposed limit?

Specifically, must other API users adhere to this limit?  If not is there
some other limit at work here?

I see under the covers that each address in this range is individually
added to some address vector.  And furthermore this vector DOES
appear to be hard limited to 1024 entries as well. (See snat.c,
vl_api_snat_add_address_range_t_handler() around line 820 or so.)

Again, arbitrary?  Or is the limit actually imposed by the FIB?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] SNAT Future API Questions

[Jon Loeliger]

Dudes and Dudettes,

As you may have guessed by now, I am working my way through
the SNAT Realm these days.  And now I have a question about
some possible, future API messages for obtaining some running
state information, notably for some form of "show snat" command.

In VAT's current implementation, there is an API call to obtain the
config data established from VPP's config file at startup time.
One can do a series of *_DUMP-style API calls to regurgitate the
configurations fed to SNAT.  That's all good.

However, there is no way to determine any of the runtime state.
In VAT today, there is a "show" command that inspects the internal
data structures directly; there is no API call to obtain any of that
same information.  Naturally that won't work for an external UI Agent.

So:  Is there a plan to add such API calls in the future?  Is it on
someone's plate already?   If not, would we entertain suggestions
or even patches to add that support?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Coding Preference Question

[Jon Loeliger]

VPPers,

As a general rule, do you guys prefer to use:

1) An integer (i32) and -1 as a flag case,
or
2) An unsigned integer (u32) and ~0 as the flag case?

If it matters, this is for an API value.

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Loopback Interface Names

[Jon Loeliger]

Folks,

So, I want to address this example from Dave's "home gateway" example:

loopback create
set int l2 bridge loop0 1 bvi
set int ip address loop0 192.168.1.1/24
set int state loop0 up

Here, lines 2, 3, and 4 all have unspoken knowledge of the effects of
line 1.  Specifically, it "knows" that "loop0", by name, just got
created.  One just knows.

In VPP land, one issues an API call to create a loopback interface.
VPP makes up the name for it ("loop0"), and tells you a new sw_if_index
for it.  Likely something like 5 or 6 or so, depending on how many
other IFs have been made already.

In a Popular Router Configuration Language (PRCL), one says
interface loopback 0
and it creates the named interface, "Loopback0".

But there is a subtle difference, in VPP the name is assumed
for subsequent commands, while in PRCL, later commands will
need to know the name of the loopback interface.  Not assume,
know.  But without specifying it at creation, one can not know its
name for use later.

So, I'm proposing a slight modification to the create_loopback
API message.  My proposal can maintain backward compatibility.

Currently:

/** \brief Create loopback interface request
@param client_index - opaque cookie to identify the sender
@param context - sender context, to match reply w/ request
@param mac_address - mac addr to assign to the interface if
none-zero
*/
define create_loopback
{
  u32 client_index;
  u32 context;
  u8 mac_address[6];
};

I'm proposing adding a field that specifies the actual
name of the loopback interface be added.

define create_loopback
{
  u32 client_index;
  u32 context;
  u8 mac_address[6];
  u8 name[32];
};

Pick your favorite upper-bound for name length or substitute
a zero-terminated C-string-like name.  Don't much care there.

But my point is that to achieve some compatibility with PRCL's
expected behavior, we'll need them to be named "Loopback",
and not "loop".  Naturally, if the name isn't supplied by
the API caller, the current default name can be allocated.

At the bare minimum, the instance number should be supplied
in the API call and the VAT command changed to allow the form:

loopback create []

For example:

> loopback create 2

That way there is an explicit, not assumed, correspondence for
the following commands like:

> set int l2 bridge loop2 1 bvi

Thoughts?

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP Wiki Release Plan Snigglet

[Jon Loeliger]

On Thu, Feb 23, 2017 at 2:04 AM, Jong Hahn (jonhahn) 
wrote:

> Hi Jon,
>
> Per below, I updated the wiki and the Jira link.
>
> Thanks,
>
> Jong
>
>
>
Jong,

Thank you!

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] SNAT Future API Questions

[Jon Loeliger]

On Wed, Feb 22, 2017 at 11:28 PM, Matus Fabian -X (matfabia - PANTHEON
TECHNOLOGIES at Cisco)  wrote:

> Hi,
>
>
>
> There is currently work on dump API  for SNAT runtime data (users and
> sessions). It will be finished in next few days.
>
>
>
> Matus
>

Matus,

That is awesome news!  Thank you!

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Loopback Interface Names

[Jon Loeliger]

Dave,

Thanks for taking the time to help me here!

On Wed, Feb 22, 2017 at 4:47 PM, Dave Barach (dbarach) 
wrote:

> You would certainly have to rewrite vnet_create_loopback_interface(...) a
> little bit. That’s not necessarily a bad thing.
>

Yeah, I figured as much on that front... :-)  I'm not afraid of
giving it a swing.


> Please brain-police the instance number: flunk attempts to create specific
> loopback instances (e.g. loop0) more than once, and so forth. Bitmap, plus
> some upper limit (maybe 16k?) on the loopback instance number.
>

Can do.  Two questions.  If a loopback interface is deleted,
would that free-up the instance number for re-use?  Or is
there lingering reason to never reuse an instance number?
And second, is there a bit-vector implementation around?
I would assume so and I just need to go looking...?

I still need to resolve the name expectations; that is, expecting
"Loopback" to be the base, and not "loop".  Does one of these
options make more sense here?

1) Have the API create call supply the desired name directly,
defaulting to "loop"-names if none are specified.

2) Have a loopback-module-global-ish config variable stating
to be in "loop" or "Loopback" mode.  Mode can be set via
new loopback API config call, or via VPP startup config setting.

3) Tell our users to get used to the New "loop" World Order? :-)

HTH… Dave
>

Thanks,
jdl


> PS -- At the risk of foretelling the future, bridge names are going to
 have this same naming issue, right?  'Cuz those are next up!
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] VPP Wiki Release Plan Snigglet

[Jon Loeliger]

Hi Folks,

Over on the VPP Wiki Page

https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_17.04

There is an apparent cut-n-paste-ish style error at the very bottom
where it suggests 17.07 features are being extracted from Jira using
an obsolete and non-public search query.

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP API Synchronization Question

[Jon Loeliger]

On Fri, Feb 10, 2017 at 11:23 AM, Dave Barach (dbarach) 
wrote:

> Dear Jon,
>
>
>
> If you send “please dump X” API message(s), followed by a control-ping
> message: when the control-ping reply appears, all of dump reply messages
> (if any) have appeared.
>
>
>
> That absolutely *does* work. See api_format.c:api_ip_add_del_route(...).
>
>
>
> In standard usage, the messages are received on a separate pthread. The
> api test tool uses the world’s crudest synchronization scheme.
>
>
> Contact me off-list if you can’t figure out what’s wrong.
>
>
>
> Thanks… Dave
>

Dave,

Spurred on by  your insistence that it does work, I went digging
around in my code a whole bunch more.  Specifically, I was trying
to instrument around my message-wait function some more.
Eventually, I came to realize that it was timing-out on almost every
message sent.  Naturally, that didn't seem right to me...

Debugging lead me to realize that I failed to call clib_time_init()
in our early initialization sequence, and all of the timer-based
tests in message wait were instantly failing, and thus the messages
were not truly waiting for the "result ready" condition like they should.

I still don't like the use of an essentially global, volatile here; but
at least it is working, as you indicated it would.

Is there a quick outline of how the API's threading model is set up
and expected to be used?  Where the vlib_global_main and vlib_mains
are established and such?

Thank you!
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] SNAT API Question

[Jon Loeliger]

VPPers,

Somewhat recently, (commit 36532bda926f5255a323c9cac3144dd758a05667),
the external_sw_if_index was added to the SNAT API snat_add_static_mapping
message.

However, when dumping the static mappings with snat_static_mapping_dump
the corresponding snat_static_mapping_details does not contain the new
external_sw_if_index.

Is that an oversight, or is it not necessary?  Or am I confused again?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Failing Out-of-tree Builds

[Jon Loeliger]

On Fri, Feb 10, 2017 at 9:12 AM, Jon Loeliger <j...@netgate.com> wrote:

> On Thu, Feb 9, 2017 at 11:16 PM, Akshaya Nadahalli (anadahal) <
> anada...@cisco.com> wrote:
>
>> Hi Jon,
>>
>> fib_urpf_list.h needs to included inside the source file and need not be
>> installed in /usr/include. Thanks for raising this. I will send out a patch
>> for this.
>>
>> Regards,
>> Akshaya N
>>
>
>  Awesome!  Thank you!
>
> jdl
>

Just to close the loop here, it looks like the commit

commit 0f438df9918911a976751f2391421cc8b4b6fdb7
Author: AkshayaNadahalli <anada...@cisco.com>
Date:   Fri Feb 10 10:54:16 2017 +0530

Out-of-tree Build Error fix

did indeed fix this issue for me.

Thank you!

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Weird VPP API message processing failure

[Jon Loeliger]

On Wed, Jan 18, 2017 at 12:24 PM, Damjan Marion 
wrote:
>
> I see.
>
> But how come vat doesn't do this [msg ID mapping] step?
>
> Likely somebody needs to do the work…
>
> Thanks,
> Damjan
>

Ed,

As I indicated when we spoke, I have implemented the gunky details
of establishing the mapping from  to API msg ID.
It turned out to be a bit less gross than I had anticipated, primarily
due to the fact that we have separate compilation within our client
of different functional areas.

Executive summary:  It is working.

Homework:  Details are below if someone wants to add something
like it to, say, vat.

HTH,
jdl

--- sparse details -

So, for example, within our interface code, I added these bits:

#define vl_msg_name_crc_list
#include 
#undef vl_msg_name_crc_list

and then in our intf_init() function, these bits:

#define _(msg_id, name, crc)\
vpp_set_msg_id_map(msg_id, #name "_" #crc);

foreach_vl_msg_name_crc_interface;
#undef _

That function, vpp_set_msg_id_map() establishes entries in
a global structure:

struct vpp_msg_map {
u32 id;
char *name_crc;
} vmid_map[];

using basically:
id = vl_api_get_msg_index((u8 *)name_crc);
vmid_map[msg_id].id = id;
vmid_map[msg_id].name_crc = strdup(name_crc);


Naturally, the vl_msg_api_set_handlers() calls have to do a
map lookup to get the new API msg id, like this:

#define _(N,n)  \
vl_msg_api_set_handlers(vmid_map[VL_API_##N].id,\
#n, \
   vl_api_##n##_t_handler, \
vl_noop_handler,\
vl_api_##n##_t_endian,  \
vl_api_##n##_t_print,   \
sizeof(vl_api_##n##_t), 1);
foreach_vpe_api_reply_msg;
#undef _

I buried the map lookup in the message alloc function, so then
the rest of the code can just use, say, SW_INTERFACE_DUMP
as it was already written.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Weird VPP API message processing failure

[Jon Loeliger]

On Mon, Jan 16, 2017 at 6:33 PM, Jon Loeliger <j...@netgate.com> wrote:

> Folks,
>
> We are seeing a really strange VPP API message processing problem.
> The scenario goes like this...
>
>
> I've started to isolate it with git bisect, and so far I believe the
> behavior changed between these commits:
>
> $ git log --oneline
> ...
> 553a411 VPP-585: vhost-user interface deletion leaks memory.
> ffc18f5 japi: include tests in jar files
> 738f3f2 API refactoring : dpdk
> 6bbf83a Revert "vppctl: bash completion for vppctl commands"
> 842b9c5 Self-service garbage collection for the API message allocator
> d995c75 vppctl: bash completion for vppctl commands
> 0d3c1cc VPP-279: af_packet via Command-line Arg should no longer be
> supported
> 48c1824 Update CSIT tests 170101 -> 170108
> ...
>
> I've not had a chance to look at them yet, but of those, the most
> suspicious looking one to me is:
> 842b9c5 Self-service garbage collection for the API message allocator
>
> If no one beats me to it, I'll continue bisecting it tomorrow...
>
> Thanks,
> jdl
>

So, our message processing issue was one of the commits
listed above.  Specifically, it is this:
738f3f2 API refactoring : dpdk

In that commit, API messages (and their IDs) are made conditionally
present based on the symbol DPDK being greater than 0.  That has
yielded an inconsistent build scenario where the include files used
by other components do not have DPDK set, and the internally built
components (vl_api_test) do see it set.  That results in API message
IDs that are skewed by 6.

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Weird VPP API message processing failure

[Jon Loeliger]

On Tue, Jan 17, 2017 at 3:45 PM, Alexander Popovsky (apopovsk) <
apopo...@cisco.com> wrote:

> We have seen a similar issue related to the same ‘API refactoring : dpdk’
> change.
> We are using an external API binding layer in C-language in our VPP based
> solution.
> After the change, it took some digging to add –DDPDK=1 to get things back
> to working.
>
> Looking forward, should it be considered a standard practice in VPP for
> the API (IDs) to be dependent on the features compiled (enabled) in VPP?
> In such case, should we consider having a generated config.h (similar to
> Linux kernel) to be included by the external C-code?
>
> Thanks,
> -AI
>

Right.

Except it is more insidious than that.  The installed include files
have an #ifdef in them that changes the message ID values.
The corresponding libraries were compiled using on or the other
of those choices.  Which one?  No way to tell.  But one of them
is right and the other is wrong.

I think the include file should never present the ability to make the
message ID values be variant.

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Weird VPP API message processing failure

[Jon Loeliger]

On Wed, Jan 18, 2017 at 5:55 AM, Damjan Marion 
wrote:

> As Ole explained, please use vl_api_get_msg_index.
>
> -DDPDK=1 will disappear soon when dpdk becomes a plugin…
>
> Thanks,
>
> Damjan
>

I see.

But how come vat doesn't do this step?

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Weird VPP API message processing failure

[Jon Loeliger]

On Wed, Jan 18, 2017 at 5:55 AM, Damjan Marion 
wrote:

>
> -DDPDK=1 will disappear soon when dpdk becomes a plugin…
>
> Thanks,
> Damjan
>

Damjan,

Will the DPDK that VPP builds be packaged and made available
from the "make pkg-{rpm,deb}" targets?  I see references to DPDK
in the vpp.spec file, and that it might be a plugin, but it is unclear to
me if these are this is the full DPDK installation (include files,
libraries,
system configuration) or just plugin glue libraries.

Is there a top-level Makefile target that makes the built DPDK
packages available?  (I'm looking reluctantly for RPMs right now.)

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Weird VPP API message processing failure

[Jon Loeliger]

Folks,

We are seeing a really strange VPP API message processing problem.
The scenario goes like this...

Our CLI issues C API calls through the vlib API.  The messages hit
the shared memory queue, but are not processed.  They sit there.

Later, we fire up, say, vppctl and do a "show api" command.  That
causes the queue to be flushed and the first thing it does is process
the outstanding API messages from our CLI.

This used to work.  About two weeks ago I started pulling in the
top-of-tree stuff to get us closer to development head and get
some of the needed bug fixes.

I'm wondering if this sounds familiar to you at all?

I've started to isolate it with git bisect, and so far I believe the
behavior changed between these commits:

$ git log --oneline
...
553a411 VPP-585: vhost-user interface deletion leaks memory.
ffc18f5 japi: include tests in jar files
738f3f2 API refactoring : dpdk
6bbf83a Revert "vppctl: bash completion for vppctl commands"
842b9c5 Self-service garbage collection for the API message allocator
d995c75 vppctl: bash completion for vppctl commands
0d3c1cc VPP-279: af_packet via Command-line Arg should no longer be
supported
48c1824 Update CSIT tests 170101 -> 170108
...

I've not had a chance to look at them yet, but of those, the most
suspicious looking one to me is:
842b9c5 Self-service garbage collection for the API message allocator

If no one beats me to it, I'll continue bisecting it tomorrow...

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP Build Bombing Out on libsvm.la?

[Jon Loeliger]

On Thu, Jan 12, 2017 at 9:25 PM, Burt Silverman  wrote:

> Cool. My suggestion would not have solved the issue, but looking at
> Damjan's .am files gives me a hint why the years ago project had issues,
> for example:
>

> libsvm_la_LIBADD = libvppinfra.la -lrt -lpthread
> libsvm_la_DEPENDENCIES = libvppinfra.la
>

When I read this, I felt I was stumbling into the right area... :-)

Again, though, thanks for all your help here!

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] VPP Build Bombing Out on libsvm.la?

[Jon Loeliger]

Folks,

I'm staring at some VPP builds on a fresh CentOS system.
I've installed all the "install-deps", and get pretty far into the
build before it wedges.  I see warnings like this:

 /bin/sh ./libtool   --mode=install /usr/bin/install -c   libsvm.la
libsvmdb.la libvlib.la libvlibapi.la libvlibmemory.la libvlibmemoryclient.la
libvlibsocket.la libvatplugin.la
'/home/jdl/ngr-rpms/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/lib64'
PLUGIN CFG vpp_plugin_configure
libtool: install: warning: relinking `libsvm.la'

I don't know if that is important misbehavior or normal behavior.

Ultimately, most of the builds quit grousing about a missing libvppinfra:

/usr/bin/ld: cannot find -lvppinfra
collect2: error: ld returned 1 exit status
libtool: install: error: relink `libsvm.la' with the above command before
installing it
make[6]: *** [install-libLTLIBRARIES] Error 1
make[6]: *** Waiting for unfinished jobs

Not sure which real target issued that loveliness due to some "make -j"
parallelism in the mix.  Might be the relinking of libvnet.la.

I am able to build VPP on an entirely different system though.
So it seems like there is some variability in its success rate.

Is it possible that there is a missing dependency and the "-j" is
effectively causing it to want libvppinfra before it is available?

Ideas or suggestions?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] API Doc Question sw_interface_add_del_address

[Jon Loeliger]

Folks,

Over in src/vnet/interface.api, round-about lines 162-182,
we find this excerpt:


/** \brief Set or delete one or all ip addresses on a specified interface
@param client_index - opaque cookie to identify the sender
@param context - sender context, to match reply w/ request
@param sw_if_index - index of the interface to add/del addresses
@param is_add - add address if non-zero, else delete
@param is_ipv6 - if non-zero the address is ipv6, else ipv4
@param del_all - if non-zero delete all addresses on the interface
@param address_length - address length in bytes, 4 for ip4, 16 for ip6
@param address - array of address bytes
*/
define sw_interface_add_del_address
{
  u32 client_index;
  u32 context;
  u32 sw_if_index;
  u8 is_add;
  u8 is_ipv6;
  u8 del_all;
  u8 address_length;
  u8 address[16];
};


My question is address_length.  The doc says it is the

address length of 4 or 16 bytes as per IPv4/6-ness.


However, I think it is really the netmask prefix

length, more like, say, 16, 24, or 32.


Right?


Thanks,

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Tap IF Names

[Jon Loeliger]

Guys,

Why do tap interfaces use the name "tap-%d" internally?  The user has
given an actual name (that corresponds to the underlying Linux tap name),
and yet VPP makes up a non-correlatable different name in the form "tap-%d"
by making up some number and assigning it to the IF.

This issue is precisely the same problem that loopback IF names had,
and for which I submitted a patch to at least allow deterministically
predictable
IF names for user-assigned names on loopbacks.

Later, there is some form of ability to "renumber" tap interfaces.  Will
this
affect the numbering of the IF names the user sees?

Specifically, I'm wondering if we can somehow unify the tap name prefix
with the other interface prefixing styles in a more standard, cohesive and
predictable way.  In the case of tap IFs, having VPP instead at least use
the name "tap-%s", formatted with the user-supplied name would make
it predictable and somewhat similar to the other IF types.

I *think* this table summarizes the current state of IF names for many
of the interface types.

Thanks,
jdl



DPDK:
User says : TenGigabitEthernet6/0/0
VPP uses  : TenGigabitEthernet6/0/0
Linux uses: 

Loopback:
User says :  - for "create" and "delete" commands
VPP uses  : loop - for any other reference to the IF
Linux : 

Host AF_PACKET
User says :  - for "create" and "delete" commands
VPP uses  : host- - for any other reference to the IF
Linux uses: 
Note: Leftover(?) use of "veth" in all VPP Wiki pages still?

Tap:
User says :  - for "create" and "delete" commands
VPP uses  : tap- - for any other reference to the IF
Linux uses: 
Note: No relationship between  and 

netmap:
User says :  - for "create" and "delete" commands
VPP uses  : netmap- - for any other reference to the IF
Linux uses: 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Strange C Dyanmic Loading Failure

[Jon Loeliger]

On Mon, Mar 27, 2017 at 9:27 AM, Adrian Daniel Calianu <
adrian.cali...@gmail.com> wrote:

> Hi all,
>
> I have the same issue. After I built the vpp from sources(master branch)
> and run vppctl I see a segmentation fault. This looks to be caused by the
> fact that the vlib_mains from init functions of dynamic linked libraries is
> 0x0.
> Following patch will fix the problem:
> --- a/src/vlib/global_funcs.h
>  19 +++ b/src/vlib/global_funcs.h
>  20 @@ -23,7 +23,7 @@ always_inline vlib_main_t *
>  21  vlib_get_main (void)
>  22  {
>  23vlib_main_t *vm;
>  24 -  vm = vlib_mains[os_get_cpu_number ()];
>  25 +  vm = vlib_mains ? vlib_mains[os_get_cpu_number ()] :
> _global_main;
>  26ASSERT (vm);
>  27return vm;
>  28  }
>
> This is like a part of patch did in commit: 
> 80f54e20270ed0628ee725e3e3c515731a0188f2
> need to be reverted.
>
> Is other fix of this issue?
>
> /Adrian
>

For the record, my issue was PEBCAK.  I needed to add -lvlib
to my link line.

Oh yeah.

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP build issue on Ubuntu 16.04.2 LTS

[Jon Loeliger]

On Tue, Mar 28, 2017 at 8:55 AM, Dumitrescu, Cristian <
cristian.dumitre...@intel.com> wrote:
>
> Hi Jon,
>
>
>
> I did “make install-dep” just before the “make bootstrap”, so maybe there
> is some package that I need to upgrade that is not picked up by “make
> install-dep”.
>
>
>
> One thing to mention is I had exactly the same error on Ubuntu 15.10
> first, then I upgraded to Ubuntu 16.04.2 LTS using “do-release-upgrade”,
> and I am still getting it.
>
>
>
> Any idea on how to debug this?
>
>
>
> Regards,
>
> Cristian
>

Hi Cristian,

I don't really have any more insight into this specific problem.  Sorry.

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP build issue on Ubuntu 16.04.2 LTS

[Jon Loeliger]

On Mon, Mar 27, 2017 at 12:41 PM, Dumitrescu, Cristian <
cristian.dumitre...@intel.com> wrote:

> Hi guys,
>
>
>
> Any idea why am I getting this error:
>
>
>
> >make bootstrap
>
> …
>
> checking for python... /usr/bin/python
>
> checking for python version... 2.7
>
> checking for python platform... linux2
>
> checking for python script directory... ${prefix}/lib/python2.7/site-
> packages
>
> checking for python extension module directory...
> ${exec_prefix}/lib/python2.7/site-packages
>
> /home/cfdumitr/git_fdio/vpp/build-root/../src/configure: line 13178:
> syntax error near unexpected token `g2,'
>
> /home/cfdumitr/git_fdio/vpp/build-root/../src/configure: line 13178: `
> PKG_CHECK_MODULES(g2, gtk+-2.0)'
>
> Makefile:649: recipe for target 'tools-configure' failed
>
> make[1]: *** [tools-configure] Error 2
>
> make[1]: Leaving directory '/home/cfdumitr/git_fdio/vpp/build-root'
>
> Makefile:133: recipe for target 
> '/home/cfdumitr/git_fdio/vpp/build-root/.bootstrap.ok'
> failed
>
> make: *** [/home/cfdumitr/git_fdio/vpp/build-root/.bootstrap.ok] Error 2
>
>
>
> Thanks,
>
> Cristian
>
>
>

The bootstrap target was recently extended to ensure that each
necessary package was indeed installed on the build machine.

You may be missing a package and may need to run "make install-dep"?

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Tap IF Names

[Jon Loeliger]

On Tue, Mar 28, 2017 at 11:50 AM, Damjan Marion (damarion) <
damar...@cisco.com> wrote:

>
> > On 28 Mar 2017, at 12:15, Kinsella, Ray  wrote:
> >
> > +1 to Jon's comments.
> >
> >
> > On 24/03/2017 14:07, Pierre Pfister (ppfister) wrote:
> >> Hello Jon,
> >>
> >> No strong opinion on my side, but I'd just like to notice that there
> might be cases where multiple interfaces, in linux, have the same name, if
> they are in different network namespaces.
> >> VPP could literally control the back-end of thousands of containers'
> interfaces, all called eth0.
> >
> > Well your backend and your frontend device names are typically named
> different. You are correct in that frontend device in the container is
> always eth0, the backend device for each container's eth0 is uniquely named
> in the default network namespace.
>
> Can somebody come up with the patch proposal?
>
> Thanks!


Happy to do so.  One question, though: what is the purpose of
the "renumber" and "custom_dev_instance" fields?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Out of Tree Build Failure on vnet/rewrite.h

[Jon Loeliger]

On Thu, Mar 30, 2017 at 5:42 PM, Ed Warnicke  wrote:

> The more interesting (to me) question is... how did it pass verify?
>
> Ed
>

Ed,

If I might speculate, it isn't anything that the VPP Builds even checks.
To catch this, you have to build VPP to packages, take those packages,
install them on a machine somewhere, now build a C API based
application that uses those installed include files and libraries.

That's what I do; I don't think you guys do that anywhere.

HTH,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Tap IF Names

[Jon Loeliger]

On Tue, Mar 28, 2017 at 11:59 AM, Jon Loeliger <j...@netgate.com> wrote:

>
>
> On Tue, Mar 28, 2017 at 11:50 AM, Damjan Marion (damarion) <
> damar...@cisco.com> wrote:
>
>>
>> > On 28 Mar 2017, at 12:15, Kinsella, Ray <ray.kinse...@intel.com> wrote:
>> >
>> > +1 to Jon's comments.
>> >
>> >
>> > On 24/03/2017 14:07, Pierre Pfister (ppfister) wrote:
>> >> Hello Jon,
>> >>
>> >> No strong opinion on my side, but I'd just like to notice that there
>> might be cases where multiple interfaces, in linux, have the same name, if
>> they are in different network namespaces.
>> >> VPP could literally control the back-end of thousands of containers'
>> interfaces, all called eth0.
>> >
>> > Well your backend and your frontend device names are typically named
>> different. You are correct in that frontend device in the container is
>> always eth0, the backend device for each container's eth0 is uniquely named
>> in the default network namespace.
>>
>> Can somebody come up with the patch proposal?
>>
>> Thanks!
>
>
> Happy to do so.  One question, though: what is the purpose of
> the "renumber" and "custom_dev_instance" fields?
>
> Thanks,
> jdl
>

OK.  I've read through bunch of that custom_dev_instance code now.
I was initially not paying attention to it, as it stumbled into the
so-called
"tapcli" data, and we're not using the VPP CLI.

I think the dev_custom_instance will do what we want (Allow the user
to specify the number that will be used as the "show" name for the
corresponding tap interface.  Good.).

However, I now have a different issue with this code.  Almost all the
code in the tapcli.c file is implementation that should be shared by
both the CLI and the API.  RIght now, the API sort of cannibalizes
into the CLI code.

Instead, there should be three files here: the CLI, the API and the
underlying implementation of Tap data structures.

Will you entertain a patch down that line?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Tap IF Names

[Jon Loeliger]

On Tue, Mar 28, 2017 at 2:28 PM, Pierre Pfister (ppfister) <
ppfis...@cisco.com> wrote:

>
>
> tapcli.c implements all tap nodes, plus the CLI calls.
> tapapi.c only implements api calls and then calls tapcli functions.
>
> Admittedly tapcli is not the perfect name,
>

It's not a matter of names.

but file renaming in git makes the history of changes way harder to follow.
>

I beg to differ. [*1*]


> So I don't think it is necessary to rename tapcli.c
>

Wouldn't do that anyway.  It's not a matter of file names.

My concern is that a pure user of the C API shouldn't drag in
anything to do with the VAT and vppctl CLI command infrastructure.
Having conflated the CLI bits (parsing, param checking, marshalling)
and the CLI output (format(), etc), with the underlying implementaion
of the actual TAP requirements (control sockets, setting the mac
and IP addrs, etc) runs the risk of having the pure C API users
drag in a lot of unneeded CLI code.

There should be a *new* file that has the underlying implementaion
without the CLI bits.


tuntap.c, on the other hand, I think is legacy code. There probably is some
> cleaning to be done there.
>

Haven't peered over there yet... :-/

> - Pierre
>

HTH,
jdl

[*1*] -- http://shop.oreilly.com/product/0636920022862.do
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Tap IF Names

[Jon Loeliger]

On Fri, Mar 24, 2017 at 9:07 AM, Pierre Pfister (ppfister) <
ppfis...@cisco.com> wrote:

> Hello Jon,
>
> No strong opinion on my side, but I'd just like to notice that there might
> be cases where multiple interfaces, in linux, have the same name, if they
> are in different network namespaces.
> VPP could literally control the back-end of thousands of containers'
> interfaces, all called eth0.
>
> I know this is a rather specific use-case, so I understand it might be
> helpful to change the default, but don't make the assumption that linux
> interface names are unique.
>
> - Pierre


Pierre and others,

Where did VPP get the names for those thousands of interfaces?

My point is that having VPP make up names for entities that the
user is going to want to name makes for a very bad UI design and
a bad User Experience.

Instead, the user needs to be in control of the namespace and be
able to predict, or out-right state, the names VPP will assign to
any entity that it allows the user to name.

The Tap interface fails in this regard.  I'm looking for a viable
solution, though.

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Make pkg-rpm seems to be failing...

[Jon Loeliger]

Hi guys,

So, the "make pkg-rpm" target seems to be failing near a
line like this:

# Python bindings
cd /home/jdl/workspace/vpp/build-root/../src/vpp-api/python
%py2_install

That is from the RPM tmp file.  The actual log of the error follows.

Anyone?

Thanks,
jdl




+ for file in '$(find
/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/share/java
-type f -name '\''*.jar'\'' -print )'
+ install -p -m 644
/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/share/java/jvpp-ioamexport-17.04.jar
/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/rpm/BUILDROOT/vpp-1.0.0-1922~g6aa75af~b35.x86_64/usr/share/java
+ cd 
/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/../src/vpp-api/python
+ %py2_install
/var/tmp/rpm-tmp.5NRgE0: line 95: fg: no job control
error: Bad exit status from /var/tmp/rpm-tmp.5NRgE0 (%install)


RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.5NRgE0 (%install)
make[2]: *** [install-rpm] Error 1
make[2]: Leaving directory
`/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root'
make[1]: *** [pkg-rpm] Error 2
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Make pkg-rpm seems to be failing...

[Jon Loeliger]

On Fri, Mar 17, 2017 at 6:33 PM, Burt Silverman  wrote:

> It probably worked during a 12 hour window. I think Neale then made a 2nd
> change incompatible with the earlier change.
>
> Burt
>

Well, yeah, maybe.  But after doing the .end_node dance,
I'm back to the %py2_build problem on a CentOS RPM build
of "make pkg-rpm".

That's building commit:

commit 898273fbb588811824bb27ad0ef203d358a7121a
Author: Neale Ranns 
Date:   Sat Mar 18 02:57:38 2017 -0700

Check change in unnumbered setting before updating IP enabled state

Using "make bootstrap; make build-release; make pkg-rpm".

HTH,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Questions about AF_PACKET and VNET_DEVICE_CLASS Functions

[Jon Loeliger]

Folks,

I am trying to understand a bit more about the "host" interface
for some AF_PACKET interfaces.

Currently, there is a single API call to create an AF_PACKET interface.
It simultaneously sets the HW_ADDR (ie, MAC address) of the interface
to either  user-specified value, or a randomly generated value.

I'd like to separate the two steps, or at the very least, be able to set
the MAC address in a separate API call that isn't the initial CREATE call.
Why?  Imagine the sequence of commands that might look like this:

# interface host fred
#mac 11:22:33:44:55:66
#no shutdown
# exit

So, at the time of "interface host fred", we'd like to cause the interface
to be created, but the MAC isn't really available yet.  Then later, when
we see the "mac " line, we'd like to set, or change, the MAC with the
new user-supplied value.

In the case of a "normal" or DPDK interface, the VNET_DEVICE_CLASS
functions specify a .mac_addr_change_function.  Roughly from
src/plugins/dpdk/device/device.c lines 774 or so:

VNET_DEVICE_CLASS (dpdk_device_class) = {
.mac_addr_change_function = dpdk_set_mac_address,
};

That's all well and good.

Naturally, no such mac_addr_change_function exists for the
AF_PACKET device class.

My question is:  Is there a fundamental reason that prevents such
a function from being written, or is it a case of simply "we just haven't
gotten to that detail yet"?  The latter case implying that someone
could actually achieve a MAC addr change on the AF_PACKET
interface, if an enterprising young engineer were to, say, write a new
API function to get there.

So, yeah, I know the actual MAC might not be really important, but
maybe the user is trying to match some external requirement or so?
I don't know.

Thoughts?
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Strange C Dyanmic Loading Failure

[Jon Loeliger]

Dave,

With the advent of a compiling tree (hooray!), I've updated, rebuilt,
installed, and tried running all the C libraries and API pieces again.
Sadly, things are not working.

Very early in the bring-up of a C executable that is linked to VPP's
libraries
(vlibmemoryclient vlibapi svm vppinfra), it goes into the weeds trying to
load some statically configured CLI initialization functions dynamically:

That error looks like this:

Program received signal SIGSEGV, Segmentation fault.
__vlib_cli_command_registration_cli_show_api_histogram_command ()
at //vpp/src/vlibmemory/memory_vlib.c:727
727 VLIB_CLI_COMMAND (cli_show_api_histogram_command, static) = {
Missing separate debuginfos, use: debuginfo-install clixon-3.2-0.x86_64
(gdb) where
#0  __vlib_cli_command_registration_cli_show_api_histogram_command ()
at //vpp/src/vlibmemory/memory_vlib.c:727
#1  0x77dec1e3 in call_init (env=0x7fffe3d0,
argv=0x7fffe398,
argc=6, l=) at dl-init.c:82
#2  _dl_init (main_map=main_map@entry=0x760790, argc=6, argv=0x7fffe398,
env=0x7fffe3d0) at dl-init.c:131
#3  0x77df08f6 in dl_open_worker (a=a@entry=0x7fffde28)
at dl-open.c:560
#4  0x77debff4 in _dl_catch_error (
objname=objname@entry=0x7fffde18,
errstring=errstring@entry=0x7fffde20,
mallocedp=mallocedp@entry=0x7fffde10,
operate=operate@entry=0x77df0540 ,
args=args@entry=0x7fffde28) at dl-error.c:177
#5  0x77deffeb in _dl_open (
file=0x77ff3f20 "/../vpp_backend.so",
mode=-2147483646, caller_dlopen=, nsid=-2, argc=6,
argv=0x7fffe398, env=0x7fffe3d0) at dl-open.c:650


As we are not using any aspect of the VPP project's actual CLI code,
there is no way we should be loading anything like a CLI command.

I suspect that this init data structure (line 727 of
src/vlibmemory/memory_vlib.c)
is incorrectly present in the API library due to some *other* symbol in
this object
file being referenced and dragging in the CLI init piece accidentally.

Here is line 727:

VLIB_CLI_COMMAND (cli_show_api_histogram_command, static) = {
.path = "show api histogram",
.short_help = "show api histogram",
.function = vl_api_show_histogram_command,
};


I have git bisected the introduction of this bad behavior to this commit:

80f54e20270ed0628ee725e3e3c515731a0188f2
Author: Dave Barach 
Date:   Wed Mar 8 19:08:56 2017 -0500

vlib_mains == 0 special cases be gone

Clean up spurious binary API client link dependency on libvlib.so,
which managed to hide behind vlib_mains == 0 checks reached by
VLIB_xxx_FUNCTION macros.

Change-Id: I5df1f8ab07dca1944250e643ccf06e60a8462325
Signed-off-by: Dave Barach 

If no one beats me to it, I'll try to isolate it a bit more tomorrow.

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Strange C Dyanmic Loading Failure

[Jon Loeliger]

On Mon, Mar 20, 2017 at 9:18 PM, Jon Loeliger <j...@netgate.com> wrote:

> Dave,
>
> With the advent of a compiling tree (hooray!), I've updated, rebuilt,
> installed, and tried running all the C libraries and API pieces again.
> Sadly, things are not working.
>
> Very early in the bring-up of a C executable that is linked to VPP's
> libraries
> (vlibmemoryclient vlibapi svm vppinfra), it goes into the weeds trying to
> load some statically configured CLI initialization functions dynamically:
>
>

> 80f54e20270ed0628ee725e3e3c515731a0188f2
> Author: Dave Barach <d...@barachs.net>
> Date:   Wed Mar 8 19:08:56 2017 -0500
>
> vlib_mains == 0 special cases be gone
>
> Clean up spurious binary API client link dependency on libvlib.so,
> which managed to hide behind vlib_mains == 0 checks reached by
> VLIB_xxx_FUNCTION macros.
>
> Change-Id: I5df1f8ab07dca1944250e643ccf06e60a8462325
> Signed-off-by: Dave Barach <d...@barachs.net>
>

Also, if one simply 'git reverts' this one commit on the current top
of tree, things resume working again.

HTH,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Some L2 Bridge API Questions

[Jon Loeliger]

Hi folks,

I have a few questions about the sw_interface_set_l2_bridge API message.
Now, some people have called me a "pedantic ass", to my face even,
so I can handle that.  :-)  And I wouldn't want to disappoint, so here we
go...

>From commit 374e2c5fc30a5bfabfd2eb6c2d3ca5797402af16, line 640
of src/vpp/api/vpe.api:

   640  /** \brief Interface bridge mode request
   641  @param client_index - opaque cookie to identify the sender
   642  @param context - sender context, to match reply w/ request
   643  @param rx_sw_if_index - the interface
   644  @param bd_id - bridge domain id
   645  @param bvi - Setup interface as a bvi, bridge mode only
   646  @param shg - Shared horizon group, for bridge mode only
   647  @param enable - Enable beige mode if not 0, else set to L3 mode
   648  */
   649  define sw_interface_set_l2_bridge
   650  {
   651u32 client_index;
   652u32 context;
   653u32 rx_sw_if_index;
   654u32 bd_id;
   655u8 shg;
   656u8 bvi;
   657u8 enable;
   658  };

I want to pick on the "u8 enable" field.  First, the easy one: Line 647 has
a typo for "bridge", right?  OK, good.  But let's talk about
"enable/disable"
versus "add/del".   Is this really an enable/disable flag?  So once "added"
to the interface at rx_sw_if_index, there is no removing it?  Or did
"disable"
really remove it?  Many of the other API calls have an "is_add" field.  Is
there
really no way to remove it once added?

How is one expected to change a flag on this bridge?  For example, to
change the BVI from "false" to "true" after it has been established,
("enabled",
right?) does one just re-issue the same API call again with the new bvi
"true"
value?  Or should the bridge be "disabled", flag changed, and then
re-"enabled"?
Or even the interface shutdown, changed, and then brought back up?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Some L2 Bridge API Questions

[Jon Loeliger]

On Tue, Mar 14, 2017 at 1:50 PM, John Lo (loj)  wrote:

> Hi Jon,
>

Hi John,


> You make a valid point about the name chosen for the API param “enable”.
> Rather than argue about the best name, let me describe how it works.
>

Sure!


> The API is intended to enable or disable an interface in L2 bridging mode.
> By disable, or enable=0, it will put the interface back to L3 mode which is
> the default mode for an interface.  If the API  is called with enable=1
> while the interface is already in L2 bridging mode, the code would actually
> perform a disable followed by enable of the interface’s current bridging
> mode as specified.
>

Ah, OK.  So at that time (the re-enable), and differing parameter
would being to take effect.  So simply re-issuing the API call
with the new parameters and an "enable" will be sufficient.

So there isn't a way to remove the bridge from the interface once
it has been associated the first time?  Or will that be accomplished
by actually removing the bridge from the bridge table?  Even if
the bridge_domain ID is left dangling on the interface?


> I take your point and will remember to update its comment in the API file,
> including fix the typo for “bridge”.
>

Thanks!
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Missing lib pneum during build?

[Jon Loeliger]

On Fri, Mar 17, 2017 at 3:57 AM,  wrote:

> Jon,
>
> >
> > I am no fairly confident that this patch fixes the race condition issue
> > that I was seeing.
> >
> > Now.  I am now failry confident
>

Wow.  I suck at this typing ting! :-)


> > And I am still seeing the build failure.  Is there any chance
> > of getting this patch or a similar fix in place?
>
> Yes, that should now be taken care of with https://gerrit.fd.io/r/#/c/
> 5666/
>
> Best regards,
> Ole
>

Awesome!  Thank you!

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Some L2 Bridge API Questions

[Jon Loeliger]

John,

So, I see that, when creating a bridge domain using the API
call bridge_domain_add_del, one can specify some feature
flags of the domain as well as the mac-age parameter.

Later, it looks like one can alter the feature flags using the
API call bridge_flags, changing one or more features to be
enabled or disabled on the fly.

However, it looks like there is no mechanism to alter just
the mac-age parameter.

So, a few questions.  Is one expected to re-issue the bridge
domain "add" request again, with all the same flag-bits, but
with the new mac-age value?  Or is this just a missing API
call that is yet to be added?

In particular, I notice that the code in src/vnet/l2/l2_bd.c has a
command to set a new mac-age, but it doesn't make an API
call to do so; instead it appears to go directly to the underlying
implementation to affect a change.

Any advice here?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Missing lib pneum during build?

[Jon Loeliger]

On Fri, Mar 10, 2017 at 1:55 PM, Jon Loeliger <j...@netgate.com> wrote:
>
>
> Ole,
>
> I am no fairly confident that this patch fixes the race condition issue
> that I was seeing.
>

Now.  I am now failry confident

And I am still seeing the build failure.  Is there any chance
of getting this patch or a similar fix in place?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Missing lib pneum during build?

[Jon Loeliger]

On Wed, Mar 8, 2017 at 2:16 AM, <otr...@employees.org> wrote:

> Jon,
>
>
> > On 8 Mar 2017, at 01:34, Jon Loeliger <j...@netgate.com> wrote:
> >
> > On Mon, Mar 6, 2017 at 2:57 PM, Jon Loeliger <j...@netgate.com> wrote:
> >
> > S, despite the Peanut Gallery, I'm not yet crazy... :-)
> >
> > Now all we have to do is find the missing dependency in a Makefile! :-)
>
>
> I have also seen this error. What I suspect happens is that while pneum is
> already built and that the build dependency is correct, the library isn't
> installed under the install- directory yet.
>
> I didn't manage to reproduce it right now, but would you mind trying this
> to see if it works:
>
> diff --git a/src/vpp-api/python/Makefile.am b/src/vpp-api/python/Makefile.
> am
> index 5407682..c60e4f4 100644
> --- a/src/vpp-api/python/Makefile.am
> +++ b/src/vpp-api/python/Makefile.am
> @@ -39,7 +39,7 @@ libpneum_la_LDFLAGS = -module
>  libpneum_la_CPPFLAGS =
>
>  # TODO: Support both Python 2 and 3.
> -install-exec-local:
> +install-exec-local: install-libLTLIBRARIES
> cd $(srcdir);   \
> mkdir -p $(pythondir);  \
> mkdir -p $(pyexecdir);  \
>
>
> (In other news I am looking at using CFFI instead, and then the whole
> vpp_api.so would go away).
>
> Cheers,
> Ole
>

Hi Ole,

I am still working on confirming or refuting this patch.

Naturally, since you sent that, my build server has failed to show
the problem in, oh 20 builds or so.  It used to fail 50% of the time...
So I continue to build...

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Missing session.api.h file

[Jon Loeliger]

VPP-ers,

I've just build RPM packages out of the current top-of-tree VPP at
commit c83c3b7f117b981b677f646a0e30f44ec70de239.

After a yum install, a file in /usr/include/ references session.api.h:

$ grep -r session.api.h /usr/include/
/usr/include/vnet/vnet_all_api_h.h:#include 

Yet it is not installed:

$ find /usr/include -name session\*
/usr/include/vnet/session
/usr/include/vnet/session/session.h

In fact, if you look in the RPM build staging directory, it is missing
there as well:

$ find  build-root/install-vpp-native/vpp/include/ -name session\*
build-root/install-vpp-native/vpp/include/vnet/session
build-root/install-vpp-native/vpp/include/vnet/session/session.h

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Missing session.api.h file

[Jon Loeliger]

On Fri, Mar 3, 2017 at 7:11 PM, Jon Loeliger <j...@netgate.com> wrote:

> On Fri, Mar 3, 2017 at 6:54 PM, Florin Coras <fcoras.li...@gmail.com>
> wrote:
>
>> Hi Jon,
>>
>> Apologies about that. Alexander was kind enough to provide a quick
>> solution here [1]. Will merge as soon as it passes verify.
>>
>> Florin
>>
>
>
> Awesome!  Thank you!
>
> jdl
>

That seems to have worked!

Thank you!


So, a different question now  Did something change about the
order or intended correct inclusion of the API message files?
That might be vague, sorry...

I'm now seeing these messages on VPP startup.

/usr/bin/vpp[2599]: vl_msg_api_config:672: BUG: multiple registrations of
'vl_api_sw_interface_tag_add_del_reply_t_handler'

It all seems to be working so far, but am I somehow managing
to call in an API registration for each message twice now?
Like, did the include files somehow end up doubled up or something?

Yeah, I don't know either yet...

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Missing session.api.h file

[Jon Loeliger]

On Fri, Mar 3, 2017 at 6:54 PM, Florin Coras  wrote:

> Hi Jon,
>
> Apologies about that. Alexander was kind enough to provide a quick
> solution here [1]. Will merge as soon as it passes verify.
>
> Florin
>


Awesome!  Thank you!

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Missing lib pneum during build?

[Jon Loeliger]

On Wed, Mar 8, 2017 at 2:16 AM,  wrote:

> Jon,
>
> I have also seen this error. What I suspect happens is that while pneum is
> already built and that the build dependency is correct, the library isn't
> installed under the install- directory yet.
>
> I didn't manage to reproduce it right now, but would you mind trying this
> to see if it works:
>
> diff --git a/src/vpp-api/python/Makefile.am b/src/vpp-api/python/Makefile.
> am
> index 5407682..c60e4f4 100644
> --- a/src/vpp-api/python/Makefile.am
> +++ b/src/vpp-api/python/Makefile.am
> @@ -39,7 +39,7 @@ libpneum_la_LDFLAGS = -module
>  libpneum_la_CPPFLAGS =
>
>  # TODO: Support both Python 2 and 3.
> -install-exec-local:
> +install-exec-local: install-libLTLIBRARIES
> cd $(srcdir);   \
> mkdir -p $(pythondir);  \
> mkdir -p $(pyexecdir);  \
>
>
> (In other news I am looking at using CFFI instead, and then the whole
> vpp_api.so would go away).
>
> Cheers,
> Ole
>

Ole,

I am no fairly confident that this patch fixes the race condition issue
that I was seeing.

At first, I was seeing a failure at about a 1 in 3 rate.  That backed off
to about 1 in 9 recently.  No idea why...

However, after applying this patch, I've run more than 30 builds
successfully without a failure now.

I've not done the statistics to determine how confident I am. :-)
But I say go with it!   I'll watch for it and let you know if it resurfaces!

Thank you!
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Missing lib pneum during build?

[Jon Loeliger]

Guys,

I am in the process of setting up a CI engine here.  (Whee!)
This is on an entirely new machine with a new number of CPUs, etc.
What I'm noticing is that every other build or so fails.  And it seems
to be for lack of a -lpneum each time it fails.  But sometimes it all
builds properly too.

What I'm thinking is that we have another missing dependency in
the Makefile somewhere that is allowing an out-of-order reference
to the pneum library prior to it really being ready.  (We had a problem
like this a few months ago too.  Blah.)

Anyone else seen anything like this?  Am I out in the weeds?

Logs from around the build failure below...

Thanks
jdl



mkdir -p 
/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/lib/python2.7/site-packages;
   \
mkdir -p 
/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/lib64/python2.7/site-packages;
\
PYTHONUSERBASE=/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp
  \
python setup.py build_ext -L
/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/lib64
   \
-I 
/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/include/
install --user
 /bin/mkdir -p 
'/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/lib64'
 /bin/mkdir -p 
'/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/include'
 /bin/sh ../../libtool --quiet  --mode=install /bin/install -c
libpneum.la 
'/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/lib64'
 /bin/mkdir -p 
'/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/include/pneum'
 /bin/install -c -m 644
/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-data/../src/vpp-api/python/pneum/pneum.h
'/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/include/pneum'
libtool: install: warning: relinking `libpneum.la'
running build_ext
building 'vpp_api' extension
creating build
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/vpp_papi
gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic
-D_GNU_SOURCE -fPIC -fwrapv -fPIC
-I/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/include/
-I/usr/include/python2.7 -c vpp_papi/pneum_wrap.c -o
build/temp.linux-x86_64-2.7/vpp_papi/pneum_wrap.o
creating build/lib.linux-x86_64-2.7
gcc -pthread -shared -Wl,-z,relro
build/temp.linux-x86_64-2.7/vpp_papi/pneum_wrap.o
-L/var/lib/jenkins/workspace/build-ngr-rpm/build_root/BUILD/vpp/build-root/install-vpp-native/vpp/lib64
-L. -lpneum -lpython2.7 -o build/lib.linux-x86_64-2.7/vpp_api.so
/bin/ld: cannot find -lpneum
collect2: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Missing lib pneum during build?

[Jon Loeliger]

On Mon, Mar 6, 2017 at 2:48 PM, Billy McFall  wrote:

> I have seen this. I was compiling in a VM with 5 CPUs. I isolate CPUs 1-4
> from Linux via kernel cmdline arg isocpu. When compiling with 1 CPU I saw
> the issue every time. Removed isocpu and compiled with 5 CPUs everything
> worked.
>
> Billy McFall
>

Hi Billy,

S, despite the Peanut Gallery, I'm not yet crazy... :-)

Now all we have to do is find the missing dependency in a Makefile! :-)

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Missing session.api.h file

[Jon Loeliger]

On Sat, Mar 4, 2017 at 7:57 AM, Dave Barach (dbarach) <dbar...@cisco.com>
wrote:

> See https://gerrit.fd.io/r/#/c/5622...
>
>
>
> Thanks… Dave
>
>
>
> *From:* Dave Barach (dbarach)
> *Sent:* Friday, March 3, 2017 10:50 PM
> *To:* Jon Loeliger <j...@netgate.com>
> *Cc:* Florin Coras <fcoras.li...@gmail.com>; vpp-dev <vpp-dev@lists.fd.io>
> *Subject:* RE: [vpp-dev] Missing session.api.h file
>
>
>
> Oh, no need to bisect or otherwise screw around. I found the problem.
>
>
>
> Too many routines called “vat_api_hookup” floating around, resulting in
> repeated calls to the version in api_format.c. I caught the dpdk plugin
> doing it, and I think there’s at least one more.
>
>
>
> I’ll fix it in the morning. I’m too sleepy to do it accurately right now.
>
>
>
> Thanks… Dave
>

Dave,

Your patch cleared that problem up nicely!

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Out of Tree Build Failure on vnet/rewrite.h

[Jon Loeliger]

On Fri, Mar 31, 2017 at 7:34 AM, Jim Thompson  wrote:

>
> Either that, or Cisco moves to builds apps the same way. You guys & gals
> break the tree for us about twice per month lately.
>

Hi VPP-ites,

That's maybe not such a bad notion.  What about taking, say, the
entire VAT piece out of VPP proper, and making it a standalone project
that is built using an installed RPM/DEB VPP build instead?

Sure, it would be a bit of a pain for some developer, but it would also
help to crystalize the boundaries between VPP-proper and CLI/API
users as well.  As it is, there are some fairly serious cross-over issues
that are discovered as we stumble through our development as an
API-only-user application.  (This issue, the CLI directly using some
functions instead of an API, is what lead me to introduce a patch for
the "set MAC address API", for example.)

HTH,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] A Curious DHCP Hostname Terminator Choice

[Jon Loeliger]

Hi Guys,

Way over in src/vnet/dhcp/dhcp_api.c, we find the function

void
dhcp_compl_event_callback (u32 client_index, u32 pid, u8 * hostname,
   u8 is_ipv6, u8 * host_address, u8 *
router_address,
   u8 * host_mac)

which contains a curious use of the newline character:

  mp = vl_msg_api_alloc (sizeof (*mp));
  mp->client_index = client_index;
  mp->pid = pid;
  mp->is_ipv6 = is_ipv6;
  clib_memcpy (>hostname, hostname, vec_len (hostname));
  mp->hostname[vec_len (hostname) + 1] = '\n';
  clib_memcpy (>host_address[0], host_address, 16);
  clib_memcpy (>router_address[0], router_address, 16);

So, is that '\n' supposed to be 0 instead?
Or is that value used in some odd location that requires an
actual newline here?
What happens if the user supplies a hostname of exactly 63
octets and this newline is added?  There is at least one
use of strncpy() on this hostname value, so it seems fragile
to me at the fencepost.

Pedantically yours,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] A Curious DHCP Hostname Terminator Choice

[Jon Loeliger]

On Wed, Apr 26, 2017 at 3:37 PM, Luke, Chris <chris_l...@comcast.com> wrote:

> Definitely looks spurious to me.
>
>
>
> Chris.
>

Spurious or wrong?

Will folks entertain a patch converting that newline to a 0?

jdl


> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Jon Loeliger
> *Sent:* Wednesday, April 26, 2017 4:24 PM
> *To:* vpp-dev <vpp-dev@lists.fd.io>
> *Subject:* [vpp-dev] A Curious DHCP Hostname Terminator Choice
>
>
>
> Hi Guys,
>
>
>
> Way over in src/vnet/dhcp/dhcp_api.c, we find the function
>
>
>
>
>   clib_memcpy (>hostname, hostname, vec_len (hostname));
>
>   mp->hostname[vec_len (hostname) + 1] = '\n';
>
>   clib_memcpy (>host_address[0], host_address, 16);
>
>   clib_memcpy (>router_address[0], router_address, 16);
>
>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] A Curious DHCP Hostname Terminator Choice

[Jon Loeliger]

On Thu, Apr 27, 2017 at 12:19 PM, Luke, Chris 
wrote:

> It looks, to me, like someone fixed a problem in the wrong place.
>
>
>
> I would certainly entertain the patch, especially if it included logic to
> make sure mp->hostname doesn’t overrun. Not likely since the DHCP option is
> limited to the same size but it’s still good practice. What I am not sure
> of is NUL in DHCP hostname strings – I remember reading somewhere it’s
> optional, so I suspect that means the TLV length is used to determine the
> string length; meaning it might be possible to have a hostname that is 64
> printable characters long. Maybe.
>

According to my RFC digging, 1 to 63 characters.

NUL is not a valid hostname character.

HTH,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Bridge Domain Dump API Inconsistency Question

[Jon Loeliger]

On Mon, May 1, 2017 at 6:26 PM, John Lo (loj)  wrote:

> Hi Jon,
>
>
>
> I agree we should fix CLI/API to not allow BD 0 modifications. Would you
> be interested to submit a patch for it? J   Otherwise, I will try to fix
> it when I get a chance.
>
>
>
> Regards,
>
> John
>

John,

I am happy to submit a patch to prevent tinkering with BD 0.
And not print it in the CLI.

In which case, I'll abandon the other, verified patch I already have
submitted to allow the API to report on BD 0.

HTH,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Bridge Domain Dump API Inconsistency Question

[Jon Loeliger]

On Mon, May 1, 2017 at 5:56 PM, John Lo (loj)  wrote:

> Hi Jon,
>
>
>
> The bridge domain (BD) 0 is created by VPP on startup to be a dummy BD and
> not intended to be used by user. BD 0 is created with everything turned off
> to drop packets in it. It is used by VPP to handle the transition of
> changing interface between L2 bridging and L3 mode so that if a packet is
> received or sent during the transition, the packet will default to BD 0 and
> be dropped safely without crashing VPP. This is why BD 0 is not shown in BD
> dump as it should not be used.
>

Thanks, John.

I understand what it is, where it is created, and why.

The end user is allowed to modify its configuration, though.
The end user should be able to inspect its settings.

If the user was not able to change its config, then it would
make sense to not dump its details as they would be known
and static.

If it should not be "used" (and I assume you mean "modified"),
because users do use it for packet processing purposes, then
the CLI and API should consistently enforce and reject requests
to modify BDI == 0.

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Question: make realclean

[Jon Loeliger]

Naturally, I meant "make distclean" on the Subject: line. :-)

On Wed, May 3, 2017 at 10:20 AM, Jon Loeliger <j...@netgate.com> wrote:

> Hey VPP Builders,
>
> Do you ever use "cd build-root; make distclean"?
> Does it look sort of like this:
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Question: make realclean

[Jon Loeliger]

On Wed, May 3, 2017 at 1:39 PM, Thomas F Herbert <therb...@redhat.com>
wrote:
>
> On 05/03/2017 12:23 PM, Jon Loeliger wrote:
>
> Naturally, I meant "make distclean" on the Subject: line. :-)
>
> distclean removes the tarball created by the "make dist" target.
>

OK, but, so?

I think I missed your point.

My point was that the "make distclean" is trying to remove
RPM packages from a location that no longer holds them.
And subsequently, it does not remove them from the directory
that *does* hold them.

Was that somehow intentional?  It looks broken to me.

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] ACL API Questions

[Jon Loeliger]

Folks,

I have two questions about the ACL plugin's API.

First, when there are no ACLs configured and an ACL_DUMP is requested,
there is no way for the API to reply except to not send a message and let
the "wait for message" time-out and indicate failure.  The same problem
exists if one requests ACL_INTERFACE_LIST_DUMP and there are no
interfaces with an ACL on them.

This seems like a very fragile interaction to me.  It also induces a delay
in the messaging which is quite noticeable in an interactive session.

Second, as there is no notion of CONTROL_PING in the ACL API it seems
like we can get into synchronization problems with the DUMP messages.

Am I missing something again? :-)

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] ACL API Questions

[Jon Loeliger]

On Wed, May 17, 2017 at 4:35 PM, Andrew  Yourtchenko 
wrote:

> Jon,
>
> No, you are not missing anything, there is a ping missing there indeed...
> :-)
>

Hi Andrew,

OK, *phew*.  Not this time then.  Good to know!


> At the time I could not figure out how to get the CONTROL_PING to be
> sent from within the VAT, and since the main use case was
> programmatic-API driven (I had used VAT primarily during the initial
> debugging/sanity checks), it fell through the cracks. Appears the
> solution is not trivial though - the SNAT plugin seems to define its
> own CONTROL_PING flavour ping, with its own reply code which is
> exactly the same as the "real" CONTROL_PING handler...
>
> That seems a bit wasteful
>

There are two competing factors at work there.

One can not #include both the VPE message enum file and the
plugin's message enum file.  The issue is conflicting notions of
the LAST_MESSAGE.

The reason SNAT has its own CONTROL_PING is so that when the
plugin is used in stand-alone testing, it can have a CONTROL_PING
to coordinate its DUMP messaging synchronization.

Technically, it doesn't need to have its own; it could use the CONTROL_PING
from VPE, except for the stand-alone case where it wouldn't be present.

I wrote a simple interface to the VPE control ping like this:

int vmgmt_control_ping_sync(void)
{
vl_api_control_ping_t *mp_ping;
int ret;

vmgmt_msg_alloc(VL_API_CONTROL_PING, mp_ping);
vmgmt_msg_send((u8 *)_ping);

ret = vmgmt_msg_wait();

return ret;
}

and have used that in the ACL code to gain synchronization with
its REPLY and DETAILS handlers.

But, for ACL to continue to have a standalone testing mechanism,
I think it will need to have its own ACL_CONTROL_PING added
just like SNAT does.

I am pretty sure this will generalize to all of the VPP plugins that
send/receive messages.

HTH,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] The Case Of the Missing API Definition

[Jon Loeliger]

On Wed, May 24, 2017 at 2:00 AM,   wrote:
> Hi Jon,

Hi Ole,

> Thanks for the poetry! ;-)

Most welcome.

> This is me in 01384fe
> Apologies for that. Next time I see you let me bring both band aid and 
> whiskey.

Apology accepted!

> To my excuse, there has been this list of "broken" APIs maintained by the
> Python and Java language binding implementors.

See?  Java is bad for you. :-)

> It's been on the todo list for a long time and I finally found some time to
> deal with them. Obviously not everyone was aware of those planned
> changes. I did include those I thought affected as code reviewers. #fail.

It's OK, really.  I've been making a pretty systematic march
through many of the VPP API areas, so there's no telling what
or where I'll be poking next... :-)

> I feel your pain. How can we make this better?
> 1) Never change APIs, regardless the reason
> 2) Announce and discuss changes a priori. Separate mailing list for
> API changes?
> {vpp-users, vpp-api-announce}
> 3) ...

This is a really good question.  I confess it is also a difficult one.
We certainly can't abide by 1) Never change APIs.  That is just not
a realistic approach.

I follow the vpp-dev list pretty regularly these days, and I try
to watch the upcoming Gerrit patches and reviews.  And I try
to keep our VPP repo up-to-date WRT the fd.io Git repo; I pull
maybe every couple days or so.

So for me, I am willing to suffer a bit of tip-of-tree development
pain and angst.  Even fixing this API call removal wasn't that
difficult for our code.

I think the thing that was most troubling for me was getting it
pretty much without warning.  So I think at the very least, it
would be good to make a statement on the vpp-dev list.

But when?  Certainly it would be nice if it were in advance of
the patch being committed.  I realize that may not always be
possible.  But some indication on the list as it is being committed
would also be nice.  Maybe even some indication from the patch
author on list like "Hey, I have a patch in review that removes
*this* API call.  If you are using it you will need to change your
code like _this_."

The process of adding API calls, and even changing an existing
one is easier, of course.  But still, some advance notice would
be appreciated.

How hard would it be to have a Jenkins nightly build job that
diff'ed yesterday's complete API list versus today's list and
generated sent that diff mail?  Dunno.  Just an idea.

> Do we reach everyone using vpp on  vpp-dev and a heads-up there
> would suffice?

Quite possibly.  I don't really have a feel for how many people
use each of the various APIs for active development these days.
It may very well justify a specific vpp-api-discussion list or so.

> Cheers,
> Ole

HTH,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Subif/VLAN Questions

[Jon Loeliger]

Hey Audience,

Guess what!  (What?)

I have another set of questions!

This time, VLAN/Subif related.  Start with the easy one:  Is the API call
create_vlan_subif slated for removal or deprecation?  I think it should be.
It seems to me to be totally redundant and a subset of the more general
API call create_subif.  Under the covers, they resolve to an identical SW
interface creation function as well.  Or have I missed something here?

So the mystery question now:  Why is there no mechanism to delete an
L2 interface VLAN tag rewrite rule?  Sure, one can apply a "disable"
operation to the subif, but that is not the same as removing the rewrite
rule.  Is it expected that the user will just remove the whole subif to
achieve this effect?

And the question of inconsistency:  Why does the l2_interface_vlan_tag_rewrite
API call only use u32 values, even for fields that are clearly only, say, a u16
or u8?  Seems like everywhere else things have been meticulously sized; just
not on this call.

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP API improvements - community discussion.

[Jon Loeliger]

On Mon, Jun 5, 2017 at 5:24 AM, Neale Ranns (nranns)  wrote:
>
> Dear VPP community,
>
> Some of the feedback we get from users of VPP is that the client-side API is 
> not particularly user-friendly – we would like to address this.

I don't know about user friendly; I can wade through the technical details.

I think one thing that is annoying about the API is a lack of consistency.
Here are some examples:

- Sometimes the flag is "u8 is_ipv4", other times it is "u8 is_ipv6".
- Sometimes the flag is "u8 is_ip4", other times it is "u8 is_ip6".

- Sometimes the flag is "u8 is_add", or "u8 is_del", or "u32 is_add".
- "is_enable" vs "is_enabled"
- Some API calls are "foo_add_del", some are "foo_add_replace",
  and some are "foo_add" and "foo_del"

I know that sounds trivial.  I get that.  But it makes for tough anticipation
and violates some principle of least-surprise-or-another.

I get that different people work on different areas, but there needs to
be some consistency both in the names of the API calls and within
the API fields themselves.

It would be documentationally nice for the API comment blocks to
explicitly denote what default values pertain to the fields of an API call.
Similarly, denote what the values of the "invalid" entry are.  Is it 0?
Or is it -1 or is it ~0?


> Naturally ☺ In order to create an API that the user community considers 
> effective, easy and intuitive to use, it must be a community wide discussion. 
> To kick-start that discussion, and to provide some initial focus on the 
> specific topics, the document below outlines a set of proposals that we hope 
> moves us in this direction.

Is there an explicit list of common complaints that we could work against?
As we all know "It sucks." is pretty generic and hard to fix... :-)

>
> please let us know any opinions you have on this topic, or feedback, 
> suggestions, additions, etc to the document, either by replying to this 
> thread, unicasting me, or by adding comments directly to the document.
>
> Thanks in advance,
>
> Neale

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Bridge Domain Dump API Inconsistency Question

[Jon Loeliger]

Folks,

There are currently two utilities that cause a print-out of the bridge
domain information:  vppctl and vpp_api_test.

Let's talk about the default  Bridge Domain 0 for a moment.  You, as the
user of the system, can talk about, name it, reference it and use it, but
neither create nor destroy it as it is the default domain.  That's all good
and wonderful.

So let's say we have three bridge domains configured: 0, 1 and 14.
And we use vppctl to see them:

vpp# show bridge
  ID   Index   BSN  Age(min)  Learning  U-Forwrd  UU-Flood  Flooding
 ARP-Term  BVI-Intf
  0  0  0 off   off   off   off   off   off
 local0
  1  1  0 offonononon   off
  N/A
  14 2  0 off   offononon   off
  N/A

And then we turn around and use vpp_api_test to do the same:

vat# bridge_domain_dump

 ID LRN FWD FLD BVI #IF
  1   1   1   1  -1   0

 ID LRN FWD FLD BVI #IF
 14   0   1   1  -1   0

My question is: Why doesn't the BRIDGE_DOMAIN_DUMP API call
also send the details about BDI 0 too?  The only way an end user
will be able to see that configuration is through this API call, and
given that the user can modify the Domain 0 configuration, the
user should be able to confirm the settings as well.

Allowing the CLI to go directly to the internal data structures for its
"dump" or "show" commands is a serious pit-fall.

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Questions regarding running VPP in KVM VM and the C API

[Jon Loeliger]

On Thu, May 4, 2017 at 7:45 AM, Tomas Brännström <
tomas.a.brannst...@tieto.com> wrote:

> Hello
>
> Is there something specific that must be done to get VPP running in a KVM
> VM?
>

I'm sorry --- I can't really speak to KVM specific issues.


> 2) I have made a tiny client where I want to test sending a message to a
> loaded plugin. I've been following the guide on the wiki (
> https://wiki.fd.io/view/VPP/How_To_Use_The_C_API)
>

As they say in the surprised void, "Oh wow!" ... :-)


> as well as looking at other test clients code. The problem I'm having is
> that when trying to get the message id base VPP prints 
> "*msg_handler_internal:429:
> no handler for msg id 11*" and returns ~0.
>

So, you are trying to use message id 11.  429 is the source code line
number issuing the error message.


> The `vl_client_connect_to_vlib' call seems to work OK so (I think) I have
> a connection to vpp.
>
> Maybe I'm misunderstanding something with how this actually works. Is it
> supposed to be possible to run separate applications that "connects" to the
> running VPP instance to send message etc., or is this only possible to do
> from a plugin?
>

The VPE base is not considered a plugin.  However, there are
other pieces (SNAT, ACL, etc) that are plugins.  If your message
is from VPE, it's not a plugin, and the "base message id" is 0 in
this case.

Are you using something close to the top-of-tree code?  Or is this
some point-release?  The reason I ask is I think message id 11 is
VL_API_GET_FIRST_MSG_ID_REPLY from vlibmemory/memclnt.api.h.

So you are not registering to handle that message, and I think that
message should be coming in semi-automatically if you have all of
the parts lined up and loading correctly.  (And furthermore, you should
not be registering for that message reply.)

Are you sure you are using the VPE module?  You need to.

HTH,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Static Route Data API Data Structures

[Jon Loeliger]

On Tue, Aug 29, 2017 at 9:37 AM, Neale Ranns (nranns)  wrote:
>
> Hi Jon,
>
> The new API does not function correctly in master at this time. If you want 
> to ride on the bleeding edge with the new API, the code I intend to commit is 
> (complete AFAICT) here:
>   https://gerrit.fd.io/r/#/c/7819/
>
> it’s not committed yet because I need to do an n-step dance with CSIT changes 
> to make the verify jobs pass. This will take a few weeks (because vacations).
>
> Regards,
> neale


Hi Neale,

Hope your vacation went well!

Glad to see you are back at The Salt Mines, though!  Any chance for
a brief update on the progress of this whole Route Table re-work effort?
Specifically, I have code poised to use the "add_del_table" API call, and
I *think* that I can do that now.  But can I remove the soon-to-be-obsolete
create_table_if_needed flag yet?

Also, I read a comment about the need to ensure that an interface does
not have addresses on it when the IF is bound to a route table.  I get
the "why" behind that, but I'd like a small clarification:  Is that per-AF?
Or is that "across the board"?

The reason I ask is the potentially somewhat disconnected special case
API call intf_add_del_address which contains a flag "del_all".  And it
does as advertised -- it removes all IPv4 and IPv6 addresses in one shot.

But if the route table addition is per-AF, it might make sense to have
the two calls coordinated a bit better.  That is:

- Modify intf_add_del_address to del_all per AF, or all AFs
- Modify intf_sw_interface_set_table to accept and bind one or both AFs

It is all in an effort to avoid repeatedly removing and re-adding the
addresses that might be present in either or both AFs on an interface.

See where I am headed there?  Am I way off base?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Multiple vppctl Considered Harmful

[Jon Loeliger]

Folks,

While I appear to be able to run a single vppctl up against VPP,
if I then start a second one, to the same VPP process, VPP immediately
aborts.  It's pretty unfriendly.

EAL:   Invalid NUMA socket, default to 0
EAL:   Invalid NUMA socket, default to 0
DPDK physical memory layout:
Segment 0: phys:0x3520, len:2097152, virt:0x7ff40d00,
socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0
Segment 1: phys:0x35c0, len:8388608, virt:0x7ff40c60,
socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0
Segment 2: phys:0x36c0, len:2097152, virt:0x7ff40c20,
socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0
Segment 3: phys:0x6d80, len:224395264, virt:0x7ff3fea0,
socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0
Segment 4: phys:0x3f940, len:2097152, virt:0x7ff3fe60,
socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0
Segment 5: phys:0x3f980, len:29360128, virt:0x7ff38c80,
socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0
Aborted



vpp# show version
vpp v17.10-rc0~307-g6b3a8ef built by jdl on bcc-1.netgate.com at Mon
Sep 11 18:38:26 CDT 2017



Does anyone else see that?  Or am I special?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Mac Address Api Changes

[Jon Loeliger]

On Tue, Oct 10, 2017 at 2:41 PM, John Lo (loj)  wrote:

> The two APIs affected are the older ones in L2FIB which use “u64 mac”
> instead of “u8 mac[6]” to pass MAC addresses:
>
> ·L2fib_add_del
>
> ·L2_fib_table_details
>
>
>
> I believe it is a good change to reduce confusion wrt how 6-byte MAC is
> stored in u64 with big/little endian hosts. The change would also require
> updates to user programs of these APIs, which we believe should be minimal.
>
>
>
> If we don’t get strong objections within a week, we will assume the change
> is acceptable and allow this API change in the master branch. It won’t
> affect 17.10 release.
>
>
>
> Regards,
>
> John
>

Sure.  +1

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Static Route Data API Data Structures

[Jon Loeliger]

On Tue, Aug 29, 2017 at 4:21 AM, Neale Ranns (nranns)  wrote:
> Hi Jon,
>

Neale,

> By ‘IP’ in this context we mean IPv4 and IPv6 and unicast and multicast
> (known as sub-address families or SAFIs). To provide this separation we
> therefore need 4 ‘tables’ per-VRF, one for each SAFI.

You say 4 here, but really we implement 2, one for IPv4 and one for IPv6.
So, an interface can be bound to multiple tables.  But is it limited to
one IPv4 and one IPv6 table?

> A ‘table’ in this context is the well known longest-prefix matching DB.
> Tables are known by a unique per-AFI ID (note per-AFI not per-SAFI,
> so IPv4 unicast and multicast share the same table-id).

A table doesn't know its Address Family, except by the inspection of
the types of routes within it, right? (But both uni- and multi-cast routes
are possible in just one table, right?)
Any checking done to prevent inter-family mixing in one table?
Or is that up to convention and enforcement by the API user?


> It is the client’s responsibility to associate unique table IDs to tables
> within all of its VRFs.

Ah, there.  Only the external client (management agent) maintains
any notion of actual Virtual Routers.  To that end, multiple routing
tables are supplied for client use as it sees fit.

> The client is free to choose the table-ID from the full u32 range.
> So, bottom line, in the context of IP forwarding[,] a table (and its
> associated ID) refer to an instance of a LPM DB.

Right.  But prefix management is left up to something else (routing protocol).

> Despite code comments and variable naming, VPP does not maintain
> the concept of a VRF, i.e. it does not maintain a grouping of ‘tables’.

This is an important observation.

> At the client interface VPP deals only with table IDs – i.e. an identifier 
> that
> the client provided for a given LPM DB. All APIs that claim to accept a
> VRF index should be renamed to accept an IP table ID.

Would you (collectively) be receptive of patches to that end?

And is "table id" the name?  Not anything more descriptive,
such as "Route Table Id"?

> As with all things VPP the allocation of the data-structure that represents
> the LPM-DB comes from a memory pool. This data-structure thus has an
> associated pool index – this is the FIB index. So, there is a one to one
> mapping between the externally visible and client assigned ‘table ID’ and
> the internal use only ‘FIB index’. Both are a u32, neither are strictly typed…

Ah, I see.  Mapping in one direction is pool index, and a hash table
in the other direction?

As some APIs appear to want the FIB index, is there an API to do
the FIB Id lookup for a Table Id?  (I'd posit that either needs to be one,
or the APIs that accept a FIB Id need to be converted to Table Id.)
Or, are all those references to a FIB Id really *also* supposed to
be a Table Id?

(I'm not seeing this line up with the API call ip_fib_dump yet.  Does it?
If it does, and I see that it has route details in the fib_path, the table id
is lost.  So no client-side FIB-to-TableId mapping can be established.)

> With regards to the creation of tables, I’m currently working on the API
> you discovered – ip_table_add_del. With this API the client instructs VPP
> to add/delete a ‘table ID’ (as discussed above).

OK, good.

> The VPP FIB has the concept of ownership or ‘sourcing’ of its resources.
> Sources can be external (i.e. the CLI or the API) or internal (e.g. LISP
> and DHCP).

Ah, "source" was confusing here.  We mean "origin" and not "route source".
How the FIB came to exist.

> FIB resources are only completely free’d was there are no more sources
> that are referencing it.

And that is internally managed, right?

> My intention with the table add/delete API is that the client can add the
> table then insert routes and bind interfaces.

Specifically in that order?  Does the table have to be fully route-populated
at the time it is IF-bound?  Or will a later route addition/deletion be
factored into that IF's forwarding properly?

> If the client then deletes the table its routes will be purged. The table will
> then be deleted iff it held the last reference.

Full table.  Good.  Individual route additions/removals to that table OK too?
Table continues to exist if last route is deleted or there were no routes
in the table from the onset, right?

> With the introduction of this API VPP will insist that it has been called
> to create the table before any routes or interfaces refer to it.

Seems like a correct behavior.

> The current behaviour is that tables can be created either by setting an
> interface into that table, or by setting the ‘create_vrf_if_needed’ flag in
> a route add. There is no means to delete it, hence my new API work.

I see.  OK, I'll help push to get your patches accepted. :-)

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Adding IP Addr to Multiple IFs

[Jon Loeliger]

Packet Handlers,

I have a question regarding adding IP address on multiple interfaces.
I know.  Seems like it should be obvious and easy.  But I am not really
a Domain Expert here.  So questions about both expected behavior
and a possible bug.  We'll see.

Let's start with this sequence of vppctl commands:

vpp# show int
  Name   Idx   State  Counter
 Count
TenGigabitEthernet6/0/0   1down
TenGigabitEthernet6/0/1   2down
TenGigabitEthernet6/0/2   3down
TenGigabitEthernet6/0/3   4down
local00down
vpp# set interface ip address TenGigabitEthernet6/0/0 1.2.3.4/32
vpp# set interface ip address TenGigabitEthernet6/0/0 1.2.3.4/32
set interface ip address: failed to add 1.2.3.4/32 which conflicts with
1.2.3.4/32 for interface TenGigabitEthernet6/0/0


So VPP has recognized an overlapping request and complains.  Good.
But not that it is an exact overlap and could have let it slide.  Ah well.

vpp# set interface ip address TenGigabitEthernet6/0/1 1.2.3.4/32
vpp#


Hrm.  No complaint here.  Turns out the address is already associated
with FIB/table_id 0.  OK.

But also, no IP address added to the second IF either:

vpp# show int address
TenGigabitEthernet6/0/0 (dn):
  1.2.3.4/32
TenGigabitEthernet6/0/1 (dn):
TenGigabitEthernet6/0/2 (dn):
TenGigabitEthernet6/0/3 (dn):
local0 (dn):


Which means it was silently accepted, but didn't do what was asked of it.
To be very clear, that means that at the layer above the API call here,
there is no way to determine if that API call was successful or not.  In
fact,
that API call always returns "0 == ALL OK" in these cases.  So any layer
above the API that relied on that return value to store configuration
requests
in a side DB just got lied to and won't do the Right Thing here.

So, digging.

I think the first layer problem is in function
vl_api_sw_interface_add_del_address_t_handler():

static void vl_api_sw_interface_add_del_address_t_handler
  (vl_api_sw_interface_add_del_address_t * mp)
{
  vlib_main_t *vm = vlib_get_main ();
  vl_api_sw_interface_add_del_address_reply_t *rmp;
  int rv = 0;
  u32 is_del;
  VALIDATE_SW_IF_INDEX (mp);
  is_del = mp->is_add == 0;
  if (mp->del_all)
ip_del_all_interface_addresses (vm, ntohl (mp->sw_if_index));
  else if (mp->is_ipv6)
ip6_add_del_interface_address (vm, ntohl (mp->sw_if_index),
   (void *) mp->address,
   mp->address_length, is_del);
  else
ip4_add_del_interface_address (vm, ntohl (mp->sw_if_index),
   (void *) mp->address,
   mp->address_length, is_del);
  BAD_SW_IF_INDEX_LABEL;
  REPLY_MACRO (VL_API_SW_INTERFACE_ADD_DEL_ADDRESS_REPLY);


}

Notice that the REPLY_MACRO() always picks of a return value as rv = 0.
So we can add "error = ..." to the add and delete arms, and slam it to 0 in
the
"delete all" arm, and check for a non-null error to return rv = -1 instead.
Adding all that doesn't fix it.  (Note that over in ip46_cli.c this is
essentially
the approach taken there.)

Landing in ip4_add_del_interface_address_internal(), the FIB on the
sw_if_index
is located and the additional IP addr is checked for conflicts with
existing entries
in the foreach_ip_interface_address() macro loop.  That's all fine.

It then passes the buck to  ip_interface_address_add_del() along with the
FIB.
The outline of that routine sort of goes like this:


addr = lookup IP addr in FIB table

check something

if (del)
delete ip addr
set invalid addr index return parameter
else if (addr failed to lookup above)
add ip addr
set new addr index return parameter
else
silently say we have ip addr already
set addr index from lookup in return parameter

return success


That last "return success" basically means everything will always
be happy all the way back to an initial API call essentially every time.

So.  In the case of adding the same IP address to a second IF, that
just happens to have the same (default) FIB on it, I think control flow
ends up in the "else" clause above.  And that always works.
Instead, is there a way to check if the addr is being added to an IF
whose sw_if_index is the same-as or different-from the sw_if_index
of the original addr in the FIB entry?  Could we return "all happy"
if they match, and return some error in the case of non-matching?
Does that make any sense and make sense to do, if it is even possible?
Or am I out in the weeds again?

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Adding IP Addr to Multiple IFs

[Jon Loeliger]

On Fri, Sep 29, 2017 at 3:33 PM, Neale Ranns (nranns) 
wrote:

> Hi Jon,
>
>
>
> We don’t support overlapping subnets on interfaces. I was trying to fix
> the cases where it is errorneously allowed with this patch:
>
>   https://gerrit.fd.io/r/#/c/8057/
>
> but I’ve not yet found all the CSIT failures yet.
>
>
>
> /neale
>
>
>
Neale,

I have submitted a proposed patch for some of the issues here:

https://gerrit.fd.io/r/#/c/8619/

The important part of this patch is simply propagating the lower
level error message up to the API level where it can be used by
the API client.

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP S-NAT rename

[Jon Loeliger]

On Mon, Aug 21, 2017 at 2:39 AM, Ole Troan  wrote:
> Hi,
>
> The 'S' in VPP's S-NAT plugin name has often been confused with Linux' 
> "Source NAT". The 'S' originally stood for "Simple", implying that it was a 
> less complex implementation of NAT than the previous VCGN implementation.
>
> Because of this confusion (and possibly valid arguments that it isn't so 
> simple anymore) we'd like to rename it.
> The feature supports all flavours of NAT44 and NAT64.
>
> The suggested new name is simply NAT. I.e. "VPP NAT".
>
> The proposal is to change the name in the wiki, documentation, folder/files 
> and CLI.
> I am unsure if it is possible to change the API at this point. We might have 
> to put in the new message names and allow those to live in parallel with the 
> old ones for a release or two.

> Does anyone use the SNAT API?

Yes!

> Opinions?

Changing its name would be good.

I can track the name changes if you just want to slam them out there.

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Missing include file. Again.

[Jon Loeliger]

Folks,

I get the following compilation error with current (ie,

commit af3d9771dbf89087d3e8bed11aca0a2efa5d7bc8
Author: Marek Gradzki 
Date:   Fri Aug 18 08:47:48 2017 +0200

 ) top-of-tree builds:


CC tap_inject.c
In file included from /usr/include/vpp/api/vpe_all_api_h.h:25:0,
 from /usr/include/vpp/api/vpe_msg_enum.h:24,
 from api_setup.c:11:
/usr/include/vnet/vnet_all_api_h.h:61:30: fatal error:
vnet/tcp/tcp.api.h: No such file or directory
 #include 

The install only supplies these /usr/include/vnet/tcp files:

$ ll /usr/include/vnet/tcp
total 68K
 0K drwxr-xr-x  2 bin bin73 Aug 23 11:19 .
 4K drwxr-xr-x 46 bin bin  4096 Aug 23 11:19 ..
24K -rw-r--r--  1 bin bin 23207 Aug 23 11:16 tcp_debug.h
28K -rw-r--r--  1 bin bin 28574 Aug 23 11:16 tcp.h
 8K -rw-r--r--  1 bin bin  5961 Aug 23 11:16 tcp_packet.h
 4K -rw-r--r--  1 bin bin   922 Aug 23 11:16 tcp_timer.h

So, either the tcp.api.h should be installed, or it should not
be referenced.  Again, I don't know which will be the correct
and intended solution, so someone upstream from me will
need to fix this.

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Augment 'make test' with C build tests?

[Jon Loeliger]

> On Wed, Aug 23, 2017 at 2:25 PM, Dave Wallace  wrote:
>

> IMO, "in-tree" .vs. "out-of-tree" really boils down to decoupling the app's
> "Makefile.am" the rest of the vpp autotools structure/configuration.  For
> example, I ran into the same issue with
> .../vppsb/vcl-ldpreload/src/Makefile.am (which is literally 'out-of-tree')
> in the case where "VPP_DIR" is specified.  However, the vcl-ldpreload build
> would work the same if it was moved somewhere under vpp without integrating
> it into .../vpp/src/Makefile.am -- thus it would equally be "out-of-tree"
> even though it was stored in the vpp repo.

For lack of exposure to much of that, I'm sure some of the subtlety
of that is lost on me still.

> There are some other test apps in .../vpp/src/uri, which could be migrated
> there as well if we want to consolidate all apps under one directory.
> Personally I think this makes sense.

All the 'test apps' under one directory makes loads of sense.

> Currently these are "noinst_PROGRAMS" in .../vpp/src/uri.am.  To build them
> for testing, "s/noinst_PROGRAMS/bin_PROGRAMS/g" in uri.am, then rebuild --
> which does build them 'in-tree' (i.e. using the vpp autotools
> structure/configuration) --> the resulting binary executable files land in
> .../vpp/build-root/install-vpp*-native/vpp/bin.

Hrm.  We don't want to pollute the install with non-real binaries and
random test apps.  (Is that what you said would happen here?)

> In any case, I think that it is entirely possible to implement your proposal
> in such a way as to ensure that we can close the test escape that was the
> impetus for your proposal.

That would be fabulous.  This is the third or fourth time I've been
caught by it.

> My recommendation is to consolidate test
> applications in the same location in the process, in which case I think
> .../vpp/extras/apps is a better location than either .../vpp/make/test/c or
> .../vpp/src/apps

I'm happy to have it anywhere that makes sense.
Extra happy if it ends up as part of a 'make test', 'make verify' or some
other pre-patch-acceptance criteria.

I sent in a patch, https://gerrit.fd.io/r/#/c/8189/ , that demos what would
be my intent with a 'make test-c-build'.  It isn't currently wired into the
'make test' effort, but it could be readily.

Feel free to nix this patch, of course, but I'm not really sure where
or how to get an equivalent test into the ..extras/apps approach yet.

> Thanks,
> -daw-

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Augment 'make test' with C build tests?

[Jon Loeliger]

>> Feel free to nix this patch, of course, but I'm not really sure where
>> or how to get an equivalent test into the ..extras/apps approach yet.
>
> Cool.  Give me a few days, and I'll revise this patch to consolidate the
> test apps and integrate the 'make test-c-build' validation into 'make
> verify'.
>
> -daw-

Awesome!

Thank you!

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Static Route Data API Data Structures

[Jon Loeliger]

VPP-ites,

I am delving into the world of static routes.  I am clearly missing
some basic information and would like some help understanding
how static routes work.

For starters, I'm a little unclear on what exactly these items are,
or what they represent or hold, and their relationship to each other:

- VRF index / VRF id
- Table id
- FIB index  / FIB id

The only place I can find that even defines "VRF" is on this wiki page:

https://wiki.fd.io/view/VPP/What_is_VPP%3F

(Yeah, the final %3F is needed.)

And even that is in passing:

Some of the functionality that a routing application can create includes:

   o Virtual Routing and Forwarding (VRF) tables (in the thousands)


How is a VRF created/deleted/managed?  I don't see an obvious API call
that looks like it would create/delete one:

$ git grep -i vrf | grep add_del
src/plugins/nat/nat64.c:nat64_add_del_pool_addr (ip4_address_t * addr,
u32 vrf_id, u8 is_add)
src/plugins/nat/nat64.c:nat64_add_del_prefix (ip6_address_t * prefix,
u8 plen, u32 vrf_id, u8 is_add)
src/plugins/nat/nat64.h:int nat64_add_del_pool_addr (ip4_address_t *
addr, u32 vrf_id, u8 is_add);
src/plugins/nat/nat64.h:int nat64_add_del_prefix (ip6_address_t *
prefix, u8 plen, u32 vrf_id,
src/plugins/nat/nat64_cli.c:  rv = nat64_add_del_pool_addr
(_addr, vrf_id, is_add);
src/plugins/nat/nat64_cli.c:  rv = nat64_add_del_prefix (, (u8)
plen, vrf_id, is_add);
src/plugins/nat/nat_api.c:  if ((rv = nat64_add_del_pool_addr
(_addr, vrf_id, mp->is_add)))
src/plugins/nat/nat_api.c:  s = format (0, "SCRIPT:
nat64_add_del_prefix %U/%u vrf_id %u %s\n",
src/vat/api_format.c:_(oam_add_del, "src  dst
 [vrf ] [del]")   \
src/vat/api_format.c:_(one_eid_table_add_del_map, "[del] vni  vrf
")   \
src/vat/api_format.c:_(lisp_eid_table_add_del_map, "[del] vni 
vrf ")  \
test/test_nat.py:
self.vapi.nat64_add_del_pool_addr_range(self.vrf1_nat_addr_n,
test/test_nat.py:
self.vapi.nat64_add_del_pool_addr_range(self.vrf1_nat_addr_n,
test/test_nat.py:self.vapi.nat64_add_del_prefix(vrf1_pref64_n,
test/vpp_papi_provider.py:def nat64_add_del_prefix(self, prefix,
plen, vrf_id=0, is_add=1):


Tables, on the other hand, can be created/deleted:

src/vnet/ip/ip.api:autoreply define ip_table_add_del
src/vnet/ip/ip_api.c:_(IP_TABLE_ADD_DEL, ip_table_add_del)
  \
src/vnet/ip/ip_api.c:vl_api_ip_table_add_del_t_handler
(vl_api_ip_table_add_del_t * mp)

Is this the right "table"?

What is the lifetime management of a table?  When is it OK to delete one?
Does it have to come into existence before any thing references the Table Id?
Or is it OK to have a dangling Table Id pointer for a while?
What happens if you use the API to delete it and there are lingering referrers?

But let's face it "table" is very generic.  What kind of table is
that?  And there
is no better name for it than "table"?   Wait.  Don't answer yet.
Let's check at
the API definition first:

/** \brief Add / del table request
   A table can be added multiple times, but need be
deleted only once.
@param client_index - opaque cookie to identify the sender
@param context - sender context, to match reply w/ request
@param is_ipv6 - V4 or V6 table
@param table_id - table ID associated with the route
 This table ID will apply to both the unicast
  and mlticast FIBs.
*/
autoreply define ip_table_add_del
{
  u32 client_index;
  u32 context;
  u32 table_id;
  u8 is_ipv6;
  u8 is_add;
};

But still, no clue what the table is, what it manages, what it holds,
what abstraction
it provides.  Nothing.

Is it really an arbitrary "Table" of anything you want?  Are these
used for several (?)
unrelated items and a generic "Table" is really appropriate?

It appears that a "table id" can sometimes be a FIB table id:

/** \brief IP FIB table response
@param table_id - IP fib table id


But clearly they are not the same:

src/vnet/dhcp/dhcp_proxy.h: * @brief The FIB index (not the
external Table-ID) in which the server
src/vnet/dhcp/dhcp_proxy.h: * @brief The FIB index (not the
external Table-ID) in which the client

OK.  Let's turn to some commands for help or insight.

NAT wants VRF ids:

VLIB_CLI_COMMAND (add_address_command, static) = {
  .path = "nat44 add address",
  .short_help = "nat44 add addresses  [- ] "
"[tenant-vrf ] [del]",

VLIB_CLI_COMMAND (add_static_mapping_command, static) = {
  .path = "nat44 add static mapping",
  .function = add_static_mapping_command_fn,
  .short_help =
"nat44 add static mapping local tcp|udp|icmp  []
external  [] [vrf ] [del]",
};

Ooo!  Look at that penultimate bit:  [vrf ]
So.  Is a "table id" the same thing as a "VRF id"?

I find no discussion or description of any of this in any of the wiki,
nor in the online docs.fd.io,
nor in 

[vpp-dev] Augment 'make test' with C build tests?

[Jon Loeliger]

Damjan and others,

Over the past 6 or 8 months, we have had several build failures
due to missing include files in the installation of built RPMs.

It is a really simple C test to identify the failure.  Here is an
almost minimal example:

#include 
#include 
#include 
#include 

#define vl_typedefs
#define vl_endianfun
#include 
#undef vl_typedefs
#undef vl_endianfun

int main(int argc, char *argv[])
{
printf("Hello, VPP World!\n");
return 0;
}

If this compiles, all of the VNET include files are present.
If one of the VNET include files (like )
is missing, it will not compile.

Other includes would be needed for the other plugins too.

There is currently no structure in place under vpp/test
using "make test" that is able to do this sort of compile
test of C code yet.

What about adding a vpp/test/c directory and a Makefile
to drive the build and execution of a couple simple test
cases like the above sample?

The trick here would be ensuring the use of the just-built
components, and not the pieces (possibly) already installed
on the host system.  That is, most of this stuff from vpp/Makefile
would have to be propagated for use as well:

make -C test \
  TEST_DIR=$(WS_ROOT)/test \
  VPP_TEST_BUILD_DIR=$(BR)/build-$(2)-native \
  VPP_TEST_BIN=$(BR)/install-$(2)-native/vpp/bin/vpp \
  VPP_TEST_PLUGIN_PATH=$(call libexpand,$(libs),$(2),vpp_plugins) \
  VPP_TEST_INSTALL_PATH=$(BR)/install-$(2)-native/ \
  LD_LIBRARY_PATH=$(call libexpand,$(libs),$(2),) \
  EXTENDED_TESTS=$(EXTENDED_TESTS) \
  PYTHON=$(PYTHON) \
  $(3)

Thoughts?

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP S-NAT rename

[Jon Loeliger]

On Wed, Aug 23, 2017 at 2:56 PM, Ole Troan  wrote:

> They are now both there in parallel. With a warning in the wiki that the old 
> one will be removed after 17.10.
> https://wiki.fd.io/view/VPP/NAT#API_.28new_after_renaming.29
>
> Does that work for you?

Yep!

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Augment 'make test' with C build tests?

[Jon Loeliger]

On Wed, Aug 23, 2017 at 2:25 PM, Dave Wallace  wrote:
> Jon,
>
> I think this is an excellent idea as your example is clearly a test escape
> that we should be detecting in our CI infra.
>
> However, I'm not sure if "make test" is the appropriate place to add this
> check.  IMHO, this would be better suited to be invoked under "make verify"
> (like the clang test coverage).  I recommend that code itself live in
> .../vpp/src/apps

This is the problem.  All the existing code is "in tree".  That always works.

I want something that is building based on out-of-tree (ie, RPM install
directory), like the 'make test' provides.

> There are some other test apps in .../vpp/src/uri, which could be migrated
> there as well if we want to consolidate all apps under one directory.
> Personally I think this makes sense.

Are these already being built from 'install' staging directories?

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Missing include file. Again.

[Jon Loeliger]

On Wed, Aug 23, 2017 at 1:30 PM, Florin Coras  wrote:
> Hi Jon,
>
> There was a pending patch for that but apparently it got abandoned. Here’s a
> fix [1] that we’ll merge as soon as it passes verify.
>
> Sorry for the inconvenience.
>
> Regards,
> Florin
>
> [1] https://gerrit.fd.io/r/#/c/8188/

Awesome!

Thank you,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Discussion Topic: creating demo branches in git.fd.io/vpp

[Jon Loeliger]

On Wed, Nov 15, 2017 at 4:17 PM, Dave Wallace  wrote:

> Folks,
>
> Per the action item from this yesterday's VPP weekly meeting, I'm asking
> for opinions from the VPP community on allowing the creation of demo
> branches in the VPP git repo.
>
> ...
>
> Pro: Will allow utilization of LF infra to utilize CI process
> Pro: Will allow publishing of demo artifacts for ease of reproduction of
> the demo.
> Con: Will pollute repo with ephemeral code that will rapidly become out of
> date / dead.
> Con: Sets precedent which may cause large numbers of non-production
> branches over time.
>
> Please feel add additional Pro/Con comments here.  Comments are welcome
> from all members of the VPP community.
>

Dave,

In my opinion, creating a cloned fork and adding demo code there would be a
better approach.  And that demo code will likely become obsolete and
bit-rot over time,
but it will forever be part of the repo.  Over time it will just be dead
weight bloat.
The core code base should remain as a library and not get tied to any
specific application.

HTH,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] ACL Build/Test Issues

[Jon Loeliger]

Folks,

Every error from the ACL implementation is -1.  Generically bad.
Without regard for what might be more useful to an upper-layer UI.

So I submitted a patch to help this situation some.
https://gerrit.fd.io/r/#/c/9383/

I have built and tested it locally, but it fails the Verify Tests because
it has a test that is expecting a hard-coded -1 return from some tests.
Returning a -6 wasn't good enough.

First, this is draconian for no really good reason.  Second, it should be
fixed.  Third, I would do that except I am stupid and need a clue where
or how to fix this situation so the tests are less draconian.  (Can we
get a "less than 0" test instead of "equal to -1"?)

Oh, and, it's pretty clear why the Verify failed, despite the Jenkins job
saying it was unable to determine a cause.  Um, double blerg.

Any help for the weary here?

Thanks,
jdl


*21:21:43* ERROR: ACL create/delete test*21:21:43*
--*21:21:43*
Traceback (most recent call last):*21:21:43*   File
"/w/workspace/vpp-verify-master-ubuntu1604/test/test_acl_plugin.py",
line 563, in test_0001_acl_create*21:21:43* tag=":",
expected_retval=-1)*21:21:43*   File
"/w/workspace/vpp-verify-master-ubuntu1604/test/vpp_papi_provider.py",
line 2483, in acl_add_replace*21:21:43*
expected_retval=expected_retval)*21:21:43*   File
"/w/workspace/vpp-verify-master-ubuntu1604/test/vpp_papi_provider.py",
line 167, in api*21:21:43* raise
UnexpectedApiReturnValueError(msg)*21:21:43*
UnexpectedApiReturnValueError: API call failed, expected -1 return
value instead of -6 in acl_add_replace_reply(_0=936, context=33,
acl_index=432, retval=-6)*21:21:43*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] ACL Build/Test Issues

[Jon Loeliger]

On Fri, Nov 10, 2017 at 5:54 PM, Andrew Yourtchenko <ayour...@gmail.com>
wrote:

> Hi Jon,
>
> On 10 Nov 2017, at 23:11, Jon Loeliger <j...@netgate.com> wrote:
>
> Folks,
>
> Every error from the ACL implementation is -1.  Generically bad.
> Without regard for what might be more useful to an upper-layer UI.
>
>
> When we discussed with the openstack folks the way they are treating
> errors was all as catastrophic, but yes more distinction would be better,
> so thanks a lot for taking care of it!
>

Happy to try to help. :-)

So I submitted a patch to help this situation some.
> https://gerrit.fd.io/r/#/c/9383/
>
> I have built and tested it locally, but it fails the Verify Tests because
> it has a test that is expecting a hard-coded -1 return from some tests.
> Returning a -6 wasn't good enough.
>
> First, this is draconian for no really good reason.  Second, it should be
> fixed.  Third, I would do that except I am stupid and need a clue where
> or how to fix this situation so the tests are less draconian.  (Can we
> get a "less than 0" test instead of "equal to -1"?)
>
>
> Yeah. So we would need to first submit new test(s) that pass on both
> current and new code and then the new code itself... wanna take a shot at
> it  or should I ?
>

I don't even know where I would begin on that front, except
to say the test should maybe be " actual < 0" for now.

> Oh, and, it's pretty clear why the Verify failed, despite the Jenkins job
> saying it was unable to determine a cause.  Um, double blerg.
>
>
> Alas, this one I leave to someone else to comment on :)
>

I hear that!

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Deprecate [S]NAT APIs

[Jon Loeliger]

On Mon, Nov 20, 2017 at 9:59 AM, Neale Ranns (nranns) 
wrote:

>
> From src/plugins/nat/nat.api
>
> /*
>  * Old "snat" APIs, will be deprecated after 17.10
>  */
>
> is it time?
>
> /neale
>

As far as I am concerned, they can go now!

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] ACL API Change

[Jon Loeliger]

Folks,

So, yeah, I was just blind-sided by an API change in the ACL code.
Not to name names, or anything by it was

commit 36ea2d6d3a67a60534a7c2b58551688858a1ce7f

One armed NAT (VPP-1035)

Use a single physical interface in order to accomplish NAT44/NAT64.

That patch also introduced many manipulations of the field "is_inside".
While it continues to use a field named "is_inside", it has now effectively
become a 4-state flag field:

$ git grep NAT_INTERFACE_FLAG_IS_
src/plugins/nat/nat.c:  i->flags &=
~NAT_INTERFACE_FLAG_IS_INSIDE;
src/plugins/nat/nat.c:  i->flags &=
~NAT_INTERFACE_FLAG_IS_OUTSIDE;
src/plugins/nat/nat.c:i->flags |= NAT_INTERFACE_FLAG_IS_INSIDE;
src/plugins/nat/nat.c:i->flags |= NAT_INTERFACE_FLAG_IS_OUTSIDE;
src/plugins/nat/nat.c:i->flags |= NAT_INTERFACE_FLAG_IS_INSIDE;
src/plugins/nat/nat.c:i->flags |= NAT_INTERFACE_FLAG_IS_OUTSIDE;
src/plugins/nat/nat.h:#define NAT_INTERFACE_FLAG_IS_INSIDE 1
src/plugins/nat/nat.h:#define NAT_INTERFACE_FLAG_IS_OUTSIDE 2
src/plugins/nat/nat.h:#define nat_interface_is_inside(i) i->flags &
NAT_INTERFACE_FLAG_IS_INSIDE
src/plugins/nat/nat.h:#define nat_interface_is_outside(i) i->flags &
NAT_INTERFACE_FLAG_IS_OUTSIDE
src/plugins/nat/nat64.c:interface->flags |=
NAT_INTERFACE_FLAG_IS_INSIDE;
src/plugins/nat/nat64.c:interface->flags |=
NAT_INTERFACE_FLAG_IS_OUTSIDE;
src/plugins/nat/nat64.c:  is_inside ? ~NAT_INTERFACE_FLAG_IS_INSIDE
:
src/plugins/nat/nat64.c:  ~NAT_INTERFACE_FLAG_IS_OUTSIDE;

Which is all pretty much fine...  Except that it continues to use a
field named "is_inside", and when passed _back_ to the Client in a
DUMP/DETAIL,
message, it is a tri-state value:
is_inside == 0 <==> "outside"
is_inside == 1 <==> "inside"
is_inside == 2 <==> "both"

Which is where the unannounced, yet visible API change took place.

Here's the whole API file change here:

diff --git a/src/plugins/nat/nat.api b/src/plugins/nat/nat.api
index 8418757..fe40821 100644
--- a/src/plugins/nat/nat.api
+++ b/src/plugins/nat/nat.api
@@ -827,7 +827,7 @@ define nat44_interface_dump {

 /** \brief NAT44 interface details response
 @param context - sender context, to match reply w/ request
-@param is_inside - 1 if inside, 0 if outside
+@param is_inside - 1 if inside, 0 if outside, 2 if inside and outside
 @param sw_if_index - software index of the interface
 */

Call me a old grumpy whiner, but can we please post something to
the list about these sorts of changes?

And can we please rename that field away from "is_inside" to something
more descriptive and *less* misleading now?

I understand that this quad-state is really a combination of "on a list or
not"
and "one of three states if it is on a list", but it really would be much
clearer
if the flags field was used as a real 4-state (2-bit) flag field and the
INSIDE and OUTSIDE bits were clearly declared as such using 0x1 and 0x2
and 0x3 was used at the API to indicate both IN and OUT.

Blah.

jdl

PS -- Yes, I can write that patch if it would be accepted...
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] ACL Build/Test Issues

[Jon Loeliger]

Chris,

On Fri, Nov 10, 2017 at 8:27 PM, Luke, Chris  wrote:

> If you’re wondering where the tests are:
>
>
>
> $ ls test/*acl*
>
> test/test_acl_plugin_conns.py  test/test_acl_plugin_macip.py
>
> test/test_acl_plugin_l2l3.py   test/test_acl_plugin.py
>

Ah, excellent!


> Chris.
>

Thanks!

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Missing udp.api.h header file?

[Jon Loeliger]

On Thu, Nov 9, 2017 at 4:29 PM, Florin Coras  wrote:

> Hi Jon,
>
> This dates back to a couple of days ago.
>

Hey, I don't pull *every* day... :-)


> Fix is on the way …
>
> Florin
>

Thank you!

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Neighbor DUMP Takes Forever

[Jon Loeliger]

Hi Folks,

OK, maybe the Neighbor DUMP doesn't literally take forever.
But it sure does take too long!  Here is the problem:

When one goes to DUMP the Neighbor tables, one has no idea which interface
might have ARP/NDP entries on them.  So one determines the total number of
interfaces, and then one iterates over them one at a time asking for an
IP_NEIGHBOR_DUMP of each sw_if_index and AF combination.

That's all fine.  The problem is that the DUMP response DETAILS never come
for
interfaces that have NO entries.  So the message handling times-out
instead.  With
a one-second timeout on each (interface, AF) pair, it takes 2 seconds per
IF.

It makes for a very slow process to determine the ARP/Neighbor tables.

This used to be a problem in the NAT DUMP as well, but that was fixed.  I
don't
recall how off-hand, but at least one solution would be to always reply,
and if a
bogus entry is needed, do that.  Use a detail with a sw_if_index = ~0 if
necessary.
(Yeah, the ip_neighbor_t detail should be returning the sw_if_index too
anyway.)

Maybe something like that?

Oh, the reason that you never see this problem with vppctl is that it
doesn't
use the API. It goes straight to internal data structures instead.

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Neighbor DUMP Takes Forever

[Jon Loeliger]

On Wed, Nov 8, 2017 at 12:25 PM, Jon Loeliger <j...@netgate.com> wrote:

> Hi Folks,
>
> OK, maybe the Neighbor DUMP doesn't literally take forever.
> But it sure does take too long!  Here is the problem:
>

The problem appears to be PEBCAK.

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Neighbor DUMP Takes Forever

[Jon Loeliger]

On Wed, Nov 8, 2017 at 12:37 PM, Klement Sekera -X (ksekera - PANTHEON
TECHNOLOGIES at Cisco)  wrote:

> Hi Jon,
>
> the usual way to deal with possible-empty result sets is to wrap the
> call with a control-ping.
>
> 1.) send control-ping
> 2.) send e.g. sw_interface_dump
> 3.) start collecting sw_interface_details responses (if any)
> 4.) once control-ping reply is received, you know that there will be no
> more
> responses to the sw_interface_dump call.
>

Yep.  I get it.  I just botched it.  Sorry.


> HTH,
> Klement
>

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] And Boost Log too?

[Jon Loeliger]

On Wed, Nov 8, 2017 at 2:29 PM, Neale Ranns (nranns) 
wrote:

> Hi Jon,
>
>
>
> It doesn’t need it. I must have left that in by mistake. I’ll take it out.
>

Awesome.  Thanks!

jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] And Boost Log too?

[Jon Loeliger]

Folks,

Looks like VPP top-of-tree needs boost_log now.  And it isn't
in the install-deps.  And my "yum install boost-log" goes MIA.

Hints?

Thanks,
jdl



g++ -o /home/jdl/workspace/vpp/build-root/vom_test/vom_test -I
/home/jdl/workspace/vpp/src/vpp-api/ -std=c++11 -g -Wall -pthread
-I/home/jdl/workspace/vpp/src
-I/home/jdl/workspace/vpp/build-root/install-vpp-native//vpp/include
-I/home/jdl/workspace/vpp/build-root/vapi_test/ -DBOOST_LOG_DYN_LINK -O0 -g
vom_test.cpp
/home/jdl/workspace/vpp/build-root/build-vpp-native/vpp/vpp-api/vom/.libs/libvom.so
-lboost_log -lboost_thread -lboost_system -lboost_filesystem
-lboost_unit_test_framework
-L/home/jdl/workspace/vpp/build-root/build-vpp-native/vpp/.libs/
-L/home/jdl/workspace/vpp/build-root/build-vpp-native/vpp/vpp-api/vapi/.libs/
-lvppinfra -lvlibmemoryclient -lsvm -lpthread -lcheck -lrt -lm -lvapiclient
-lsubunit
/usr/bin/ld: cannot find -lboost_log
collect2: error: ld returned 1 exit status
make[2]: *** [/home/jdl/workspace/vpp/build-root/vom_test/vom_test] Error 1
make[2]: Leaving directory `/home/jdl/workspace/vpp/test/ext'
make[1]: *** [ext] Error 2
make[1]: Leaving directory `/home/jdl/workspace/vpp/test'
make: *** [test] Error 2


# make install-dep -n
sudo -E yum groupinstall  'Development Tools'
sudo -E yum install  redhat-lsb glibc-static java-1.8.0-openjdk-devel
yum-utils apr-devel numactl-devel check check-devel boost boost-devel
openssl-devel python-devel python-virtualenv chrpath libffi-devel rpm-build

$ sudo yum install boost-log
Loaded plugins: auto-update-debuginfo, fastestmirror
Loading mirror speeds from cached hostfile
 * base: repo1.dal.innoscale.net
 * epel: kdeforge2.unl.edu
 * epel-debuginfo: mirror.steadfast.net
 * extras: repo1.dal.innoscale.net
 * updates: repo1.dal.innoscale.net
No package boost-log available.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] i40e in a sorry state?

[Jon Loeliger]

Guys,

I've updated VPP to vpp.x86_64 0:18.01-rc0~405_g7f0d1d3 and when
I enable a interface, I get this love note:

i40e_dev_interrupt_handler(): ICR0: HMC error
Aborted

This used to work, of course.  Some more details below.

Any notions?

Thanks,
jdl


# cat /etc/vpp/startup.conf

unix {
nodaemon
log /tmp/vpp.log
full-coredump
cli-listen /run/vpp/cli.sock
gid vpp
}

dpdk {
uio-driver igb_uio
}

api-trace {
on
}

api-segment {
gid vpp
}



# /usr/bin/vpp -c /etc/vpp/startup.conf
vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins
load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists)
load_one_plugin:184: Loaded plugin: dpdk_plugin.so (Data Plane Development
Kit (DPDK))
load_one_plugin:184: Loaded plugin: flowprobe_plugin.so (Flow per Packet)
load_one_plugin:184: Loaded plugin: gtpu_plugin.so (GTPv1-U)
load_one_plugin:184: Loaded plugin: ila_plugin.so (Identifier-locator
addressing for IPv6)
load_one_plugin:184: Loaded plugin: ioam_plugin.so (Inbound OAM)
load_one_plugin:114: Plugin disabled (default): ixge_plugin.so
load_one_plugin:184: Loaded plugin: lb_plugin.so (Load Balancer)
load_one_plugin:184: Loaded plugin: libsixrd_plugin.so (IPv6 Rapid
Deployment on IPv4 Infrastructure (RFC5969))
load_one_plugin:184: Loaded plugin: memif_plugin.so (Packet Memory
Interface (experimetal))
load_one_plugin:184: Loaded plugin: nat_plugin.so (Network Address
Translation)
load_one_plugin:184: Loaded plugin: pppoe_plugin.so (PPPoE)
load_one_plugin:184: Loaded plugin: router.so (router)
load_one_plugin:184: Loaded plugin: stn_plugin.so (VPP Steals the NIC for
Container integration)
/usr/bin/vpp[4604]: tap_inject_interface_add_del:474:
tap_inject_interface_add_del: Adding interface with hw_if_index 0
/usr/bin/vpp[4604]: tap_inject_is_config_enabled:122:
tap_inject_is_config_enabled: Value of im->flags is 0
/usr/bin/vpp[4604]: tap_inject_interface_add_del:477:
tap_inject_interface_add_del: tap_inject is disabled in config
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/acl_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/dpdk_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/flowprobe_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/gtpu_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_export_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_pot_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_trace_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/ioam_vxlan_gpe_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/lb_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/memif_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/nat_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/pppoe_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/udp_ping_test_plugin.so
/usr/bin/vpp[4604]: load_one_plugin:63: Loaded plugin:
/usr/lib/vpp_api_test_plugins/vxlan_gpe_ioam_export_test_plugin.so
/usr/bin/vpp[4604]: tap_inject_is_config_enabled:122:
tap_inject_is_config_enabled: Value of im->flags is 0
/usr/bin/vpp[4604]: vlib_pci_bind_to_uio: Skipping PCI device :08:00.0
as host interface enp8s0f0 is up
/usr/bin/vpp[4604]: vlib_pci_bind_to_uio: Skipping PCI device :08:00.1
as host interface enp8s0f1 is up
/usr/bin/vpp[4604]: dpdk_bind_devices_to_uio:753: Unsupported PCI device
0x8086:0x0435 found at PCI address :09:00.0
/usr/bin/vpp[4604]: vlib_pci_bind_to_uio: Skipping PCI device :0a:00.0
as host interface enp10s0f0 is up
/usr/bin/vpp[4604]: dpdk_config:1216: EAL init args: -c 1 -n 4 --huge-dir
/run/vpp/hugepages --file-prefix vpp -b :08:00.0 -b :08:00.1 -b
:0a:00.0 --master-lcore 0 --socket-mem 64
EAL: No free hugepages reported in hugepages-1048576kB
EAL:   Invalid NUMA socket, default to 0
EAL:   Invalid NUMA socket, default to 0
EAL:   Invalid NUMA socket, default to 0
EAL:   Invalid NUMA socket, default to 0
DPDK physical memory layout:
Segment 0: IOVA:0x75c0, len:12582912, virt:0x7f124ec0, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 1: IOVA:0x76a0, len:2097152, virt:0x7f124e80, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 2: IOVA:0x43e40, len:2097152, virt:0x7f124e40, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 3: IOVA:0x43e80, len:33554432, virt:0x7f124c20,
socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0
Segment 

[vpp-dev] MACIP ACL replace causes ip4_table_index change?

[Jon Loeliger]

Hey VPP Fans,

I've detected a slight anomaly in the handling of MACIP ACLs, and
would like some help tracking down the right solution.

I start by making a MACIP ACL. vppctl shows:

vpp# show acl-plugin macip acl
MACIP acl_index: 0, count: 1 (true len 1) tag {bob} is free pool slot: 0
  ip4_table_index 3, ip6_table_index 3, l2_table_index 3
rule 0: ipv4 action 1 ip 0.0.0.0/0 mac 00:00:00:00:00:00 mask
00:00:00:00:00:00

I then attach that to an interface, and vppctl still shows:

vpp# show acl-plugin macip acl
MACIP acl_index: 0, count: 1 (true len 1) tag {bob} is free pool slot: 0
  ip4_table_index 3, ip6_table_index 3, l2_table_index 3
rule 0: ipv4 action 1 ip 0.0.0.0/0 mac 00:00:00:00:00:00 mask
00:00:00:00:00:00

Then, I change the MACIP rule from permit to deny using the
API call macip_acl_add_replace to adjust it in-place.  Now vppctl shows:

vpp# show acl-plugin macip acl
MACIP acl_index: 0, count: 1 (true len 1) tag {bob} is free pool slot: 0
  ip4_table_index 0, ip6_table_index 0, l2_table_index 0
rule 0: ipv4 action 0 ip 0.0.0.0/0 mac 00:00:00:00:00:00 mask
00:00:00:00:00:00

Notice that the ip4_table_index has changed from 3 in the first two 'show'
command outputs, while it is now 0 in the 3rd 'show' output.

My guess is it should be a consistent value throughout, and I think it
should
be table 3, but I'm not certain yet.

When I then go to remove the MACIP from the interface, I am told error -65,
which is "No such table."

So.

Should it have copied the ip4_table_index 3 to the replaced MACIP as it
stands
after the macip_add_replace API call?

Or should the original MACIP ACL have inherited the table number 0 from the
interface when it was first bound there?

Given that the complaint (upon deletion) is about table 0 being invalid (as
it should
because that table is "permanently present", right?), I suspect that it
should have
copied the 3 to the new (after replacement) MACIP.

I'll go digging some more, but thought I'd just throw this out there in case
anyone knows better or more than I.

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] MACIP ACL replace causes ip4_table_index change?

[Jon Loeliger]

On Fri, Dec 8, 2017 at 11:24 AM, Jon Loeliger <j...@netgate.com> wrote:

> On Fri, Dec 8, 2017 at 10:56 AM, Jon Loeliger <j...@netgate.com> wrote:
>
>>
>> vpp# show acl-plugin macip acl
>> MACIP acl_index: 0, count: 1 (true len 1) tag {bob} is free pool slot: 0
>>   ip4_table_index 0, ip6_table_index 0, l2_table_index 0
>> rule 0: ipv4 action 0 ip 0.0.0.0/0 mac 00:00:00:00:00:00 mask
>> 00:00:00:00:00:00
>>
>> Notice that the ip4_table_index has changed from 3 in the first two 'show'
>> command outputs, while it is now 0 in the 3rd 'show' output.
>>
>> My guess is it should be a consistent value throughout, and I think it
>> should
>> be table 3, but I'm not certain yet.
>>
>> When I then go to remove the MACIP from the interface, I am told error
>> -65,
>> which is "No such table."
>>
>> Should it have copied the ip4_table_index 3 to the replaced MACIP as it
>> stands
>> after the macip_add_replace API call?
>>
>> Or should the original MACIP ACL have inherited the table number 0 from
>> the
>> interface when it was first bound there?
>>
>
Sorry.  I also hate gmail.  But I could digress acerbically.

Anyway.

I meant to say that I've read enough to know now that these are classifier
table indices.  Which means the 3rd, unlisted option is more likely here:
As the ACL changed, update these table to use the _new_ classifier table
indices.  That should likely be table 4 unless the classifier can positively
determine that there are no other users of tables 3 and can do it in place,
in which case 3 is the correct answer.

But not 0.

Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev