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

Quentin Young qlyoung at cumulusnetworks.com
Wed Nov 1 16:03:58 EDT 2017


Yes, this on my to-do list.

On Nov 1, 2017 4:02 PM, "Donald Sharp" <sharpd at cumulusnetworks.com> wrote:

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=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFW
e5J8PTfkrzVSo&r=yetdj-aXQpuqTCJGs-93hOpK3740MIRXowfUNLByeos&m=
39gFpBpfaetXLzjjR76DUE8_Ju4vRUt7sYRtCAk5gY8&s=1AXFF8MKa7HBFGMglzbyhXAP3TjDeW
h9w9xcNn4puxQ&e=
>     >     >
>     >
>     >
>
>

_______________________________________________
dev mailing list
dev at lists.frrouting.org
https://lists.frrouting.org/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20171101/173a0b75/attachment.html>


More information about the dev mailing list