[quagga-dev 12559] Re: [PATCH v3 00/22] VRF support in quagga
sharpd at cumulusnetworks.com
Fri May 29 14:45:38 BST 2015
To Continue with Paul's point. I believe that there are allot of
performance gains to be had by running perf and looking at the output to
see where our algorithmic/data structure choices are wrong and fixing those
first before diving in and rewriting for multi-threaded code.
On Fri, May 29, 2015 at 9:41 AM, Paul Jakma <paul at jakma.org> wrote:
> On Fri, 29 May 2015, Michael H Lambert wrote:
> I just want to make sure I've been following this email chain correctly.
>> It seems that there is at least some consensus for a single daemon for all
>> VRFs. Does this preclude a thread per VRF within the daemon?
> generally, no.
> For existing Quagga libzebra daemons, probably that's going to be such a
> long effort to achieve, that there will be significant risks as to whether
> it can succeed. Multi-daemon would be much easier I suspect (it's not like
> VRF instances need to share any data, so there's no memory/performance
> trade-off issues that would generally give threads any benefit over
> multi-process - unlike multi-processing bgpd).
> Paul Jakma paul at jakma.org @pjakma Key ID: 64A2FF6A
> You can fool all the people all of the time if the advertising is right
> and the budget is big enough.
> -- Joseph E. Levine
> Quagga-dev mailing list
> Quagga-dev at lists.quagga.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Quagga-dev