lkml.org 
[lkml]   [2000]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH/RFC] (long) network interface changes


On Mon, 18 Sep 2000, David S. Miller wrote:

> Date: Mon, 18 Sep 2000 21:31:17 -0400 (EDT)
> From: jamal <hadi@cyberus.ca>
>
> My testing with the included scheme (#ifdef RAND_LIE) indicates
> that fairness infact goes up; however, the overall throughput when
> only one interface is utilizing the system goes down under heavy to
> moderate congestion. I am including it here as a way to highlight
> the problem. I think there could be better ways to do this. Code
> is included and can be turned on by defining RAND_LIE in dev.c
>
> Why not keep a counter per-device.
>
> This counter is an atomic_t and initially zero.
>
> When a packet is given to netif_rx and becomes part of the backlog
> this counter is incremented.
>
> When a packet leaves the backlog, this same counter is decremented.
>
> You can use this counter to approximate queue percentages per-device
> and use this to decide who gets the little white lies.
> Questions are whether this will be cheaper than calling net_random()

What you describe is _exactly_ one of the schemes we discussed.
Maintaining that device state info is cheap.
You will need to consider the arrival rates, so you would sample the
(same way we do in the patch) and maintain the average queue-contrib,
per-device. The elegance required is in deciding the per-device quotas
dynamically incase some devices is not using up its quota.
Another scheme would be to do per-device queues ... soft-irq does a RR

We need to experiment, show some numbers. That code exposes the problem
and gives a less than optimal solution since no per-device state is
maintained.

> occaisionally and actually more interesting would be a scheme which
> did not hurt the single interface case. :-(
>

The dynamic sharing of the per-device quoatas would help.

cheers,
jamal


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [from the cache]
©2003-2011 Jasper Spaans