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" <chris_l...@comcast.com>
Date: Thursday, 3 August 2017 at 14:11
To: "Neale Ranns (nranns)" <nra...@cisco.com>, "vpp-dev@lists.fd.io"
<vpp-dev@lists.fd.io>, "csit-...@lists.fd.io" <csit-...@lists.fd.io>,
"honeycomb-...@lists.fd.io" <honeycomb-...@lists.fd.io>
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: csit-dev-boun...@lists.fd.io [mailto:csit-dev-boun...@lists.fd.io]
On
> Behalf Of Neale Ranns (nranns)
> Sent: Thursday, August 3, 2017 3:57
> To: vpp-dev@lists.fd.io; csit-...@lists.fd.io; honeycomb-...@lists.fd.io
> 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
> csit-...@lists.fd.io
> https://lists.fd.io/mailman/listinfo/csit-dev
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
