Yes, this on my to-do list. On Nov 1, 2017 4:02 PM, "Donald Sharp" <sharpd@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@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@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@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@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@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@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@lists.frrouting.org https://lists.frrouting.org/listinfo/dev