>> 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?
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?
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
