headers
Chris Hall | 1 Dec 2009 01:58

[quagga-dev 7446] Re: (no subject)

Stephen Hemminger wrote (on 30-Nov-2009 at 19:44)
...
> Unfortunately, pthread mutex and locking primitives are slow. That is 
> why almost all the databases end up rolling their own. Part of the 
> problem is the glibc clash between being portable and being fast.
> 
> What is the proposed design for using threads? I am concerned that if 
> it just changes the bottleneck from being a single thread, to having a 
> single lock there will be little performance gain.

The objective is to separate out:

   1. "Routeing Engine" -- managing the RIB(s) and calculating updates.

   2. "BGP Engine" -- Finite State Machine and all BGP session I/O

   3. CLI -- all I/O

in order to:

   1. ensure that BGP sessions are kept alive, even when the
      Routeing Engine gets very busy.

   2. ensure that the CLI is responsive, even when the Routeing Engine
      gets very busy.  (Though when a command is actually executed, it
      will need the attention of the Routeing Engine).

The problem is that, especially when running many hundreds of Route Server
peers, bgpd has so much work to do dealing with RIB(s) etc. that it drops
the ball on BGP sessions.  That is, BGP sessions hit holdtime expired
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Hall | 1 Dec 2009 02:05

[quagga-dev 7447] Re: (no subject)

Michael Lambert wrote (on 30-Nov-2009 at 22:52):
> What would your thoughts be on making each view in bgpd its own thread?
> Could this improve performance as a route server?

A thread for each Route Server client would certainly allow it to use all
the processors at its disposal when updates arrive.  Since bgpd is
completely CPU bound when running as Route Server for 200-300 clients, I
think that would be a Good Thing.

However, to start with I shall be happy to get enough threads running to
eliminate the current problems with BGP sessions dropping, and with the CLI
stopping responding, when the thing gets busy.

Chris
Permalink | Reply | 0 comments |
headers
Adrian Chadd | 1 Dec 2009 03:02
Picon

[quagga-dev 7448] Re: (no subject)

2009/12/1 Chris Hall <chris.hall.list <at> highwayman.com>:
> Michael Lambert wrote (on 30-Nov-2009 at 22:52):
>> What would your thoughts be on making each view in bgpd its own thread?
>> Could this improve performance as a route server?
>
> A thread for each Route Server client would certainly allow it to use all
> the processors at its disposal when updates arrive.  Since bgpd is
> completely CPU bound when running as Route Server for 200-300 clients, I
> think that would be a Good Thing.
>
> However, to start with I shall be happy to get enough threads running to
> eliminate the current problems with BGP sessions dropping, and with the CLI
> stopping responding, when the thing gets busy.

I'd suggest looking at mapping out the various tasks inside bgpd and
see what relies on what. Blindly creating threads without knowing how
they interact is going to lead down a path of fail. :)

My proposal for this (which is why it was so expensive and time
consuming) was to spend a lot more time teasing apart the internals
into some semblence of a documented mess; then massage module
boundaries into something useful for parallelism. I couldn't say off
hand whether parallelism was best at one thread per peer; or one
"general" thread and then one (or more) "RIB" threads per view as a
starting point, etc, etc. Too much of the code relies on changes
happening atomically to make any changes easy -and- stable. :)

IMHO, 2c,

Adrian
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Ward | 1 Dec 2009 14:24
Picon

[quagga-dev 7449] Status of Patches?

On 11/19/2009 04:47 PM, Joakim Tjernlund wrote:
> Cool, patches are accumulating. Anyone know were Paul is?
>   Jocke
>    
Can I also very politely ask what the status is of reviewing and/or 
checking in the patches recently sent to the quagga-dev list?

Thanks,

David
Permalink | Reply | 6 comments |
headers
Denis Ovsienko | 1 Dec 2009 17:13
Picon
Favicon
Gravatar

[quagga-dev 7450] Re: Status of Patches?

>  > Cool, patches are accumulating. Anyone know were Paul is?
>  >   Jocke
>  >    
>  Can I also very politely ask what the status is of reviewing and/or 
>  checking in the patches recently sent to the quagga-dev list?

Hello to all.

Folks, I would like to review some of them. That said, let me pick some easy ones to start with.

--

-- 
    Denis Ovsienko
Permalink | Reply | 0 comments |
headers
Bartek Kania | 1 Dec 2009 18:02

[quagga-dev 7451] Re: [PATCH] ospfd: Don't use _RO when list nodes will be deleted.


On Sun, 29 Nov 2009, Bartek Kania wrote:
> On Sun, 29 Nov 2009, Joakim Tjernlund wrote:
>> Damn, I just completed some addons and was just about to send them.
>> If it isn't too much trouble, could you try with the new series I will
>> send in a few moments?
> Sure.
> Compiling right now. Will report back in a day or so, or if anything
> interresting happens.

Hi!
ospfd has been running well for two days now.
Seemingly no memory leaks (tho not checked with valgrind, only going
by memory usage shown in top) and no crashes.
All neighbors and routes show up as they should.

/B
--

-- 
* GPG-Key: http://bk.gnarf.org/mrbk.pgp

A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?
-- http://www.i-hate-computers.demon.co.uk/
Permalink | Reply | 2 comments |
headers
Joakim Tjernlund | 1 Dec 2009 18:13
Picon

[quagga-dev 7452] Re: [PATCH] ospfd: Don't use _RO when list nodes will be deleted.

Bartek Kania <mrbk <at> gnarf.org> wrote on 01/12/2009 18:02:51:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Sun, 29 Nov 2009, Bartek Kania wrote:
> > On Sun, 29 Nov 2009, Joakim Tjernlund wrote:
> >> Damn, I just completed some addons and was just about to send them.
> >> If it isn't too much trouble, could you try with the new series I will
> >> send in a few moments?
> > Sure.
> > Compiling right now. Will report back in a day or so, or if anything
> > interresting happens.
>
> Hi!
> ospfd has been running well for two days now.
> Seemingly no memory leaks (tho not checked with valgrind, only going
> by memory usage shown in top) and no crashes.
> All neighbors and routes show up as they should.

Great! BTW, do you have ant PtoP links as well?

      Jocke
Permalink | Reply | 1 comment |
headers
Bartek Kania | 1 Dec 2009 18:45

[quagga-dev 7453] Re: [PATCH] ospfd: Don't use _RO when list nodes will be deleted.


On Tue, 1 Dec 2009, Joakim Tjernlund wrote:
>> Hi!
>> ospfd has been running well for two days now.
>> Seemingly no memory leaks (tho not checked with valgrind, only going
>> by memory usage shown in top) and no crashes.
>> All neighbors and routes show up as they should.
> Great! BTW, do you have ant PtoP links as well?

Not on my test routers.
Don't vlinks count as ptp?

I have some GREs on production routers, but I don't treat them any
differently than normal interfaces so I don't know if ospfd will treat
them as ptp.

/B
--

-- 
* GPG-Key: http://bk.gnarf.org/mrbk.pgp

A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?
-- http://www.i-hate-computers.demon.co.uk/
Permalink | Reply | 0 comments |
headers
Denis Ovsienko | 1 Dec 2009 19:21
Picon
Favicon
Gravatar

[quagga-dev 7454] Re: [PATCH] ospf6d: minor lsa locking fix


> * ospf6_lsdb.c: (ospf6_new_ls_id) Unlock the current LSA when breaking
> out of the ospf6_lsdb_*_head() / ospf6_lsdb_*_next() loop early. No
> explicit unlocking is needed when all LSAs are looped through
> because ospf6_lsdb_*_next() manages everything in that case.

Committed.

--
    Denis Ovsienko
Permalink | Reply | 0 comments |
headers
paul | 1 Dec 2009 20:39

[quagga-dev 7455] Re: Status of Patches?

On Tue, 1 Dec 2009, David Ward wrote:

> Can I also very politely ask what the status is of reviewing and/or 
> checking in the patches recently sent to the quagga-dev list?

Hmm, I'm basically not around for the next 6 months I'm afraid.

regards,
--

-- 
Paul Jakma	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
Kent's Heuristic:
 	Look for it first where you'd most like to find it.
Permalink | Reply | 4 comments |

Gmane