[vpp-dev] Subif/VLAN Questions
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.
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] Packet Trace API?
Hey vpp-dev, Is there no API to enable packet tracing, and then get the trace buffer(s)? Is there any plan to do so? Or is this the whole point of the ioam code and I just don't see the connection yet? They seem different to me. Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Regarding C API
On Tue, Aug 15, 2017 at 7:45 PM, Burt Silverman wrote: > It appears that there are 2 typos not just one: try -lvatplugin. > > Burt I suck at this. Sorry, 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
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.
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
[vpp-dev] Augment 'make test' with C build tests?
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] Missing include file. Again.
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] Augment 'make test' with C build tests?
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] VPP S-NAT rename
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?
> 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?
>> 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
Re: [vpp-dev] VPP S-NAT rename
On Wed, Aug 23, 2017 at 2:56 PM, Ole Troan wrote:
> Does that work for you?
Ole,
So, I have renamed SNAT --> NAT/NAT44 as needed now.
That's all fine.
Got caught by this failure mode, though
I now have this code:
plugin_name = format(0, "nat_%08x%c", nat_api_version, 0);
base_msg_id = vl_client_get_first_plugin_msg_id((char *)plugin_name);
Which produced this failure:
vl_client_get_first_plugin_msg_id:500: plugin 'nat_72bb6883' not registered
But we renamed "snat" as "nat" for all the module names, etc., right?
Except this lingers in src/plugins/nat/nat_api.c:
snat_api_init (vlib_main_t * vm, snat_main_t * sm)
{
u8 *name;
clib_error_t *error = 0;
name = format (0, "snat_%08x%c", api_version, 0);
and correspondingly this in src/plugins/nat/nat_test.c:
name = format (0, "snat_%08x%c", api_version, 0);
Naturally, changing this is effectively the *real* commitment of the
rename effort, so it *could* be that this was a conscious choice to wait
until next release to do this particular name change.
I'm guessing there is no way to register both names ...
That's likely to be icky, right?
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
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
(&this_addr, vrf_id, is_add);
src/plugins/nat/nat64_cli.c: rv = nat64_add_del_prefix (&prefix, (u8)
plen, vrf_id, is_add);
src/plugins/nat/nat_api.c: if ((rv = nat64_add_del_pool_addr
(&this_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.
Re: [vpp-dev] Static Route Data API Data Structures
On Tue, Aug 29, 2017 at 4:21 AM, Neale Ranns (nranns) wrote: > Hi Jon, > > (apologies for repeating some of what you already know, but from the top…) > > A VRF is virtualisation of a router’s *IP* routing and forwarding. VRFs are > typically identified by a name (and again typically named to refer to the VPN > customer they represent). IP packets in VRF RED must be separate from IP > packets in VRF BLUE. 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. 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). It is the client’s responsibility to > associate unique table IDs to tables within all of its VRFs. 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. > > 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’. 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. > 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… > > 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). 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). FIB resources are only > completely free’d was there are no more sources that are referencing it. > My intention with the table add/delete API is that the client can add the > table then insert routes and bind interfaces. If the client then deletes the > table its routes will be purged. The table will then be deleted iff it held > the last reference. 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. > 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. > > Hth, > neale Neale, That helps tremendously! I am poised to add a bunch of route-related API calls to our project. Are the "new" IP Route APIs in place at this time? Or shall I wait a bit and watch for a bit still? Thank you! 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
On Tue, Aug 29, 2017 at 4:21 AM, Neale Ranns (nranns) wrote: > Hi Jon, > > (apologies for repeating some of what you already know, but from the top…) > > A VRF is virtualisation of a router’s *IP* routing and forwarding. Neale, Also, for the benefit of other Wiki Doc Searchers, I have captured your explanation here: https://wiki.fd.io/view/VPP/Per-feature_Notes 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
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
Re: [vpp-dev] Static Route Data API Data Structures
> A table doesn't know its Address Family, except by the inspection of
> the types of routes within it, right?
Ooo. My bad. Reading the ip_table_add_del API call, a Table
clearly knows what address family it holds:
autoreply define ip_table_add_del
{
u32 client_index;
u32 context;
u32 table_id;
u8 is_ipv6;
u8 is_add;
};
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
>> 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.)
Neale,
My double bad. I see (and understand!) this now:
/** \brief IP FIB table response
@param table_id - IP fib table id
@address_length - mask length
@address - ip4 prefix
@param count - the number of fib_paths in path
@param path - array of of fib_path structures
*/
manual_endian manual_print define ip_fib_details
{
u32 context;
u32 table_id;
u8 address_length;
u8 address[4];
u32 count;
vl_api_fib_path_t path[count];
};
That table_id *is* the dump coming back with the mapping from
FIB index to Table Id, right?
S, Will FIB index allocation always be dense? If it is
coming from a pool allocation, it should be, right? So FIB
indices are going to be reused after they are free'd up, right?
And this dump/details response will be in dense-index order, right?
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] VPP API Message Multi-Registration Question
Folks,
We have a need to re-register API message handlers.
(Think re-fork/exec scenarios for daemons.)
Today, we register handlers via a call to this function:
vl_msg_api_set_handlers (int id, char *name, void *handler, void *cleanup,
void *endian, void *print, int size, int traced)
When we do that today, we see this warning on the second call.
vl_msg_api_config (vl_msg_api_msg_config_t * c)
{
[...]
if (am->msg_names[c->id])
clib_warning ("BUG: multiple registrations of 'vl_api_%s_t_handler'",
c->name);
am->msg_names[c->id] = c->name;
am->msg_handlers[c->id] = c->handler;
am->msg_cleanup_handlers[c->id] = c->cleanup;
am->msg_endian_handlers[c->id] = c->endian;
am->msg_print_handlers[c->id] = c->print;
am->message_bounce[c->id] = c->message_bounce;
am->is_mp_safe[c->id] = c->is_mp_safe;
Sure, the handler is re-registered, but it is really annoying,
and it is misleading in our case. So we are looking for a
way to squelch it.
Is there a way to *un*-bind a handler during a "graceful shutdown"
procedure so that we can remove any binding here, and thus
later when we re-bind it is all happy again?
Or, can we call a (new?) API function that says "Yeah, we know,
but squash that message for me." just prior to registering the
handlers.
Or, is there a graceful shutdown of the API handling that
I have just missed or overlooked somewhere?
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
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] Static Route Data API Data Structures
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
Re: [vpp-dev] 回复： How to get interface stats using C api?
On Tue, Sep 26, 2017 at 9:47 PM, Keith Burns wrote: > Apologies, > > It's a callback. > > We probably need some decent literature written for how to consume the > various C, C++, Python and Lua APIs > > If you have a preference for any of those languages I could write a brief > client program for you and start work on documenting this stuff. Keith, I can't speak to the other API languages, but I have started some documentation about using the C API on the Wiki already. https://wiki.fd.io/view/VPP/How_To_Use_The_C_API It may not be what you are wanting, but it is a start. :-) In particular, there are some aspects of the message exchange that are missing. I only have Guilder and a wedding this weekend to blame for it. Sorry. 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
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
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] Mac Address Api Changes
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] 17.10 draft release notes
On Wed, Oct 25, 2017 at 7:28 AM, Ole Troan wrote:
> Hi Florin,
>
Hi Ole,
> What about something like this?
>
> #!/usr/bin/env python
> import os, fnmatch, subprocess
> starttag = 'v17.07'
> endtag = 'v17.10-rc2'
> apifiles = []
> for root, dirnames, filenames in os.walk('.'):
> for filename in fnmatch.filter(filenames, '*.api'):
> apifiles.append(os.path.join(root, filename))
> for f in apifiles:
> commits = subprocess.check_output(['git', 'log',
>'--oneline', starttag + '..' +
> endtag,
>f])
> if commits:
> print f
> print commits
>
Just as an FYI, Git might be able to help simplify some of
this script for you too. For example:
$ git ls-files *.api
src/examples/sample-plugin/sample/sample.api
src/plugins/acl/acl.api
src/plugins/dpdk/api/dpdk.api
src/plugins/flowprobe/flowprobe.api
src/plugins/gtpu/gtpu.api
Depending on development at HEAD, you may want:
$ git ls-files v17.10-rc2 *.api
or so.
Then, if you are not too concerned about the individual
break-down by file, you can one-line it:
$ git log --oneline v17.07..v17.10-rc2 -- *.api
50570ec Update of free text tag patch for BD
831fb59 Stats refactor
2297af0 Add a name to the creation of an IP and MPLS table
c29940c ACL-plugin add "replace" semantics for adding a new MacIP acl
8a19f12 Allow individual stats API and introduce stats.api -
want_interface_simple_stats - want_interface_combined_stats -
want_ip4|6_fib|nbr_stats
d630713 LISP: add neighbor discovery and CP protocol separation APIs
111a5ce LISP: Add APIs for enable/disable xTR/P-ITR/P-ETR modes
4802632 Punt socket: Fix coverity error for pathname length mismatch
between API and sun_path.
33e002b Fix session connect_* api message handling.
Also, the "shortlog" command is tailored to producing release notes:
$ git shortlog v17.07..v17.10-rc2 -- *.api
Dave Barach (1):
TCP source address automation
Dave Wallace (1):
Fix session connect_* api message handling.
Eyal Bari (3):
API:fix arp/ND event messages - remove context
SPAN:add l2 mirror
SPAN/API:enable L2 dump
Filip Tehlar (4):
LISP: make TTL for map register messages configurable
LISP: Map-server fallback feature
LISP: Add APIs for enable/disable xTR/P-ITR/P-ETR modes
LISP: add neighbor discovery and CP protocol separation APIs
HTH,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] Assumed "deny" at end of ACLs?
Hi VPP Gurus, Is there an assumed "deny all" at the end of an ACL rule list? Or some form of "route to dpo-drop"? Anything like that? Or is that something that use must explicitly encode into an ACL list? Is this stated somewhere in the Wiki and I just missed it? Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Assumed "deny" at end of ACLs?
On Mon, Oct 30, 2017 at 3:34 PM, Andrew Yourtchenko wrote: > Jon, > > Assuming it’s ACL plugin that you ask about, yes - if none of the ACLs in > the list of ACLs applied to interface in a given direction matches, it’s > the same as deny. > > --a Excellent! Thank you! jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Assumed "deny" at end of ACLs?
On Mon, Oct 30, 2017 at 3:38 PM, Jon Loeliger wrote: > On Mon, Oct 30, 2017 at 3:34 PM, Andrew Yourtchenko > wrote: > >> Jon, >> >> Assuming it’s ACL plugin that you ask about, yes - if none of the ACLs in >> the list of ACLs applied to interface in a given direction matches, it’s >> the same as deny. >> >> --a > > What about for the MACIP acls too? Is there an assumed "deny any" at the end of those rule sets too? Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] Neighbor DUMP Takes Forever
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
On Wed, Nov 8, 2017 at 12:25 PM, Jon Loeliger 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
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
[vpp-dev] And Boost Log too?
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
Re: [vpp-dev] And Boost Log too?
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] Missing udp.api.h header file?
Folks, Anyone recognize this one? CC my_af_packet.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 my_af_packet.c:14: /usr/include/vnet/vnet_all_api_h.h:64:30: fatal error: vnet/udp/udp.api.h: No such file or directory #include That is as of: Author: Florin Coras Date: Thu Nov 9 10:05:42 2017 -0800 session: fix app index in unbind Change-Id: Iff1a665b6cf9ca2def0fcdacf02d7f8c579c0f4e Signed-off-by: Florin Coras 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?
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] ACL Build/Test Issues
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
On Fri, Nov 10, 2017 at 5:54 PM, Andrew Yourtchenko wrote: > Hi Jon, > > On 10 Nov 2017, at 23:11, Jon Loeliger 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] ACL Build/Test Issues
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
[vpp-dev] ACL API Change
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] Discussion Topic: creating demo branches in git.fd.io/vpp
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
Re: [vpp-dev] Deprecate [S]NAT APIs
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] i40e in a sorry state?
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
Re: [vpp-dev] i40e in a sorry state?
On Wed, Dec 6, 2017 at 5:17 AM, Kinsella, Ray wrote: > > We may need the contents of PFHMC_ERRORINFO and PFHMC_ERRORDATA registers > to figure this out. > I suspect that this may be something to do with interrupts being enabled. > However from reading the code, looks like interrupts should be disabled by > default unless explictly enabled. > > Ray K > Ray, I backed off to 17.08, and still showed the problem. That indicated to me that something else was happening. I dug a little deeper and found an entirely different hole unrelated to VPP/DPDK that caused this issue for me. Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] MACIP ACL replace causes ip4_table_index change?
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?
On Fri, Dec 8, 2017 at 10:56 AM, Jon Loeliger 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."
>
> 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?
>
___
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?
On Fri, Dec 8, 2017 at 11:24 AM, Jon Loeliger wrote:
> On Fri, Dec 8, 2017 at 10:56 AM, Jon Loeliger 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
Re: [vpp-dev] MACIP ACL replace causes ip4_table_index change?
On Fri, Dec 8, 2017 at 12:34 PM, Andrew Yourtchenko
wrote:
> Jon,
>
> Do you have an api trace you could throw in my direction unicast ?
>
I'd have to work at that quite a bit as I am using a totally new and
different UI to drive these API calls... I can outline it for you:
macip_index = create macip acl with one rule "permit"
call interface bind (some sw_if_index, macip_index)
show the classifier tables
show the MACIP interface bindings
show the MACIP acls
call macip_acl_add_replace(macip_index, "change rule to deny")
show the new classifier tables (look ok)
show the MACIP interface bindings (look ok)
show the MACIP acls (look ok except the {ip4,ip6,l2}_table_index values
are 0; should be 3?)
> Macip_add_replace call was added later than most ACL plugins, (after
> realizing the convenience of this approach in the policy ACLs vs the
> unapply/delete acl/readd acl/reapply and for consistency), via commit
> c29940c58de3e44c0c1dd5c4eda5e0268d963b14
>
I know. In fact, I had a different bug reported against our UI due
to the old way of removing the rules and then not getting them
re-applied upon addition correctly.
So when I saw the new API call (add_replace), I jumped on it!
I think I've just re-discovered the same underlying problem just
two layers deeper into the MACIP implementation now. :-/
> That change modified the existing “macip_acl_add_list” routine to also get
> the replace semantics, by deleting and then recreating the classifier
> tables anew.
>
I've just read through the macip_create_classifier_tables(), so yeah...
> This doesn’t work very well if the classifier tables are applied
> somewhere: they are removed, but the new tables are not applied
> automatically.
>
Right. That's what I think I am seeing.
> We need to iterate the am->macip_acl_by_sw_if_index and for interfaces
> which have the acl in question applied, reapply these new tables to these
> interfaces so the already active macip acl remained active.
>
Ah, I see
> This is a bug. Sorry for that.
>
No worries. I've written a bug or two in my day...
> Since there were also tests in that commit which ideally should have
> caught this, i will also need to take a double check at what is going on
> there (my guess missing negative tests), and fix it too, but not sure I can
> pull off thumbtyping in a vi session,
>
I see your problem here. No one should have to use vi. :-)
> so I will add you to the changerequest with the fix once I have it, hope
> in a day or so.
>
Excellent!
Thank you!
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?
On Fri, Dec 8, 2017 at 12:55 PM, Jon Loeliger wrote:
>
>
>
>> We need to iterate the am->macip_acl_by_sw_if_index and for interfaces
>> which have the acl in question applied, reapply these new tables to these
>> interfaces so the already active macip acl remained active.
>>
>
> Ah, I see
>
I'm not convinced this is the issue. I added that loop, and it doesn't
change things. Specifically, a->ip4_table_index is 0, not 3 after the
creation of the classify tables.
So, here is sort of a trace through some key places of the
classify table construction. It follows the API sequence I
outlined in an earlier message (create MACIP with one permit rule,
then bind to interface, then modify that MACIP's rule to deny
and update it using macip_acl_add_replace).
I'll annotate this some.
Here is the initial creation of the classify tables:
macip_acl_add_list: looks like a create
macip_create_classify_tables: top a->count 1
macip_create_classify_tables: last_table before 4294967295
Now we create the rules in reverse order:
macip_create_classify_tables: ARP looop top
macip_create_classify_tables: ARP loop last_table 0
macip_create_classify_tables: IP[46] loop top
macip_create_classify_tables: IP[46] loop last_table 1
macip_create_classify_tables: IP[46] loop last_table 2
macip_create_classify_tables: IP[46] loop last_table 3
macip_create_classify_tables: ip4_t_i 3
macip_create_classify_tables: ip6_t_i 3
macip_create_classify_tables: l2_t_i 3
That leaves last_table at 3, the most recently created rule,
with a chain from 0 through 3:
vpp# show classify tables
TableIdx Sessions NextTbl NextNode
0 1 1-1
Heap: 3 objects, 204 of 2k used, 76 free, 0 reclaimed, 1k overhead, 8188k
capacity
nbuckets 32, skip 0 match 2 flag 0 offset 0
mask
linear-search buckets 0
1 1 2-1
Heap: 3 objects, 204 of 2k used, 76 free, 0 reclaimed, 1k overhead, 8188k
capacity
nbuckets 32, skip 0 match 2 flag 0 offset 0
mask
linear-search buckets 0
2 1 3-1
Heap: 3 objects, 236 of 2k used, 76 free, 0 reclaimed, 1k overhead, 8188k
capacity
nbuckets 32, skip 0 match 3 flag 0 offset 0
mask :
0020:
linear-search buckets 0
3 1-1 0
Heap: 3 objects, 204 of 2k used, 76 free, 0 reclaimed, 1k overhead, 8188k
capacity
nbuckets 32, skip 0 match 2 flag 0 offset 0
mask
Now I bind that MACIP to the interface, and get:
vpp# show acl-plugin macip interface
sw_if_index 0: -1
sw_if_index 1: 0
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
Now I update the MACIP rule, changing "permit" to "deny".
And I call macip_acl_add_replace():
macip_acl_add_list: replacing ACLs now, acl_list_index is 0
macip_acl_interface_add_acl: macip_acl_index 0
macip_acl_add_list: looks like a replace
macip_create_classify_tables: top a->count 1
macip_create_classify_tables: last_table before 4294967295
That's just like before. Good.
And now we count down the existing matching rules:
macip_create_classify_tables: ARP looop top
macip_create_classify_tables: ARP loop last_table 3
macip_create_classify_tables: IP[46] loop top
macip_create_classify_tables: IP[46] loop last_table 2
macip_create_classify_tables: IP[46] loop last_table 1
macip_create_classify_tables: IP[46] loop last_table 0
And leave last_table at 0.
Which we then store in the {ip4,ip6,l2}_table_index variables:
macip_create_classify_tables: ip4_t_i 0
macip_create_classify_tables: ip6_t_i 0
macip_create_classify_tables: l2_t_i 0
This is my loop added to the bottom of macip_acl_add_list():
for (i = 0; i < vec_len (am->macip_acl_by_sw_if_index); i++)
{
vlib_cli_output (vm, "%s: check swif %d\n", __func__, i);
if (am->macip_acl_by_sw_if_index[i] == *acl_list_index)
{
vlib_cli_output (vm, "%s: re-add acl_list_index %d\n", __func__,
*acl\
_list_index);
macip_acl_interface_add_acl (am, i, *acl_list_index);
}
}
macip_acl_add_list: replacing ACLs now, acl_list_index is 0
macip_acl_add_list: check swif 0
macip_acl_add_list: check swif 1
macip_acl_add_list: re-add acl_list_index 0
macip_acl_interface_add_acl: macip_acl_index 0
So the MACIP ACL is applied to the SW IF, I believe, but
the MACIP ACL itself appears to be pointing to the wrong
end of
Re: [vpp-dev] MACIP ACL replace causes ip4_table_index change?
On Sat, Dec 9, 2017 at 8:16 AM, Andrew 👽 Yourtchenko wrote: > Jon, > Hi Andrew, Thanks for taking a look at this issue! > on api trace: does the below work ? (even though the current scenario > is trivially reproducible, the api traces are very useful for tougher > cases, and save a lot of typing while storytelling). > > DBGvpp# api trace on > > . do the things > > DBGvpp# api trace save macip-trace > API trace saved to /tmp/macip-trace > DBGvpp# api trace custom-dump /tmp/macip-trace > SCRIPT: macip_acl_add_replace -1 count 1 count 1 \ > ipv4 permit \ > src mac 00:00:00:00:00:00 mask 00:00:00:00:00:00 \ > src ip 0.0.0.0/0, \ > > SCRIPT: macip_acl_interface_add_del sw_if_index 0 acl_index 0 add > SCRIPT: macip_acl_add_replace 0 count 1 count 1 \ > ipv4 permit \ > src mac 00:00:00:00:00:00 mask 00:00:00:00:00:00 \ > src ip 0.0.0.0/0, \ > I think that is the right sequence. Now, to the issue itself: it's exactly as I described, but with a twist: > vnet_set_input_acl_intfc(), which is used under the hood to assign the > inacl on the interfaces, is quite picky - if there is an existing > inacl applied, it just quietly does nothing. (@DaveB - this kinda > feels strange, I am not sure what the logic is behind doing that.) > > Anyway, rather than debating on why it behaves this way, and, > especially since we actually are deleting the tables in question, it's > better to unapply the inacls first, and then reapply them after the > tables have been recreated. > This solves half the problem for me. It looks like I can properly turn around and remove this ACL from the interface now! But I still have doubts; or at least I don't understand why the three table indices are 3 after initial creation, and 0 after they are replaced. The result is in https://gerrit.fd.io/r/#/c/9772/ - you can verify > that it addresses the issue. > I've left a comment on the code there. Despite what Gerrit thinks, this code does compile and run for me! So maybe just a "rebuild" request there will allow it to verify? > Now, going on to "how exactly did this slip through" - seems the macip > tests are quite a bit too lenient than they should be. I'll need to > address that as well, though probably I will split the dot1q/dot1ad > test cases out, and in the process refactor things a bit... so in the > interests of your time, maybe 9772 can go with just an actual code > fix. > I've not read through the test as they stand today. I'd like to understand the "3 vs. 0" issue before I am happy to Code Review +1 this patch. > I've dumped the entire debugging process into a log, which turned out > be fairly long, so to avoid sending the walls of text to the list, > I've dumped it elsewhere: > http://stdio.be/blog/2017-12-09-Debugging-VPP-MACIP-ACLs/ And, excellent! I read through that in quite some detail. And I understand the "3 vs 0" issue I was seeing now! The two pieces I missed were: The "show inacl type l2" to see where the chain was starting, and then noticing that the chain had indeed been reversed once the starting point was known. So thanks for that excellent debug layout and explanation. And thanks for including the intermediate step of showing why simply updating the interface at the end wasn't sufficient. I had done that, but hadn't yet gotten into the next function to see it was being ignored. Thanks again for catching this. Thanks for fixing this! > > --a So, with that, I've left a comment and a Review -1 on the patch. And the patch didn't Verify. So where do we go from here? I'm good with the patch, and we need to rebuild it. So do we just re-build the same patch or re-submit it as a new patch? I will either update or Review a-new to +1 it! Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] Failing verify jobs
Folks, So, I have a long-standing "DON'T MERGE"-ish patch that is a recurring rebase request to help identify failures of missing #include files in C API application biulds. It is: https://gerrit.fd.io/r/8189 It was recently rebased, and failed for an entirely different reason. That reason appears to be related to some VIRL server failure. Starting around 16:02:56 in the console log file https://jenkins.fd.io/job/vpp-csit-verify-virl-master/8806/console shows this: *16:02:56* ++ ssh -i priv_key -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o BatchMode=yes -o LogLevel=error jenkins-in@10.30.51.29 'start-testcase -vv --quota 65 --copy double-ring-nested.xenial --release csit-ubuntu-16.04.1_2017-10-21_2.0 /tmp/vpp_18.01-rc0~540-gda58107~b8806_amd64.deb' /tmp/vpp-api-java_18.01-rc0~540-gda58107~b8806_amd64.deb /tmp/vpp-api-lua_18.01-rc0~540-gda58107~b8806_amd64.deb /tmp/vpp-api-python_18.01-rc0~540-gda58107~b8806_amd64.deb /tmp/vpp-dbg_18.01-rc0~540-gda58107~b8806_amd64.deb /tmp/vpp-dev_18.01-rc0~540-gda58107~b8806_amd64.deb /tmp/vpp-dpdk-dkms_17.11-vpp1_amd64.deb /tmp/vpp-lib_18.01-rc0~540-gda58107~b8806_amd64.deb /tmp/vpp-plugins_18.01-rc0~540-gda58107~b8806_amd64.deb apparently yielded this error: *16:02:58* VIRL simulation start failed on 10.30.51.29 I have no clue other than "connection wasn't established" as to why that might be. In fact I have no idea what is going on here. :-) Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] Some memif API and Naming Questions
Hi VPPeople,
I am working on adding memif support to our system and need
to design some User Interface pieces for it. I am having a bit of
a hard time with one naming aspect of the memif components.
Each memif entry has a unique u32 id assigned to it.
Each memif entry requires a socket as part of its setup.
Each memif entry can be either a slave or a master role.
Each memif entry has a corresponding SW IF as well.
The SW IF name is created using the template "memif%d/%d"
where the first %d is the pool index of the socket's filename,
and the second %d is the unique id.
There is a default socket filename that is used when no socket
name is provided in a "memif_create" API call. I am able to
create either "master" or "slave" entries with unique ids, but not
both using the default socket. Changing the socket name
allows both master and slave entries to be created. Eventually,
some experimentation lead me to believe that there must be
an underlying problem with using the same socket for master
and for slave entries.
In fact, reading some of the code, I found src/plugins/memif/memif.c, line
585:
/* existing socket file can be either master or slave but cannot be
both */
OK.
So if both master and slave entries might be present in the system,
specifying the socket filename is required at some point.
In the User Interface that I have, I allow a user to declare that they want
to make a memif and state attributes about it. Specifically, I allow them
to make a role "slave" or "master", and set some queue sizes and lengths.
The User shouldn't ever care about some underlying socket file name here.
(It is purely an implementation detail they don't care about.)
Later, the User should be able to specify attributes about the corresponding
SW IF for the memif. However, there is no way for the user to know (predict
with certainty) the name of that SW interface. They can get close, but
there
is no way to know for sure. It will be something like "memif.../" where
the "" part is a unique number they provided in the memif declaration
and setup earlier. However, the User cannot predict the socket number.
And lest you say something like "but creating the memif instance returns
the sw_if_index, and you can use that to lookup the SW IF's name",
understand
that this is NOT necessarily an interactive system. We have to be able to
set up batch configuration without screen scraping the results. The user
has
to be able to reliably predict the corresponding SW IF name.
So let's ask some questions and posit some solutions.
I'm willing to grant that different sockets are needed for the master and
slave
roles. Are there ever more than two sockets needed for all of the memif
instances? Is it good enough to have one slave, and one master socket?
If so, then we can just use the role to map an instance to a socket and have
the corresponding SW IF name be, say, memif-slave/ or memif-master/.
Right now, as implemented, the "unique id" is not "for all memifs". It is
for
"each {master,slave" group, though. That is one can have "unique id 23"
as both master and slave. More accurately, the id need only be unique
within
a given socket pool index. (And we know there will be different sockets for
masters and for slaves.) So we could totally change this looser uniqueness
requirement (per socket) to "for all memif instances". With this approach,
we could use the unique id to, well, uniquely identify the SW IF using a
name
like "memif-". We'd have to keep a mapping to socket within the memif
entry (but that is already done!) We just wouldn't place the socket pool
index
in part of the SW IF name.
Another solution would be to pre-allocate memif sockets with named socket
entries that the User could control. For example, allow a user to
pre-allocate
a socket called "slave_sock" to file "/var/run/vpp/slave.sock". And then
within
the memif entry, use the _name_ of the socket, not the filename of the
socket.
Now the user knows that the SW IF would be named "memif-slave_sock/".
Other thoughts?
Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Some memif API and Naming Questions
On Sun, Jan 14, 2018 at 9:36 AM, Damjan Marion (damarion) < damar...@cisco.com> wrote: > Jon, > Hi Damjan, Thanks for answering my email! I think there are somethings I'm not quite understanding yet, so I have a few more questions and suggestions. > Each memif connection between master and slave is uniquely identified > by AF_UNIX socket and ID pair. This is first law of memif :) > I understand that. > On unix side AF_UNIX socket is identified by filename in the filesystem > but that is too long so in VPP each AF_UNIX socket have assigned file_id > and that index is used in > memif interface name. > I understand that. > So as you described, memif interface is formatted as follows: > > memif-/ > And I understand that. > You cannot have 2 VPP instances listening on the same AF_UNIX socket, so > only one VPP instance can be listener. Because of that you cannot configure > both master and slave to use same AF_UNIX socket. > This is simply how system works. > I understand UNIX. I get it. > On other side it is perfectly fine to have one slave connected to 2 > different > masters where both connections have same interface ID. That's why > interface name is constructed out of 2 numbers. Having only interface_id > in interface name will simply not work in this case. > This I need help understanding still. What are the CLI commands to set this up? create memif id 13 master socket /tmp/master-13.sock create memif id 23 master socket /tmp/master-23.sock create memif id 100 slave ??? I don't know how the connections are set up. I _think_ you don't understand my issue here. I am in no way questioning the underlying implementation, nor am I questioning having the index-mappings that you use. My issue is in the names that get exposed to the user and when they become knowable. In order to make your mechanisms work, it relies on having to reveal or expose the names mid-setup and then proceeding with the rest of the setup commands. > Possible area for improvement is adding explicit "create memif listener > " > cli and API so > you can better control assignment mapping of file_id to actual AF_UNIX > socket. > OK, that is equivalent to my third suggestion, I think. Pre-allocating the sockets in a known order so that they have known index numbers. In advance. If you don't allow for the creation of the (socket-name to socket-index) mapping in advance of creating the memif itself, then the name of the memif effectively becomes something unwieldly like "memif /path/to/socket/foo.sock id 23" everywhere. > Today file_id is simply index to the pool of memif files. > I know. And that is the problem. You have exposed an unreliable allocation result to be the only authoritative and yet unknowable user identifier. And here by "user" I mean any other "API user". In no way can the user say "Make an item for me and call it ." Beside that, i don't see what else we can do to make your life easier > I think the problem stems from the fact that you expose the socket index to the user visible names, and there is no way of knowing what those values will be. I think the whole problem can be avoid by simply exposing a memif name with just the one id that is used during creation of the memif. From an implementation standpoint, I think it is pretty easy to add to the current implementation. - Add a hash in memif_main mapping user memif id to socket_index(*) - The uniqueness test during creation needs to be modified to check for the id within the global mapping, - When the memif is made, add the id to socket_index to the new hash - When the memif is removed, remove the id from the new hash Then only expose to the user the global memif id, and not the socket_index too. The user supplied the id in the first place during creation, so we satisfy the need to be able to say "Make a for me and call it ." So now the user knows that the corresponding SW IF will be named "memif-" without having to guess or rely on API call ordering. We had this same "naming problem" with loopback interfaces last year too, and we had to fix aspects of that as well. Similarly, the loopback interfaces were just created sequentially, but the user had no idea what interface name was actually created as a result. In order to determine that, the user must have run some form of "inspect the results" command before further configuration could take place on the corresponding interface. Just like with loopback interfaces then, we really need to have predictable naming creation mechanisms in every aspect of the API presented by VPP. Thanks, > Damjan > Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Some memif API and Naming Questions
On Sun, Jan 14, 2018 at 12:10 PM, Damjan Marion (damarion) < damar...@cisco.com> wrote: > > master 1: > create memif id 33 master socket /tmp/memif1.sock > > Interface name: memif-0/33 > Here! You know that because you had to look at "show int" or "show memif". What if earlier allocations of memif had happened to create a new socket? You don't know the "0" part of that name unless you look. Or rely on a very specific API call sequence ordering. > master 2: > create memif id 33 master socket /tmp/memif2.sock > > Interface name: memif-0/33 > No, it is a new socket, and a new pool index, so this one is named "memif1/33". And *that* is precisely the problem I am having to prevent here. Also, there are no dashes in these names despite your using them with me on every example you have sent me. vpp# create memif id 33 master socket /tmp/memif1.sock vpp# show memif interface memif0/33 id 33 mode ethernet file /tmp/memif1.sock flags listener-fd 28 conn-fd 0 num-s2m-rings 0 num-m2s-rings 0 buffer-size 0 vpp# create memif id 33 master socket /tmp/memif2.sock vpp# vpp# show memif interface memif0/33 id 33 mode ethernet file /tmp/memif1.sock flags listener-fd 28 conn-fd 0 num-s2m-rings 0 num-m2s-rings 0 buffer-size 0 interface memif1/33 id 33 mode ethernet file /tmp/memif2.sock flags listener-fd 29 conn-fd 0 num-s2m-rings 0 num-m2s-rings 0 buffer-size 0 > slave: > create memif id 33 slave socket /tmp/memif1.sock > create memif id 33 slave socket /tmp/memif2.sock > > Interface names: memif-0/33, memif-1/33 No. vpp# create memif id 33 slave socket /tmp/memif1.sock create memif: Interface with same id already exists > I _think_ you don't understand my issue here. I am in no way > > questioning the underlying implementation, nor am I questioning > > having the index-mappings that you use. > > > > My issue is in the names that get exposed to the user and when > > they become knowable. > > > > > In order to make your mechanisms work, it relies on having to reveal > > or expose the names mid-setup and then proceeding with the rest > > of the setup commands. > > > > > Possible area for improvement is adding explicit "create memif listener > " > > cli and API so > > you can better control assignment mapping of file_id to actual AF_UNIX > socket. > > > > OK, that is equivalent to my third suggestion, I think. Pre-allocating > the sockets > > in a known order so that they have known index numbers. In advance. > > If you don't allow for the creation of the (socket-name to socket-index) > mapping in advance > > of creating the memif itself, then the name of the memif effectively > becomes something > > unwieldly like "memif /path/to/socket/foo.sock id 23" everywhere. > > > > Today file_id is simply index to the pool of memif files. > > > > I know. And that is the problem. You have exposed an unreliable > allocation > > result to be the only authoritative and yet unknowable user identifier. > And here > > by "user" I mean any other "API user". In no way can the user say "Make > an > > item for me and call it ." > > > > Beside that, i don't see what else we can do to make your life easier > > > > I think the problem stems from the fact that you expose the socket index > > to the user visible names, and there is no way of knowing what those > > values will be. > > > > I think the whole problem can be avoid by simply exposing a memif name > > with just the one id that is used during creation of the memif. From an > > implementation standpoint, I think it is pretty easy to add to the > current > > implementation. > > - Add a hash in memif_main mapping user memif id to socket_index(*) > > - The uniqueness test during creation needs to be modified to check > >for the id within the global mapping, > > - When the memif is made, add the id to socket_index to the new hash > > - When the memif is removed, remove the id from the new hash > > > > Then only expose to the user the global memif id, and not the > socket_index too. > > The user supplied the id in the first place during creation, so we > satisfy the > > need to be able to say "Make a for me and call it ." So now > > the user knows that the corresponding SW IF will be named "memif-" > > without having to guess or rely on API call ordering. > > > I dont like this proposal, it adds another ID to the game or limits us for > using same > id on 2 different socket files. No, I don't think it does limit anything like that. The underlying implementation can remain the same, and the connection set ups can remain. It's just the name of the interface that gets created is in a single global namespace like "memif%d". > Just like with loopback interfaces then, we really need to have > predictable > > naming creation mechanisms in every aspect of the API presented by VPP. > > If "create memif socket file id [master|slave|" > works for you i would suggest that we go that way. > I'm not able to use the CLI, so I wa
Re: [vpp-dev] Some memif API and Naming Questions
Hi Damjan, Let's try again. I've spoken with a colleague here and I think I may have misunderstood a few aspects of your proposal. Reviewing it with him, I think we can make it work! Let me review, and see if I understand (better) what you are saying and proposing. You said: On Sun, Jan 14, 2018 at 12:10 PM, Damjan Marion (damarion) < damar...@cisco.com> wrote: > > If "create memif socket file id [master|slave|" > works for you i would suggest that we go that way. > > So scenario above will look like: > > master 1: > create memif socket file /tmp/memif1.sock id 11 server > create memif id 33 master socket-id 11 > > Interface name: memif-11/33 > > master 2: > create memif socket file /tmp/memif2.sock id 22 server > create memif id 33 master socket-id 22 > > Interface name: memif-22/33 (OK, so my first point of misunderstanding here was that you had two different instances of VPP, one for each master, in this example. But that doesn't matter WRT the proposal.) Second, I didn't realize that these were two separate API calls now. Specifically, I now think you are saying that this command: create memif socket file /tmp/memif1.sock id 11 server Is a new memif API call that places the socket file name in a table with the user-assigned id 11 associated with it. Later, a "create memif" API call can reference "socket id 11" as its socket, along with its memif id, (here 33), so that it would yield the SW IF name "memif11/33". If so, this is perfect and satisfies the naming problem that I was describing. > slave: > create memif socket file /tmp/memif1.sock id 11 client > create memif socket file /tmp/memif2.sock id 22 client > create memif id 33 slave socket-id 11 > create memif id 33 slave socket-id 22 > > Interface names: memif-11/33, memif-22/33 > Right. So. Bottom line: I think this proposal is a viable solution! Would you like me to write a first patch effort? Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Heads up: VPPAPIGEN rewrite
On Wed, Jan 17, 2018 at 2:25 AM, Ole Troan wrote:
> Hi there,
>
> For a while there has been some interest in making the API language more
> explicit.
> This is a rewrite of the vppapigen generator with support for services {}
> (like grpc), enums, output plugins, better error checking.
>
The change is in:
> https://gerrit.fd.io/r/#/c/8781/
>
> The compiler generates the same output as before. As this has quite a few
> stake holders I will hold off for a week or so awaiting comments before
> asking for it to be published.
>
>
> Future planned features:
> - unions
> - bool, text
> - array support (including length)
> - proto3 output plugin
> - Refactor C/C++ generator as a plugin
> - Refactor Java generator as a plugin
Ole,
Can we add to the "Future Plans" list?
I would like to see it draw a correlation between a message's actual
list of fields and the attempt at a documentation for those fields.
Specifically, there always seems to be some discrepancy and it is
hard to tell which to believe without then going and reading the code.
If the fields and doc lines for the fields at least agreed on which fields
were present, that would be a start.
Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Heads up: VPPAPIGEN rewrite
On Thu, Jan 18, 2018 at 2:32 AM, Ole Troan wrote: > Hi Jon, > > I find embedded documentation (and excessive comments) problematic for > that exact reason. > Absolutely agree 100%. > We're never going to make them consistent. > Sadly, correct again. > Stepping back a little; I think we agree that the API, being the main > interface outside of VPP, should have good documentation. > Yes. > I don't think doxygen tags in the .api files can ever be that. > Agreed. > If you agree with that, do you have better suggestions? > Carry a large stick and use it frequently? Perhaps on every commit? :-) > Given that we have multiple language bindings, interactive documentation > like what Swagger has might be one option? > So, I might caution that this runs the risk of introducing a whole bunch of complexity and dependency where we might not need more. We need better writing and a willingness to write more complete sentences with an eye toward understanding that the details are maybe not yet obvious to the API user. That is, we need better content, not a more complex system to manage the content. Best regards, > Ole > HTH, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] Upcoming memif API and CLI changes.
Folks, Just a heads-up that I have submitted a patch that alters both the API and the CLI for the memif functions. That patch is being reviewed and will (hopefully) be merge soon. Prior to the patch, the memif CLI supported a create and a delete command roughly like this: vppctl# create memif id filename (master|slave) ... After the patch, the management of the will be through a separate API call and a corresponding CLI command: vppctl# create memif socket id filename Then in the memif interface command, one references the instead: vppctl# create interface memif id socket-id (master|slave) ... Note that in addition to the replacing the , the command itself has changed from "create memif" to "create interface memif". To flesh-out the patch, dump/details API calls were added for the new socket id-filename table, and VAT learned direct API call mechanisms for the new APIs as well. HTH, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] RFC: Error Codes
Hey VPP Aficionados, I would like to make a proposal for a new way to introduce error codes into the VPP code base. The two main motivations for the proposal are 1) to improve the over-all error messages coupled to their API calls, and 2) to clearly delineate the errors for VNET from those of various plugins. Recently, it was pointed out to me that the errors for the various plugins should not introduce new, plugin-specific errors into the main VNET list of errors (src/vnet/api_errno.h) on the basis that plugins shouldn't clutter VNET, should be more self-sustaining, and should stand alone. Without a set of generic error codes that can be used by the various plugins, there would then be no error codes as viable return values from the API calls defined by plugins. So here is my proposal: - Extend the API definition files to allow the definition of error messages and codes specific to VNET, or to a plugin. - Each plugin registers its error codes with a main registry upon being loaded. - The global error table is maintained, perhaps much like API enums today. - Each API call then has a guaranteed set of return values defined directly within its own API definition, thus coupling API calls and their possible returned error codes as well. Other thoughts? Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] RFC: Error Codes
On Tue, Jan 23, 2018 at 8:12 AM, Ole Troan wrote: > Dear Dave, > > > I would be tempted to have the compiler emit > > "foreach__api_error" > macros [or similar]: > > > > #define foreach_foo_api_error \ > > _(SUCCESS, "Success") \ > > _(ERROR, "This didn't go well") > > > > To minimize pain in upgrading existing C-code... > > Ah, yes of course. > Done. > https://gerrit.fd.io/r/#/c/10204/ > > Cheers, > Ole Glad to see you guys like the notion! With this, will plugins have to manage an error number base for each plugin now? Or will that be some form of magic behind the scene? Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] Re-verify a Commit?
Hey vpp-dev-iants, How do I kick-off a re-verify request after a patch fails to verify properly. It is the mystery "unknown failure", so we just need to try to rebuild it again. Am I just blindly missing a "reverify" button on an otherwise inscrutable Gerrit page somewhere? Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Re-verify a Commit?
On Tue, Jan 23, 2018 at 11:03 AM, Neale Ranns (nranns) wrote: > Hi Jon, > > > > Leave a code review comment of: > > recheck > > > > that will poke JJB to go do its thing again > > > > /neale > Ah, most excellent! ...and it looks like that has been done as well! Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] Missing PLY ?
Hey Kids, The new API Gen seems to want ply.lex, but I don't think it is listed as a dependency or something somewhere. Or maybe I have a really crappy Python. Dunno. Net effect, shown below, isn't good. Did I miss a step? Thanks, jdl make[4]: Entering directory `/home/jdl/workspace/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/build-vpp-native/vpp' APIGEN vlibmemory/memclnt.api.h JSON API vlibmemory/memclnt.api.json Traceback (most recent call last): File "/home/jdl/workspace/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/tools/bin/vppapigen", line 4, in import ply.lex as lex ImportError: No module named ply.lex Traceback (most recent call last): File "/home/jdl/workspace/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/tools/bin/vppapigen", line 4, in import ply.lex as lex ImportError: No module named ply.lex make[4]: *** [vlibmemory/memclnt.api.h] Error 1 make[4]: *** Waiting for unfinished jobs make[4]: *** [vlibmemory/memclnt.api.json] Error 1 make[4]: Leaving directory `/home/jdl/workspace/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/build-vpp-native/vpp' make[3]: *** [vpp-build] Error 2 make[3]: Leaving directory `/home/jdl/workspace/vpp/build-root/rpmbuild/vpp-18.04.0/build-root' make[2]: *** [install-packages] Error 1 make[2]: Leaving directory `/home/jdl/workspace/vpp/build-root/rpmbuild/vpp-18.04.0/build-root' error: Bad exit status from /var/tmp/rpm-tmp.8lAVBj (%build) ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Missing PLY ?
On Wed, Jan 24, 2018 at 1:10 PM, Florin Coras wrote: > Hi Dad, > LOL. I deserved that. At least I didn't get "Hi Old Man". :-) Did you try the evergreen: > > make wipe > make install-dep > make build > Yeah, have done a "make install-dep" a couple times now and it doesn't improve things at all. I seem to be using python 2.7.5. jdl jdl@bcc-1 $ python Python 2.7.5 (default, Aug 4 2017, 00:39:18) [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ply Traceback (most recent call last): File "", line 1, in ImportError: No module named ply >>> ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Missing PLY ?
> > Did you try the evergreen: >> >> make wipe >> make install-dep >> make build >> > > Yeah, have done a "make install-dep" a couple times now > and it doesn't improve things at all. > > I seem to be using python 2.7.5. > > > This seems to be working fine on centos7. They say ply is compatible with > both python 2 and 3 .. :/ > Oh, it works once it is installed! It appears to not be in the RPM_DEPENDS list. I can patch that up... jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] Building APIs outside of the VPP tree
Folks, I have updated to top-of-vpp master, now at commit: commit fc804d9cf1d23a616ea7bce19fc65198aa978e6e Author: Florin Coras Date: Fri Jan 26 01:27:01 2018 -0800 Fix session/tcp coverity warnings I am trying to build a VPP API outside of the VPP tree. It now wants to run this rule: %.api.h: %.api vppapigen --input $^ --output $@ Which is fine. It ends up using the VPP package install of /usr/bin/vppapigen, but that in turn wants to use ../share/cpp/C.py. That however, appears not to be installed: Exception: Error importing output plugin: /usr/bin/../share/vpp/C.py, [Errno 2] No such file or directory Did I miss a step somewhere? Or should the RPM bundle that up and install it as well now? Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Building APIs outside of the VPP tree
On Sat, Jan 27, 2018 at 3:37 PM, Jon Loeliger wrote:
> Folks,
>
> I have updated to top-of-vpp master, now at commit:
>
> commit fc804d9cf1d23a616ea7bce19fc65198aa978e6e
> Author: Florin Coras
> Date: Fri Jan 26 01:27:01 2018 -0800
>
> Fix session/tcp coverity warnings
>
> I am trying to build a VPP API outside of the VPP tree.
> It now wants to run this rule:
>
> %.api.h: %.api
> vppapigen --input $^ --output $@
>
> Which is fine.
>
> It ends up using the VPP package install of /usr/bin/vppapigen,
> but that in turn wants to use ../share/cpp/C.py. That however,
> appears not to be installed:
>
> Exception: Error importing output plugin: /usr/bin/../share/vpp/C.py,
> [Errno 2] No such file or directory
>
> Did I miss a step somewhere? Or should the RPM bundle that up
> and install it as well now?
>
> Thanks,
> jdl
>
Ole,
I applied this patch and it appears to work.
I am relatively certain there is a better patch trying to get out here. :-)
HTH,
jdl
diff --git a/extras/rpm/vpp.spec b/extras/rpm/vpp.spec
index 532b9a2..830ba4f 100644
--- a/extras/rpm/vpp.spec
+++ b/extras/rpm/vpp.spec
@@ -228,6 +228,9 @@ for i in $(ls
%{_mu_build_dir}/../src/vpp-api/java/jvpp/gen/jvppgen/*.py); do
install -p -m666 ${i} %{buildroot}%{python2_sitelib}/jvppgen
done;
+install -p -m 644 %{_mu_build_dir}/../src/tools/vppapigen/C.py
%{buildroot}/usr/share/vpp
+install -p -m 644 %{_mu_build_dir}/../src/tools/vppapigen/JSON.py
%{buildroot}/usr/share/vpp
+
# sample plugin
mkdir -p -m755 %{buildroot}/usr/share/doc/vpp/examples/sample-plugin/sample
#for file in $(cd
%{_mu_build_dir}/%{_vpp_install_dir}/../../src/examples/sample-plugin &&
git ls-files .)
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Building APIs outside of the VPP tree
On Sun, Jan 28, 2018 at 2:42 PM, Ole Troan wrote: > Thanks for fixing it Jon! > I'm not sure there is anything much better than that. ;-) > > Cheers, > Ole I'll submit a real patch to Gerrit then. Thanks! jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] VXLAN Tunnel IF Names
Hey Developers, I've turned my attention to the wondrous world of VXLANs! And with that, I stare into the Vast VXLAN API Abyss... My first question, as usual, involves the SW IF that is created by the vxlan tunnel create API call. The IF has a name that is once-again unknowable by the User who creates the tunnel unless direct inspection takes place. Can we somehow invert the naming responsibility here so that the API states either the name or the unique integer used to form the the SW IF tunnel name? Or perhaps it can be formed using the VNI number? Inspecting the reply return value isn't good enough; we need to be able to know, in advance, what the tunnel SW IF name will be. This is, again, the same naming problem we've had in the past with Loopback IFs, bridges, and recently memif socket names. If directly using the VNI won't work, I can work up a patch to allow user numbering in the style of, say, bridges, if that would be helpful. Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] Consolidatation of fib_ip_proto() functions?
Neale,
I have need of using a function like fib_ip_proto(), below, in yet another
file.
But rather than introduce a 5th copy of the same function, would you
accept a patch that consolidated them all into one static inline in, say,
fib_types.h where the FIB_PROTOCOL_* values are defined?
Thanks,
jdl
static inline fib_protocol_t
fib_ip_proto(bool is_ip6)
{
return (is_ip6) ? FIB_PROTOCOL_IP6 : FIB_PROTOCOL_IP4;
}
jdl@bcc-1 $ git grep fib_ip_proto src/
src/plugins/gtpu/gtpu.c:fib_ip_proto (bool is_ip6)
src/plugins/gtpu/gtpu.c: fib_protocol_t fp = fib_ip_proto (is_ip6);
src/plugins/gtpu/gtpu.c: encap_fib_index = fib_table_find
(fib_ip_proto (ipv6_set), tmp);
src/vnet/geneve/geneve.c:fib_ip_proto (bool is_ip6)
src/vnet/geneve/geneve.c: fib_protocol_t fp = fib_ip_proto (is_ip6);
src/vnet/geneve/geneve.c: encap_fib_index = fib_table_find
(fib_ip_proto (ipv6_set), tmp);
src/vnet/vxlan-gpe/vxlan_gpe.c:fib_ip_proto (bool is_ip6)
src/vnet/vxlan-gpe/vxlan_gpe.c: fib_protocol_t fp = fib_ip_proto (is_ip6);
src/vnet/vxlan/vxlan.c:fib_ip_proto(bool is_ip6)
src/vnet/vxlan/vxlan.c: fib_protocol_t fp = fib_ip_proto(is_ip6);
src/vnet/vxlan/vxlan.c:encap_fib_index = fib_table_find
(fib_ip_proto (ipv6_set), tmp);
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] VXLAN Tunnel IF Names
On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj) wrote: > Hi Jon, > Hi John, Thanks for taking the time to get back to me on this! All VPP tunnel creation uses the mechanism of returning a sw_if_index of > the created tunnel. > I know. I get that. It works. > The name of the tunnel is then followed by a number being the instance or > index to the tunnel struct vector. Thus, the first VXLAN tunnel created is > called vxlan_tunnel0 followed by vxlan_tunnel1, etc. The number is > incrementing unless tunnels are deleted and created again where a newly > created tunnel will reuse the last deleted tunnel, hence its name. If all > previously deleted tunnels are used up, then the tunnel name number will > start incrementing again. > Right. > I am not sure if it is feasible to follow this behavior to “predict” > tunnel name. > It is not. The problem is not just "predict it", but the user has to be able to know the associated SW IF name at the time that the (vxlan tunnel) create API call happens. The reason for that is because the very next thing the API call user is going to want to do is configure that interface. Short of interrogating the system, there is no way to know the IF name. (I understand that the name can be obtained from the sw_if_index. That's not what I mean.) Consider this series of PEUDO API calls that are being issued by some client front-end. Think of this as a batch of CLI commands: vxlan MyVxlan23 source 1.2.3.4 destination 10.11.12.13 vni 19 exit interface do stuff to interface like apply an ACL or whatever exit There is no way to batch-run those as there is a step needed to determine what is. It could be "vxlan_tunnel..." anything. That has to match a VPP interface by name. But what name? The entire transactional history of VXLANs must be known in order to guess the next name. BTW, GRE tunnels are created and named the same way. You added TEB > (transparent ethernet bridging) support to GRE. Have you not been using it > and bothered by how to predict name of created GRE tunnels? > I've not touched GRE yet. However, it is next on my list to fix! My current plan is to submit essentially the same patch there too. It is not a good idea to tie tunnel name to VNI as it is not a unique ID to > identify VXLAN tunnels. It is quite common for existence of multiple VXLAN > tunnels with the same VNI with different remote end point IP addresses. A > bridge domain (BD) may have multiple VXLAN tunnels with the same VNI to > several remote servers where the same overlay network exist. It is quite > common to use the ID for BD or VLAN as the VNI for all its VXLAN tunnels to > make it easier to track their usage. > Excellent! Thank you for this insight! That makes total sense now! I suppose it is feasible to provide another set of VXLAN tunnel > create/delete API to allow caller to specify instance or number of the > tunnel, similar to what you did for loopback interface. > This is the route I was headed: Just like loopback interface naming! In this case, the above example would be, perhaps, something like this: vxlan MyVxlan23 instance 101 source 1.2.3.4 destination 10.11.12.13 vni 19 exit interface vxlan_tunnel101 do stuff to interface like apply an ACL or whatever exit One complication for the new API is that, upon VXLAN tunnel deletion, the > interface created for the tunnel is not really deleted by the current code > but put into a reuse pool. > I solved that by making a trivial vxlan_name_renumber() function, and then calling vnet_interface_name_remumber(sw_if_index, instance) to update the previously captured "vxlan_tunnel" name and rename it using the new instance number. When more tunnels are created, any interface from reuse pool with its > existing interface name will be used for the new tunnel, before new > interfaces are created. If a interface is reused upon tunnel creation, its > interface name may not match the specified tunnel instance/number of the > new tunnel creation API. One way to overcome this may be to not keep > interface in reused pool on tunnel deletion. Thus, tunnel creation would > always create new interface. For backward compatibility, I suppose we can > keep the tunnel create/delete API as is so interfaces of deleted tunnels > are kept for reuse. The new API will then always create/delete interface on > tunnel create/delete. This would put a restriction that user should not > mix the usage of new or old APIs. > To me, that sounds like a whole bunch of really unnecessary code replication and fragile separation of API results that will invariably get mixed up and cause mysterious failures. Instead, I maintain the original instance allocation scheme when there is no requested Instance Id made by the CLI or API user. I have submitted a patch to Gerrit. When this passes "verify", I'll add you to be a Reviewer! HTH, jdl __
Re: [vpp-dev] VXLAN Tunnel IF Names
On Fri, Feb 2, 2018 at 3:08 PM, Jon Loeliger wrote: > > I have submitted a patch to Gerrit. When this passes "verify", I'll add > you to be > a Reviewer! > John, How do I run just these tests locally? I need to determine if these failures are due to my patch or not. Specifically, I am not able to succesfully "make test" on a CentOS system due to Python having a memory corruption failure and dumping core on me. As many tests until that point were passing though. I'll add you as a patch reviewer anyway -- maybe you can spot something brain-dead that I did in the patch...? Thanks, jdl *20:46:28* 20:33:41 *20:46:28* 20:33:41 Tests.Vpp.Func.Ip6.Eth2P-Ethip6-Ip6Base-Ip6Ecmp-Func :: *Ipv6 Multipath routing test cases* *20:46:28* 20:33:41 *20:46:28* 20:34:06 TC01: IPv6 Equal-cost multipath routing :: [Top] TG=DUT | PASS |*20:46:28* 20:34:06 *20:46:28* 20:34:06 Tests.Vpp.Func.Ip6.Eth2P-Ethip6-Ip6Base-Ip6Ecmp-Func :: *Ipv6 Multipath routing test cases* | PASS |*20:46:28* 20:34:06 1 critical test, 1 passed, 0 failed*20:46:28* 20:34:06 1 test total, 1 passed, 0 failed*20:46:28* 20:34:06 *20:46:28* 20:34:06 Tests.Vpp.Func.Ip6.Eth2P-Ethip6-Ip6Base-Ip6Ra-Func :: *IPv6 Router Advertisement test cases* *20:46:28* 20:34:06 *20:46:28* 20:34:20 TC01: DUT transmits RA on IPv6 enabled interface :: [Top] TG-DUT1-DUT2-TG. | PASS |*20:46:28* 20:34:20 *20:46:28* 20:34:36 TC02: DUT retransmits RA on IPv6 enabled interface after a set interval :: [Top] TG-DUT1-DUT2-TG. | PASS |*20:46:28* 20:34:36 *20:46:28* 20:34:49 TC03: DUT responds to Router Solicitation request :: [Top] TG-DUT1-DUT2-TG. | FAIL |*20:46:28* 20:34:49 Traffic script execution failed*20:46:28* 20:34:49 *20:46:28* 20:35:02 TC04: DUT responds to Router Solicitation request sent from link local address :: [Top] TG-DUT1-DUT2-TG.| FAIL |*20:46:28* 20:35:02 Traffic script execution failed*20:46:28* 20:35:02 *20:46:28* 20:35:02 Tests.Vpp.Func.Ip6.Eth2P-Ethip6-Ip6Base-Ip6Ra-Func :: *IPv6 Router Advertisement test cases*| PASS |*20:46:28* 20:35:02 0 critical tests, 0 passed, 0 failed*20:46:28* 20:35:02 4 tests total, 2 passed, 2 failed*20:46:28* 20:35:02 ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] VXLAN Tunnel IF Names
On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj) wrote: > Hi Jon, > > > > All VPP tunnel creation uses the mechanism of returning a sw_if_index of > the created tunnel. The name of the tunnel is then followed by a number > being the instance or index to the tunnel struct vector. Thus, the first > VXLAN tunnel created is called vxlan_tunnel0 followed by vxlan_tunnel1, > etc. The number is incrementing unless tunnels are deleted and created > again where a newly created tunnel will reuse the last deleted tunnel, > hence its name. If all previously deleted tunnels are used up, then the > tunnel name number will start incrementing again. I am not sure if it is > feasible to follow this behavior to “predict” tunnel name. > John and Dave, I have uploaded a new patch set. It is being verified at the time of this writing. This patch has a different implementation than the previous version. The API changes, including VAT-n-friends, have been updated a bit, but the basic mechanism of obtaining predictable SW IF names is different from my original patch. In the current form, I followed an existing "custom device instance" pattern that was already present on several other objects already. Much simpler, and I expect it to verify now. :-) So, I guess I realize my mistake in my previous discussions of this general problem I apparently wasn't using the right words. I was saying something like "The User needs to be able to know or predict the SW IF name." The phrase that seems to be used specifically for this purpose in many other places is "Let the user assign a custom device instance id." And that is achieved via the use of the so-called *_name_renumber() class function. So my earlier plea for a "can we somehow solve this at a higher level" might be more properly stated as: Where objects are created as a side-effect of some other creation request, a "renumber flag and custom device instance" would be really nice on the Create API call. HTH, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] VXLAN Tunnel IF Names
On Mon, Feb 5, 2018 at 9:29 AM, John Lo (loj) wrote:
> Hi Jon,
>
Hi John,
> I don’t think the renumber scheme, as used by vhost and tap interfaces, is
> foolproof and can cause problems if used extensively for vxlan. On
> creating an interface with renumber, it does not check if the instance
> being requested is already used by another device. On creating an interface
> without renumber, it also does not check if the “natural instance’ may have
> already been used by another device’s renumber. Thus, on instance
> collision, last interface will take over the interface name and leave the
> previous interface not accessible by the duplicated interface name.
>
I was solving that the UI level, but it could be added into the
vxlan_add_del_interface() layer as well.
> I think we must check and reject instance misuse for this to be
> acceptable. I doubt the renumber is really used much for vhost and tap
> interface (others please correct me if not true).
>
We do use them on every call we make to these functions.
As well as on loopbacks. Knowing what object (by name) will b
created is essential for us.
> I see a “FIXME” warning in the existing vhost renumber function:
>
>
>
> static int
>
> vhost_user_name_renumber (vnet_hw_interface_t * hi, u32 new_dev_instance)
>
> {
>
> // FIXME: check if the new dev instance is already used
>
> vhost_user_main_t *vum = &vhost_user_main;
>
> vec_validate_init_empty (vum->show_dev_instance_by_real_dev_instance,
>
> hi->dev_instance, ~0);
>
Hmmm, yes, I see ...
> In your previous patch set #1, the usage of a bitmap to track instance
> usage seem a reasonable solution. It does imply we will never use “natural”
> instance and would always use the instance allocated from the bitmap and
> stored in the tunnel struct.
>
This procedure fails for some reason on the 5th test in VXLAN tests.
I am not certain, but I think it is because the renumbering effort was
trying to get the desired instance number out of the tunnel struct,
which lead to finding the corresponding vnet_hw_interface, and when
it needed to renumber, the hi->hw_if_index or hi->dev_instance wasn't
yet set, and it ended up creating IFs with wrong names (always 0?).
That said, we can combine the two approaches. That is, use the
show_instance_by_real_instance vector for knowing what name to use,
but also use a bitmap to record what was used and allocated.
One question on the bitmap approach. It had a hard-coded upper limit of 16K
bits in my previous patch. Are people OK with that? It is arbitrary, and
could
be larger. It simply depends on how much memory folks are willing to spend
recording in-use bits. That or a search of the show_by_real vector. Or we
could convert to a hash-map to check "in-use" status.
Preference?
As for the API/CLI, I though another parameter “instance” would suffice as
> ~0 can be used to state “not specified” rather than having an additional
> parameter “renumber”, although I can accept either way.
>
Two things here. I'm fine with either as well. I was following the
existing
pattern for the "renumber" approach. Using ~0 effectively means that the
message constructors must all explicitly initialize this field to ~0. I'm
good
with that (previous patch!) if you guys are as well.
Regards,
>
> John
>
Thanks for your feedback!
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] VXLAN Tunnel IF Names
On Mon, Feb 5, 2018 at 9:55 AM, Jon Loeliger wrote: > > > >> I think we must check and reject instance misuse for this to be >> acceptable. I doubt the renumber is really used much for vhost and tap >> interface (others please correct me if not true). >> > > We do use them on every call we make to these functions. > As well as on loopbacks. Knowing what object (by name) will b > created is essential for us. > > >> >> > In your previous patch set #1, the usage of a bitmap to track instance >> usage seem a reasonable solution. It does imply we will never use “natural” >> instance and would always use the instance allocated from the bitmap and >> stored in the tunnel struct. >> > > That said, we can combine the two approaches. That is, use the > show_instance_by_real_instance vector for knowing what name to use, > but also use a bitmap to record what was used and allocated. > > One question on the bitmap approach. It had a hard-coded upper limit of > 16K > bits in my previous patch. Are people OK with that? It is arbitrary, and > could > be larger. It simply depends on how much memory folks are willing to spend > recording in-use bits. That or a search of the show_by_real vector. Or we > could convert to a hash-map to check "in-use" status. > > Preference? > John, Also as a point of information, I'd like to follow this approach for GRE as well as soon as we agree on an approach here! Thanks! jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] VXLAN Tunnel IF Names
On Mon, Feb 5, 2018 at 11:48 AM, John Lo (loj) wrote: > One more thang, I would prefer to have a u32 instance number instead of > the 64 bytes if_name in the vxlan_tunnel_details API. -John > Hi John, I'll work up a patch re-spin using a hash-table, and I will include the if_name -> sw_if_index change mentioned above! Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] VXLAN Tunnel IF Names
John, On Mon, Feb 5, 2018 at 2:14 PM, John Lo (loj) wrote: > Thanks Jon. Seems we have an agreed upon an approach now. Just to be > sure, let me list the specifics: > > > > 1. We will get rid of custom_instance_by_real_instance vector in > vxlan_main_t > See #3 below. > 2. We will add something like user_instance_by_real_instance hash in > vxlan_main_t to track instance usage. > Yes. > 3. We will add u32 instance in vxlan_tunnel_t to keep user specified > instance, which will be the same as real instance or index of vxlan tunnel > in the tunnels vector in vxlan_main. > > I am happy to do this, yes. However, there is some reason that this number can not be used directly within the format() of the vxlan_tunnel%d name. At the time that the reuse of the HW IF happens, the necessary name_renumber() call fails to get the right instance number as the hw_if_index isn't set in the hi struct properly yet. This is why the custom_instance_by_real_instance mechanism works: it is always available. I will endeavor to use just the hash and the instance on the tunnel struct. I will attempt to resolve the issue described in the previous paragraph in more detail. I know that was a bit vague, so I'll attempt to nail-down the real issue I was seeing. 4. We will replace the 64 byte if_name in the vxlan_tunnel_details API > with u32 instance. > Yes. > 5. We will generate instance-in-use API error if vxlan tunnel > creation cannot use the desired instance, either natural or specified. > Yes. We also have to guarantee that: in the case of default allocation (ie, not specified by the user/API), that there still always a successful allocation. (Ie, a bit of searching for a valid instance might take place.) I don't think this will be a problem in general. it will likely only be noticed when both default and specified allocations are intermixed. > Will review your new patch set when it shows up. Once you patch is > merged, I will copy the same mechanism into the GRE tunnel update I am > currently working. I will submit my GRE patch for review sometime later and > add you as one of the reviewers. > Awesome! Sounds great! > Thanks, > > John > Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] _mm_testz_si128 Woes
Hey hey hey, I tried to build a variant of vppsb and failed miserably for lack of the __mm_testz_si128 symbol. >From whence does that arrive on my doorstep? I'm trying to figure out if vppsb needs to #define something new, or #include something first, or if my system is suddenly missing something assumed to be present and VPP cleverly allowed for it to be missing while vppsb was less so? Thanks, jdl ```libtool: compile: gcc -DPACKAGE_NAME=\"netlink\" -DPACKAGE_TARNAME=\"netlink\" "-DPACKAGE_VERSION=\"1.0.1-21~g888408a\"" "-DPACKAGE_STRING=\"netlink 1.0.1-21~g888408a\"" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"netlink\" "-DVERSION=\"1.0.1-21~g888408a\"" -I. -Wall -fstack-protector -fPIC -Werror -g -DFORTIFY_SOURCE=2 -O2 -I/home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -c librtnl/netns.c -fPIC -DPIC -o librtnl/.libs/netns.o In file included from /home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/vector.h:262:0, from /home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/mheap_bootstrap.h:47, from /home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/mem.h:47, from /home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/vec.h:42, from /home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/format.h:44, from /home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/elf.h:41, from /home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/elf_clib.h:41, from /home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vlib/vlib.h:44, from ./librtnl/netns.h:19, from librtnl/netns.c:16: /home/jdl/work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/vector_sse2.h: In function 'u8x16_is_all_zero': /home/jdlwork/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vppinfra/vector_sse2.h:552:3: error: implicit declaration of function '_mm_testz_si128' [-Werror=implicit-function-declaration] return _mm_testz_si128 ((__m128i) x, (__m128i) x); ^ cc1: all warnings being treated as errors ```
[vpp-dev] VXLAN Instances Not Freed Properly?
John, et al, I stumbled across this interesting behavior in VXLAN tunnels: vpp# create vxlan tunnel src 1.2.3.4 dst 10.11.12.13 vni 1 instance 101 vxlan_tunnel101 vpp# create vxlan tunnel src 1.2.3.4 dst 10.11.12.13 vni 1 instance 101 del vpp# create vxlan tunnel src 1.2.3.4 dst 10.11.12.13 vni 1 instance 101 create vxlan tunnel: Instance is in use And note the actual interface has been removed, so 101 should be free: 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 I was pretty sure this was working, but I might have botched that patch somehow? Any chance you stumbled into this problem? It might be worth noting that the equivalent GRE does work: vpp# create gre tunnel src 1.2.3.4 dst 10.11.12.13 instance 14 gre14 vpp# create gre tunnel src 1.2.3.4 dst 10.11.12.13 instance 14 del DELETED vpp# create gre tunnel src 1.2.3.4 dst 10.11.12.13 instance 14 gre14 I feel like this might be some typo or easy oversight in the VXLAN case. Thanks, jdl
Re: [vpp-dev] VXLAN Instances Not Freed Properly?
On Fri, Feb 23, 2018 at 4:43 PM, John Lo (loj) wrote: > Hi Jon, > > > > I see the problem in the delete path where the hash_unset() call is using > the tunnel instance instead of the user_instance of the tunnel starting at > about line 558 of vxlan.c: > > > > vnet_delete_hw_interface (vnm, t->hw_if_index); > > hash_unset (vxm->instance_used, instance); > Woah. Awesome. > Do you mind submit a patch to fix it, please? > Will do! > Regards, > > John > Thanks, jdl
Re: [vpp-dev] Upcoming memif API and CLI changes.
Peter, > Trying to configure Memif: > > > > vat# memif_dump > > Sending ping id=714 > > memif0/0: sw_if_index 3 mac 02:fe:db:be:87:29 > >id 0 socket-id 0 role slave > >ring_size 1 buffer_size 0 > >state down link down > If you also dump the memif socket table you should see that socket-id 0 is the default socket filename. Which means ... > vat# memif_socket_filename_add_del add id 0 filename /tmp/memif > > Invalid socket idmemif_socket_filename_add_del error: Misc > you can neither create nor delete that socket-id 0. > vat# memif_socket_filename_add_del add id 1 filename /tmp/memif > > memif_socket_filename_add_del error: Misc > > > > vat# memif_create id 0 socket-id 1 master > > memif_create error: Invalid argument > That might be an issue... And it might be localized to VAT because: vpp# create memif socket id 1 filename /tmp/foo.sock vpp# show memif sockets id listenerfilename 0 no /run/vpp/memif.sock 1 no /tmp/foo.sock I'll peer at VAT unless John Lo beats me to it. :-) jdl
Re: [vpp-dev] Upcoming memif API and CLI changes.
Peter, On Tue, Feb 27, 2018 at 11:09 AM, Jon Loeliger wrote: > Peter, > > vat# memif_socket_filename_add_del add id 1 filename /tmp/memif >> >> memif_socket_filename_add_del error: Misc >> >> >> >> vat# memif_create id 0 socket-id 1 master >> >> memif_create error: Invalid argument >> > > That might be an issue... And it might be localized to VAT because: > > vpp# create memif socket id 1 filename /tmp/foo.sock > vpp# show memif > sockets > id listenerfilename > 0 no /run/vpp/memif.sock > 1 no /tmp/foo.sock > > I'll peer at VAT unless John Lo beats me to it. :-) > > jdl > Indeed this was a bug in the VAT call to that API function. I have submitted the patch: https://gerrit.fd.io/r/#/c/10848/ to address this issue. Thank you! jdl ._,_. Tt
[vpp-dev] Tap and Tap-inject
Discuss:
Two Things That Don't Work Together: Tap and Tap-inject
In today's world of discord, we often stray into territory that seems
benign and harmless; a world that should be harmonious and
fruitful. Yet, a cursory inspection yields quizzical behavior, mysterious
happenings, and hidden messages. This is the world of Tap and
Tap-injection after lifting the rock cap hiding them.
A simplistic approach would start with the tried-and-true invocation of
VPP using an interactive unix clause. For those not in the know, who
suspect an arcane craft is at work, the following could be used:
$ vppctl unix { interactive cli-listen /run/vpp/cli.sock gid vpp }
Lo! The hidden messages are quick to appear! Some of the most unusual
are these:
0: tap_inject_is_config_enabled:140: tap_inject_is_config_enabled:
Value of im->flags is 0
0: tap_inject_sw_interface_add_del:706:
tap_inject_sw_interface_add_del: tap_inject is disabled in config
The astute would be quick to see that the messages appear for each interface
configured on the system. And that they pertain to the mysteries at hand:
Tap-injection.
To verify that all is well, invoke the powerful VPP controller and create a
tap!
vpp# create tap host-if-name bob id 23
0: tap_inject_is_config_enabled:140: tap_inject_is_config_enabled:
Value of im->flags is 0
0: tap_inject_sw_interface_add_del:706:
tap_inject_sw_interface_add_del: tap_inject is disabled in config
vpp#
As if my magic call-backs, the same messages appear again on the VPP
console.
Do not be lured into a false sense of security, believing all is puppies and
pink unicorns. There is hidden woe here.
And here is the ominous part. Enable tap-inject. All should be well,
right?
All the taps and tap-derivatives should be aware and pleased with each
other.
But no.
vpp# enable tap-inject
Argh! Ho. Ly. Cow! There are more hidden messages! A lot!
0: tap_inject_iface_isr:572: tap_inject_iface_isr: Enable: sw_if_index 1
0: tap_inject_iface_isr:611: tap_inject_iface_isr: creating host intf for
sw_if_index 1
0: tap_inject_tap_connect:151: tap_inject_tap_connect: sw_if_index 1 thread
0 fd 35
0: tap_inject_tap_connect:168: tap_inject_tap_connect: Found fd 35 for
thread 0
0: tap_inject_tap_connect:197: tap_inject_tap_connect: Setting hardware
address : 0:8:162:11:33:50
0: tap_inject_tap_connect:221: tap_inject_tap_connect: tap_if_index is 401
0: tap_inject_tap_connect:224: tap_inject_tap_connect: Mapping sw_if_index
1 tap_fd 35 tap_if_index 401 thread 0
0: tap_inject_iface_isr:572: tap_inject_iface_isr: Enable: sw_if_index 2
0: tap_inject_iface_isr:611: tap_inject_iface_isr: creating host intf for
sw_if_index 2
0: tap_inject_tap_connect:151: tap_inject_tap_connect: sw_if_index 2 thread
0 fd 36
0: tap_inject_tap_connect:168: tap_inject_tap_connect: Found fd 36 for
thread 0
0: tap_inject_tap_connect:197: tap_inject_tap_connect: Setting hardware
address : 0:8:162:11:33:51
0: tap_inject_tap_connect:221: tap_inject_tap_connect: tap_if_index is 402
0: tap_inject_tap_connect:224: tap_inject_tap_connect: Mapping sw_if_index
2 tap_fd 36 tap_if_index 402 thread 0
0: tap_inject_iface_isr:572: tap_inject_iface_isr: Enable: sw_if_index 3
0: tap_inject_iface_isr:611: tap_inject_iface_isr: creating host intf for
sw_if_index 3
0: tap_inject_tap_connect:151: tap_inject_tap_connect: sw_if_index 3 thread
0 fd 37
0: tap_inject_tap_connect:168: tap_inject_tap_connect: Found fd 37 for
thread 0
0: tap_inject_tap_connect:197: tap_inject_tap_connect: Setting hardware
address : 0:8:162:11:33:52
0: tap_inject_tap_connect:221: tap_inject_tap_connect: tap_if_index is 403
0: tap_inject_tap_connect:224: tap_inject_tap_connect: Mapping sw_if_index
3 tap_fd 37 tap_if_index 403 thread 0
0: tap_inject_iface_isr:572: tap_inject_iface_isr: Enable: sw_if_index 4
0: tap_inject_iface_isr:611: tap_inject_iface_isr: creating host intf for
sw_if_index 4
0: tap_inject_tap_connect:151: tap_inject_tap_connect: sw_if_index 4 thread
0 fd 38
0: tap_inject_tap_connect:168: tap_inject_tap_connect: Found fd 38 for
thread 0
0: tap_inject_tap_connect:197: tap_inject_tap_connect: Setting hardware
address : 0:8:162:11:33:53
0: tap_inject_tap_connect:221: tap_inject_tap_connect: tap_if_index is 404
0: tap_inject_tap_connect:224: tap_inject_tap_connect: Mapping sw_if_index
4 tap_fd 38 tap_if_index 404 thread 0
0: tap_inject_iface_isr:572: tap_inject_iface_isr: Enable: sw_if_index 5
0: tap_inject_iface_isr:611: tap_inject_iface_isr: creating host intf for
sw_if_index 5
0: tap_inject_tap_connect:151: tap_inject_tap_connect: sw_if_index 5 thread
0 fd 39
0: tap_inject_tap_connect:168: tap_inject_tap_connect: Found fd 39 for
thread 0
0: tap_inject_tap_connect:197: tap_inject_tap_connect: Setting hardware
address : 2:254:145:56:99:30
0: tap_inject_tap_connect:221: tap_inject_tap_connect: tap_if_index is 405
0: tap_inject_tap_connect:224: tap_inject_tap_connect: Mapping sw_if_index
5 tap_fd 39 tap_if_index 405 thread 0
But that i
Re: [vpp-dev] Tap and Tap-inject
On Wed, Feb 28, 2018 at 5:59 PM, Jon Loeliger wrote: > Discuss: > > Two Things That Don't Work Together: Tap and Tap-inject > > In today's world of discord, we often stray into territory that seems > benign and harmless; a world that should be harmonious and > fruitful. Yet, a cursory inspection yields quizzical behavior, mysterious > happenings, and hidden messages. This is the world of Tap and > Tap-injection after lifting the rock cap hiding them. > Hi Guys-n-Gals, I have posted the following patch to address this issue: https://gerrit.fd.io/r/#/c/10942/ HTH, jdl
[vpp-dev] A Question about SPAN Dump Details
John, et al, Could we add the "is_l2" flag into the SPAN details message so that we don't have to maintain global state about what type of detail is coming back? Happy to submit that patch if you are OK with the suggestion. Thanks, jdl
Re: [vpp-dev] VPP As A Router Between Namespaces - 10ms latency
On Mon, Mar 12, 2018 at 3:57 AM, Sara Gittlin wrote: > Dear Florin, > > When using the command " create tap rx-ring-size 4096 tx-ring-size 4096 " > VPP create the devices with default names tap0, tap1, ..tapn. > > Is it possible for the user to set the name in the 'create' command line ? > > Thank you in advance > -Sara Hi Sara, Welcome to my battle! Luckily, there is a way to do as you wish! If you set the "instance" value during the tap_create API call, or use "id " during the "create tap ..." CLI command, you will create an interface of the name "tap". You may not use a different prefix than "tap", but at least you can know what the name will be when it is created. HTH, jdl
Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.
On Tue, Mar 13, 2018 at 5:47 AM, Klement Sekera wrote:
> I would say that this should be worth the extra effort just to have the
> same conditions. Otherwise the verify job does something different than
> `make test` on your box and that could be confusing.
>
> Thanks,
> Klement
These days, 'make test' on my box(*) running as not-root fails many tests.
I've not looked into it, but here are some. I'm going with duplicate API
message registration?
HTH,
jdl
(*) -- CentOS 7.4.1708
PAPI Message parsing Test Case
==
New compound type with array
ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-f22YXN ]
13:33:25,146 [Errno 17] File exists
ERROR: New compound type with array
--
Traceback (most recent call last):
File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line
281, in test_add_new_compound_type_with_array
msglist.add_type(p[0], p[1:])
File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 590, in add_type
typeonly=True)
File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: vl_api_ip4_fib_counter_t
==
ERROR: IPv6 FIB test
--
Traceback (most recent call last):
File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_ip6.py", line 343,
in test_fib
pkts = self.pg0.get_capture()
File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/vpp_pg_interface.py",
line 242, in get_capture
raise Exception("No packets captured on %s" % name)
Exception: No packets captured on pg0
ERROR: Add new message object
--
Traceback (most recent call last):
File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line 71,
in test_adding_new_message_object
msgdef = msglist.add_message(p[0], p[1:])
File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: show_version
ERROR: New message with array
--
Traceback (most recent call last):
File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line 87,
in test_adding_new_message_object_with_array
msglist.add_message(p[0], p[1:])
File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: ip_address_details
[vpp-dev] vppsb's librtnl is broken with top of VPP tree
Hey VPP-dev Is it me? It's me, isn't it. jdl librtnl/mapper.c: In function 'mapper_add_del_route': librtnl/mapper.c:101:31: error: passing argument 10 of 'fib_table_entry_path_add' from incompatible pointer type [-Werror] FIB_ROUTE_PATH_FLAG_NONE); ^ In file included from /work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vnet/fib/fib.h:647:0, from librtnl/mapper.c:25: work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vnet/fib/fib_table.h:332:25: note: expected 'struct fib_mpls_label_t *' but argument is of type 'mpls_label_t *' extern fib_node_index_t fib_table_entry_path_add(u32 fib_index, ^ librtnl/mapper.c:132:31: error: passing argument 10 of 'fib_table_entry_path_add' from incompatible pointer type [-Werror] FIB_ROUTE_PATH_FLAG_NONE); ^ In file included from work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vnet/fib/fib.h:647:0, from librtnl/mapper.c:25: work/vpp/build-root/rpmbuild/vpp-18.04.0/build-root/install-vpp-native/vpp/include/vnet/fib/fib_table.h:332:25: note: expected 'struct fib_mpls_label_t *' but argument is of type 'mpls_label_t *' extern fib_node_index_t fib_table_entry_path_add(u32 fib_index, ^ cc1: all warnings being treated as errors make[3]: *** [librtnl/mapper.lo] Error 1 make[3]: Leaving directory `/vppsb/netlink/build-root/rpmbuild/BUILD/netlink-1.0.1-22~gd8e6dbc-dirty' error: Bad exit status from /var/tmp/rpm-tmp.IlCmHt (%build)
[vpp-dev] Ccache vs VPPAPIGEN
Good Evening Sports Fans,
Have we got a match for you tonight!
In this corner, ccache. Loved for it speed and hackery, hated for
its invasive corruptibility.
In the other corner, we have vppapigen, loved tool of the single-source
definitions for all things yet hated as the monster that will not die!
Tonight we bring them together in the top-level Makefile, in a clause
that might leave a few, myself included, mystified:
ifeq ("$(wildcard /usr/bin/ccache )","")
@echo "WARNING: Please install ccache AYEC and re-run this script"
else
@rm -rf $(BR)/tools/ccache-bin
@mkdir -p $(BR)/tools/ccache-bin
@ln -s /usr/bin/ccache $(BR)/tools/ccache-bin/gcc
@ln -s /usr/bin/ccache $(BR)/tools/ccache-bin/g++
@ln -s /usr/bin/ccache $(BR)/tools/ccache-bin/clang
@ln -s /usr/bin/ccache $(BR)/tools/ccache-bin/clang++
mkdir -p $(BR)/tools/bin
rm -f $(BR)/tools/bin/vppapigen
ln -s $(WS_ROOT)/src/tools/vppapigen/vppapigen \
$(BR)/tools/bin/vppapigen
ls -lsa $(BR)/tools/bin
endif
@touch $@
You might recognize that as part of the $(BR)/.bootstrap.ok target!
It is! You could win!
But first, let's see what happens when ccache is NOt installed on the
build machine! Yep, you get that warning:
@echo "WARNING: Please install ccache AYEC and re-run this script"
Naturally, that is lost way, way, back at the beginning of the
scroll-back. Twenty
minutes of scroll-back. Unless Yes, in just under 2 minutes, the
build fails!
Quizically like this:
APIGEN vlibmemory/memclnt.api.h
JSON API vlibmemory/memclnt.api.json
/bin/sh: line 2: vppapigen: command not found
/bin/sh: line 2: vppapigen: command not found
So, yeah, installing ccache clears all that up.
And since using vppapigen is sort of necessary for the
whole build here, using ccache is not really an optional
build-time dependency anymore. If you're cools with that,
I'm cool with that, but we should list it as a build-time
requirement for all build hosts including CentOS:
$ git grep ccache Makefile
Makefile:CCACHE_DIR?=$(BR)/.ccache
Makefile:DEB_DEPENDS = curl build-essential autoconf automake ccache
Makefile:RPM_SUSE_BUILDTOOLS_DEPS = autoconf automake ccache check-devel chrpath
If no one beats me to it, I might submit a patch to
help the situation.
So it's a tie!
jdl
Re: [vpp-dev] Ccache vs VPPAPIGEN
On Thu, Mar 15, 2018 at 2:00 PM, Damjan Marion wrote: > > Lot of changes happened in this area in last 48 hours. There is no > bootstrap step needed anymore. > > Do you still see issues? > Damjan, I believe your changes have fixed things. Thanks! jdl
Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.
On Thu, Mar 15, 2018 at 1:54 PM, Damjan Marion
wrote:
>
> Should be fixed now, issue was happening when VPP was allocating buffer
> memory from 4K pages (running as non-root).
>
Damjan,
It has gotten better, but I still see these:
==
PAPI Message parsing Test Case
==
New compound type with array
ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-Kl0Zr3 ]
15:09:04,318 [Errno 17] File exists
Add new types
ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-Kl0Zr3 ]
Add new types 2 OK
15:09:05,997 [Errno 17] File exists
Add new message object
ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-Kl0Zr3 ]
15:09:06,908 [Errno 17] File exists
New message with array
ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-Kl0Zr3 ]
Argument nameOK
VLA with aribtrary length field placementOK
15:09:09,451 [Errno 17] File exists
Message to byte encoding
ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-Kl0Zr3 ]
15:09:10,370 [Errno 17] File exists
Nested array type
ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-Kl0Zr3 ]
Old style VLA array OK
15:09:12,125 [Errno 17] File exists
Old VLA compound type
ERROR [ temp dir used by test case:
/tmp/vpp-unittest-TestPAPIMessageParsing-Kl0Zr3 ]
MPLS IPv4 Multicast Tail
ERROR [ temp dir used by test case: /tmp/vpp-unittest-TestMPLS-bWDeO0 ]
Later, the output also has these:
==
ERROR: New compound type with array
--
Traceback (most recent call last):
File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line
281, in test_add_new_compound_type_with_array
msglist.add_type(p[0], p[1:])
File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 590, in add_type
typeonly=True)
File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: vl_api_ip4_fib_counter_t
==
ERROR: Add new types
--
Traceback (most recent call last):
File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line
167, in test_add_new_types
msglist.add_type(p[0], p[1:])
File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 590, in add_type
typeonly=True)
File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: vl_api_ip4_fib_counter_t
==
ERROR: Add new message object
--
Traceback (most recent call last):
File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line 71,
in test_adding_new_message_object
msgdef = msglist.add_message(p[0], p[1:])
File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: show_version
==
ERROR: New message with array
--
Traceback (most recent call last):
File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line 87,
in test_adding_new_message_object_with_array
msglist.add_message(p[0], p[1:])
File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: ip_address_details
==
ERROR: Message to byte encoding
--
Traceback (most recent call last):
File "/home/jdl/workspace/tnsr-pkgs/work/vpp/test/test_papi.py", line 95,
in test_message_to_bytes
msgdef = msglist.add_message(p[0], p[1:])
File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: show_version
==
ERROR: Nested array type
---
Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.
On Thu, Mar 15, 2018 at 4:45 PM, Dave Barach wrote: > +1. Definitely try “make test” as root, and let folks know how it goes… > > > > *From:* vpp-dev@lists.fd.io *On Behalf Of *Damjan > Marion > *Sent:* Thursday, March 15, 2018 5:24 PM > *To:* vpp-dev@lists.fd.io > *Cc:* vpp-dev@lists.fd.io > *Subject:* Re: [vpp-dev] make TEST=test_ip6 test failing on multiple > machines, when NOT run as root. > > > > > > OK, this doesn't look like related to my issue. does it work with sudo? > So, yes. Even sudone, these remaining errors persist. Not sure what is at work here yet. jdl
Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.
On Fri, Mar 16, 2018 at 3:33 AM, Klement Sekera wrote:
> This looks kinda like you have old papi installed somewhere.
>
> Please try `make test-wipe` and let me know how it goes.
>
> Thanks,
> Klement
These are clean build of top-of-tree. The 'make test-wipe' has no effect.
I think the problem is that it doesn't quit at the first error, and tries to
reopen one of the output files or directories a second time, not realizing
it is already there.
In one of the complaint directories, the stderr file contains this message:
$ less /tmp/vpp-unittest-TestPAPIMessageParsing-P8q8OK/vpp_stderr.txt
load_one_plugin:184: Loaded plugin: tlsmbedtls_plugin.so (mbedtls based TLS
Engine)
load_one_plugin:184: Loaded plugin: tlsopenssl_plugin.so (openssl based TLS
Engine)
work/vpp/build-root/install-vpp-native/vpp/bin/vpp[19872]:
unix_physmem_region_alloc:172: physmem page for region 'buffers' allocated
on the wrong numa node (requested 0 actual 4294967294)
In the log.txt we find:
10:12:52,305 --- setUp() for
TestPAPIMessageParsing.test_add_new_compound_type_with_array( New compound
type with array ) called ---
10:12:52,305 Starting sleep for 0.1s (during setUp)
10:12:52,405 Finished sleep (during setUp) - slept 0.100102901459s (wanted
0.1s)
10:12:52,405 CLI: clear trace
10:12:53,132 --- addError()
TestPAPIMessageParsing.test_add_new_compound_type_with_array( New compound
type with array ) called, err is (,
ValueError(u'Duplicate message name: vl_api_ip4_fib_counter_t',),
)
10:12:53,133 formatted exception is:
Traceback (most recent call last):
File "/usr/lib64/python2.7/unittest/case.py", line 369, in run
testMethod()
File "work/vpp/test/test_papi.py", line 281, in
test_add_new_compound_type_with_array
msglist.add_type(p[0], p[1:])
File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 590, in add_type
typeonly=True)
File "build/bdist.linux-x86_64/egg/vpp_papi.py", line 545, in add_message
raise ValueError('Duplicate message name: ' + name)
ValueError: Duplicate message name: vl_api_ip4_fib_counter_t
10:12:53,133 creating a link to the failed test
10:12:53,133 os.symlink(/tmp/vpp-unittest-TestPAPIMessageParsing-P8q8OK,
/tmp/vpp-failed-unittests//vpp-unittest-TestPAPIMessageParsing-P8q8OK-FAILED)
10:12:53,133 --- tearDown() for
TestPAPIMessageParsing.test_add_new_compound_type_with_array( New compound
type with array ) called ---
10:12:53,134 CLI: show trace
HTH,
jdl
Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.
On Mon, Mar 19, 2018 at 10:40 AM, Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) wrote: > Can you please provide instructions to reproduce? > > I checked out latest master > I think we are not communicating. I checkout any top of tree commit over the past, oh three weeks or so, and it fails. > commit 2bc940272ec75d1094326eafb4a3fa2c614e3a7b > Author: Neale Ranns > Date: Sun Feb 25 12:27:18 2018 -0800 > > Scapy upgrade to 2.4.0.rc5 > > - many of the patches fd.io applies in test/patches/2.3.3 are now > upstreamed in 2.4 > - 2.4 adds support for IGMPv3 which is my main motivation for the > upgrade > > Change-Id: If2c0a524e3cba320b4a5d8cd07817c6ea2bf0c5a > Signed-off-by: Neale Ranns > These tests: > And run both > > make test TEST=test_ip6 > make test-debug TEST=test_ip6 are not the problem. jdl
Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.
On Mon, Mar 19, 2018 at 10:55 AM, Burt Silverman wrote: > I believe the physmem/numa error is just to throw us off -- a code bug but > an innocuous one at least for non NUMA systems; Damjan would know more. > > Jon, I like your idea about it not quitting on the first error. And I > guess the "File Exists" error is also just something that happens after the > "real" error. Roughly speaking, but maybe Klement can give us a more > accurate statement about that. > > Burt > But that's just it. Those tests go red-fail, then the whole local "make test" fails, so I have no real way of knowing when I submit a gerrit review if it is my problem or not before I do so. jdl
Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.
On Mon, Mar 19, 2018 at 5:23 PM, Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) wrote: > Hi Jon, > > > Just to confirm - what's your environment? > > Centos 7.4 jdl@bcc-1 $ uname -a Linux bcc-1 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux HTH, jdl
Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.
On Tue, Mar 20, 2018 at 6:30 AM, Ole Troan wrote: > > I debugged this a bit further and it seems that sometimes when hopping > branches, the json files corresponding to APIs are not regenerated properly. > > What happens in vpp-papi is that if it founds a duplicate, it checks > whether it's the same message and if so, there is no exception raised. > > But I saw that after Neale's recent update to vnet_combined_counter_t, > in stats.api.json, the message was defined as before, while in > interface.api.json, it was updated. > > Doing a > > > > git clean -d -f -x . > > and rebuilding everything fixes the issue > > > > Let me know if you see a different issue... > Ooo, I see... So, yeah, I have to hop between a local branch and the upstream master, so I may be being victimized by this problem. I've been doing a "make wipe" or "wipe-release" and forgot about the industrial 'git clean'. Drat. I'll give that a run... Ah right. So I guess this is caused by the lack of dependency tracking from > the vppapigen compiler, that is for included files in .apis. > I can modify vppapigen to add a new -M to output dependencies like what a > C compiler does. > Anyone has good ideas for how to add this into the GNU autotools stuff? > I can't believe I've read a sentence with the words "good ideas" and "GNU autotools" in it. :-) > Cheers, > Ole Cheers, jdl
Re: [vpp-dev] make TEST=test_ip6 test failing on multiple machines, when NOT run as root.
On Tue, Mar 20, 2018 at 9:44 AM, Jon Loeliger wrote: > On Tue, Mar 20, 2018 at 6:30 AM, Ole Troan wrote: > >> >> > >> > git clean -d -f -x . >> > and rebuilding everything fixes the issue >> > >> > Let me know if you see a different issue... >> > > Ooo, I see... So, yeah, I have to hop between a local branch and the > upstream master, > so I may be being victimized by this problem. I've been doing a "make > wipe" or "wipe-release" > and forgot about the industrial 'git clean'. Drat. I'll give that a > run... > And for the record, I have rebuilt at this commit: commit 6f4a6be8f222dd8caa94d19a7e4d87cb864ba7f4 Author: Neale Ranns Date: Fri Mar 16 16:26:21 2018 -0700 Interface Unicast, Multicast and Broadcast stats on the API Change-Id: I7c75da358aff1bd0216a602a49f2909cef5d920d Signed-off-by: Neale Ranns In a"git clean -fxd" directory and still see the PAPI "make test" errors. jdl
[vpp-dev] Some DS Lite Questions
Matus, et al, I am looking at the DS Lite CLI and API calls. I have a few questions. Is there no way to remove either the B4 or AFTR tunnel endpoint once it is set? It seems there is maybe a missing dslite_pool_addr_dump API call? Is there a future for the ip4_addr fields on the "set B4" and "set AFTR" API calls? The CLI doesn't set them. And while the Python API appears to be able to set them, they are not used in any implementation anywhere. Finally, is there any plan to make any of the NAT parameters (snat_config()) available via an API call? I'm specifically thinking about the "deterministic" and "is_ce" flags. It seems these, and perhaps others, could be set at API handling time if we all agreed it mean flushing the current NAT state and re-initializing things? Thanks, jdl
