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