-----Original Message----- From: Jon Loeliger <j...@netgate.com> Date: Tuesday, 29 August 2017 at 21:23 To: "Neale Ranns (nranns)" <nra...@cisco.com> Cc: vpp-dev <vpp-dev@lists.fd.io> Subject: 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? That should be the client’s assigned table-ID (not VPP’s FIB index). There should be a table-Id in the vl_api_fib_path_t too, which is relevant for recursive paths (it would be the next_hop_table_id when the route was added) Soooo, 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? Yes, yes and yes, And this dump/details response will be in dense-index order, right? One would reasonably expect so. For v6 it would appear to be the case, but, reading code in: vl_api_ip_fib_dump_t_handler() fib_entry_cmp_for_sort() fib_entry_cmp() it does not compare the route’s FIB-index. So I expect the details to come prefix sorted. We might want to change that loop code in the v4 dump handler to do one table at a time, like v6 does. /neale jdl _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev