Nicolas,
Thanks for fixing these really quick - with super fast turn around time!
I'm glad to see this set of patches finally makes it in, and I'm sure
there are
a lot of users in the community who share the same feeling since it
paves the roads
for many new use cases. I'm also sure there are many users who were
waiting for this to
happen to get their hands dirty implementing VRF-aware protocol daemons.
The "thanks" goes to all who contributed by code, discussion, and
raising concerns!
Many Thanks,
Jafar
On 6/2/2015 10:57 AM, Nicolas Dichtel wrote:
Hi,
here is the end of the VRF support series (the last three patches that were
not applied).
v3 -> v4:
- send only the last three patches (was 19/22 to 22/22 in the v3)
- rebase the series on HEAD
- fix FreeBSD compilation
v2 -> v3:
- rebase the series on HEAD
- fix setns() syscall with old toolchains
- add patch 01/22 to cleanup babeld code (also submitted separately)
v1 -> v2:
(1) Make "struct vrf" internal within lib/vrf
The "struct vrf" gets invisible from outside of the vrf.c. Accordingly, some
new utilities are provided to access the
VRF-ID/interface-list/user-data-pointer.
And hence, some previous wrapper in zebra are removed now.
The global VRF table (it was previously a vector) now also becomes invisible
from outside. A new utility "VRF iterator" is provided to scan the VRF
table.
(2) Release the hard-coded up-limitation of the number of VRFs
The VRF_MAX is removed. The type of "vrf_id_t" is changed from
"u_int32_t" to "u_int16_t". So now there's a natural up-limitation 65535 for
the VRF ID value.
The previous VRF vector is changed to a table (in type of
"struct route_table").
(3) Make interface APIs backward compatible
New interface APIs are defined to access the interfaces in a specified
VRF, while the old ones are kept unchanged and serving for only the
default VRF. Thus, the no modification is need in all protocol daemons
where an interface API is called. The new APIs are presently used only
by zebra.
(4) Remove the flag arrays defined with a hard-coded VRF_MAX
Many flags are used to indicate whether a client interests some
information in some VRF or not (called registering flags). Zebra is
using these flags to block the unnecessary API messages sent to
clients.
Previously these flags were defined as arrays in length of VRF_MAX. Now
a new utility "vrf_bitmap_t" is provided to create/free/set/unset/check
these flags.
Comments are welcome.
Regards,
Nicolas
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
