[quagga-dev 3307] Re: zebra rib work queue

Paul Jakma paul at clubi.ie
Mon Apr 25 19:54:00 BST 2005

On Mon, 25 Apr 2005, Andrew J. Schorr wrote:

> Are you saying that you believe the failing (EAGAIN) writev system 
> call is wasting a lot of time?

Before your buffer changes - the blocking of bgpd on zebra caused 
/huge/ lag. With your changes, its far *far* better (and I'd even 
noticed before bgpd was behaving itself quite nicely, i just never 
put two + two together, sorry).

I'm /hoping/ that with the rib queue, with zebra reading zclient 
socket as fast as it can and hence bgpd writing as fast as it can, it 
will be even better. I have to test further. I dont believe though 
that a failed inline flush (EAGAIN, defer to thread write) could have 
that much effect. However, there is an initial stall, even with your 
changes, which would be nice to get rid of, not sure what it is yet.

I need to test to see whether the rib-queue changes add anything to 
the blocking changes.

> If this is really a problem, then there could be some ways of 
> changing this behavior.  One possibility is to set a minimum write 
> size to eliminate the series of small write calls that occur before 
> the socket buffer fills up.  Another possibility is to use timers 
> to try flushing instead of trying to flush each time buffer_write 
> is called.  I have implemented both of these strategies in my own 
> code, so I know it is possible, but it certainly increases 
> complexity...


Let me test buffering alone against buffering + rib queue..

My gut feeling is that they're complimentary. The queueing can allow 
what is now a long long thread of buffer preparation + flush + 
preparation, etc, to be split up.

Just now I need to split up bgpd to prove that point. The reading 
side queueing isnt as important now with client-side buffering.

I'll test and see.

> That seems like it could make sense.  I would be more comfortable
> with that because it would be restricted to known hot spots in the code...

Aye, they can be audited. I'll try get that together.


Prefix                :        -59

at least one bad MTYPE user..

It'd be useful for specific mtypes though - maybe. I'll find out :)

Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Experience varies directly with equipment ruined.

More information about the Quagga-dev mailing list