Hi Chris, Short answer; I plan to flush. Long answer; entries in a FIB table are owned by a ‘source’, external sources are the API and CLI, but there are also internal ones like LISP and DHCP. I plan to extend this sourcing concept to the FIB table. So, when the API issues table_create it will hold one lock on the table. Other sources may also lock the same table. When the API issues table_delete its last lock will go and I will flush all the entries that the API also sources. If the API held the last lock from all the sources then the table is then completely deleted – otherwise the table will remain, owned by and containing entries from, e.g. LISP.
Other details I should mention: - It will be an error to bind an interface, or add a route to/via, etc, a table ID that does not exist. The IPv[46] default table (#0) will be the exception, as it will always exist. The MPLS default table will need to be explicitly created. - When ip[46] table X is created via the API, this will instantiate both a unicast and multicast FIB. However, VPP internal apps can still create unicast and multicast FIB individually. Regards, neale -----Original Message----- From: "Luke, Chris" <[email protected]> Date: Thursday, 3 August 2017 at 14:11 To: "Neale Ranns (nranns)" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: RE: API Change Proposal: explicit FIB table create and delete +1 Do you intend to block fib deletion until nothing uses it, or flush those things at deletion? Chris. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Neale Ranns (nranns) > Sent: Thursday, August 3, 2017 3:57 > To: [email protected]; [email protected]; [email protected] > Subject: [csit-dev] API Change Proposal: explicit FIB table create and delete > > > Dear All, > > I would like to propose the addition of a new API to explicitly create and > delete FIB tables. At present the only way to create FIB tables (for e.g. VRFs) > is to: > 1) Bind an interface to a new table index; ‘set int ip table Eth0 <NEW > TABLE_ID> > 2) Add a route in a new table and set the create_vrf_if_needed flag > > With the addition of an explicit create we have the possibility to set per-table > properties, like the flow-hash and (potentially) the mtrie stride (to favour > memory over performance for small VRFs). With an explicit delete VPP is > aware when it is safe to delete the table. > > An explicit API makes the management of FIB tables by the agent/client the > same as managing any other table resource, like Bridge-Domains or classify > tables. > > Regards, > neale > > _______________________________________________ > csit-dev mailing list > [email protected] > https://lists.fd.io/mailman/listinfo/csit-dev _______________________________________________ vpp-dev mailing list [email protected] https://lists.fd.io/mailman/listinfo/vpp-dev
