[dev] A question about the # of vrf per router or switch can support by FRR?

Donald Sharp sharpd at cumulusnetworks.com
Wed Nov 1 16:02:36 EDT 2017


Jay -

Conversion of lists over for well used data structures would be
greatly appreciated and in general is on the list of things that need
to be done..  I do know the bgp peers have both a list and a hash( for
o(1) lookup) that was put in about 1.5 years ago and showed some great
improvements in scaling because of not having to traverse a list for
peer lookup.

donald

On Wed, Nov 1, 2017 at 1:28 PM, Jay Chen <jchen1 at paloaltonetworks.com> wrote:
> Donald,
>
> Cool, indeed it is using an rb already. I was looking at BGP that uses a lot of list for group, peer etc. My code is indeed old too. I am going to update it and try the newest one.
>
> Thanks,
> Jay
>
> On 11/1/17, 10:04 AM, "Donald Sharp" <sharpd at cumulusnetworks.com> wrote:
>
>     Jay -
>
>     What version of the code are you looking at?  VRF's use RB trees:
>
>     static __inline int vrf_id_compare(const struct vrf *, const struct vrf *);
>     static __inline int vrf_name_compare(const struct vrf *, const struct vrf *);
>
>     RB_GENERATE(vrf_id_head, vrf, id_entry, vrf_id_compare);
>     RB_GENERATE(vrf_name_head, vrf, name_entry, vrf_name_compare);
>
>     struct vrf_id_head vrfs_by_id = RB_INITIALIZER(&vrfs_by_id);
>     struct vrf_name_head vrfs_by_name = RB_INITIALIZER(&vrfs_by_name);
>
>     So do interfaces now as well:
>
>     static int if_cmp_func(const struct interface *, const struct interface *);
>     static int if_cmp_index_func(const struct interface *ifp1,
>                                  const struct interface *ifp2);
>     RB_GENERATE(if_name_head, interface, name_entry, if_cmp_func);
>     RB_GENERATE(if_index_head, interface, index_entry, if_cmp_index_func);
>
>     We've been trying to intelligently move code over and may have missed
>     something.
>
>     donald
>
>     On Wed, Nov 1, 2017 at 1:00 PM, Jay Chen <jchen1 at paloaltonetworks.com> wrote:
>     > Hi Donald,
>     >
>     > Great, thank you for the clarification.
>     > I noticed that FRR using linked list in both BGP, and OSPF where a red black tree may be better in turn of Big-O. Two questions below:
>     >
>     > A. Is it worth to implement a redblack tree?
>     > B. Any effort is already in progress in implementing an embedded redblack tree and use it in some key places?
>     >
>     > If the answer to A is yes, B is no. I can volunteer to implement a light weight redblack tree (embedded usage), and patch it (I have done a couple of time for another two router companies). I just thought it might be better than search a long linked list.
>     >
>     > Thanks,
>     > Jay
>     >
>     >
>     >
>     > On 11/1/17, 6:15 AM, "Donald Sharp" <sharpd at cumulusnetworks.com> wrote:
>     >
>     >     Jay -
>     >
>     >     There is no hard limit.  Having said that I am not aware of serious
>     >     testing beyond like 64 vrf's.  But that is allot of vrf's to have to
>     >     maintain at one time..
>     >
>     >     donald
>     >
>     >     On Tue, Oct 31, 2017 at 10:39 PM, Jay Chen <jchen1 at paloaltonetworks.com> wrote:
>     >     > Is there a limit that the # of vrf can support for a single switch or router
>     >     > by using FRR?
>     >     >
>     >     >
>     >     >
>     >     > Thanks,
>     >     >
>     >     > Jay
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > dev mailing list
>     >     > dev at lists.frrouting.org
>     >     > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.frrouting.org_listinfo_dev&d=DwIBaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=39gFpBpfaetXLzjjR76DUE8_Ju4vRUt7sYRtCAk5gY8&s=1AXFF8MKa7HBFGMglzbyhXAP3TjDeWh9w9xcNn4puxQ&e=
>     >     >
>     >
>     >
>
>



More information about the dev mailing list