On Wed, Jan 17, 2001 at 06:50:57PM +0100, Andi Kleen wrote:
> On Wed, Jan 17, 2001 at 06:22:41PM +0100, Gleb Natapov wrote:
> > On Wed, Jan 17, 2001 at 05:14:38PM +0100, Andi Kleen wrote:
> > > On Wed, Jan 17, 2001 at 02:51:48PM +0100, Gleb Natapov wrote:
> > > >
> > > > You are trying to say that if I'll connect to my router via 9600 serial
> > > > line and run 'ip monitor'
> > > > there the routing daemon will not be able to feed routes to the kernel
> > > > quicker than ip monitor will
> > > > be able to read them and send output via slow serial line?! Somehow
> > > > 9600 serial line become a
> > > > bottleneck! Are you sure about that, or I misunderstood you?
> > >
> > > You misunderstood me. The kernel side doesn't do any flow control, it
> > > just drops messages when the
> > > buffers fill up. The user side does flow control by blocking or EAGAIN,
> > > e.g. you submitting new
> > > routes.
> > >
> > What user side? There are to sides: W - feeds routes to the kernel, R -
> > read netlink updates from the kernel.
>
>
> (W) is flow controlled.
>
> (R) is in a sense flow controlled too because it can only get information
> the kernel queues, but the kernel cheats a bit by dropping stuff when the
> buffer fills.
Exactly. And currently buffer fills very quickly. Alexey says that there is no
difference
between 16 and 116 messages but I disagree; if queue will be bigger, R will
have a chance to
empty it before W will run next time and adds more routes to the kernel. Less
resyncs needed.
If we can considerably enlarge queue size for free why not to do it?
>
>
> >
> > Who does flow control and how?
> >
> > W knows nothing about R it simple adds routes to the kernel with the speed
> > kernel can process them.
>
> Which is the flow control -- it gets blocked when the kernel cannot keep up.
>
>
>
> -Andi
--
Gleb.
|