Re: [Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps?

["John W. Linville" <linville@tuxdriver.com>]

On Wed, Mar 16, 2011 at 12:01:41AM +0200, Jonathan Morton wrote:
> 
> On 15 Mar, 2011, at 10:51 pm, John W. Linville wrote:
> 
> >>> If you don't throttle _both_
> >>> the _enqueue_ and the _dequeue_, then you could be keeping a nice,
> >>> near-empty tx queue on the host and still have a long, bloated queue
> >>> building at the device.
> >> 
> >> Don't devices at least let you query how full their queue is?
> > 
> > I suppose it depends on what you mean?  Presumably drivers know that,
> > or at least can figure it out.  The accuracy of that might depend on
> > the exact mechanism, how often the tx rings are replinished, etc.
> > 
> > However, I'm not aware of any API that would let something in the
> > stack (e.g. a qdisc) query the device driver for the current device
> > queue depth.  At least, I don't think Linux has one -- do other
> > kernels/stacks provide that?
> 
> I get the impression that eBDP is supposed to work relatively
> close to the device driver, rather than in the core network stack.
> As such it's not a qdisc, but instead manages a parameter used by
> a well-behaved device driver.  (The number of well-behaved device
> drivers appears to be small at present.)

If you count mac80211 as part of the "driver", what is between the
qdisc and the "driver"?  I wouldn't consider the bottom of the qdisc
as the core of the stack.

I would really like to see eBDP (or ALT or A* or something similar)
implemented in a single place if possible, rather than reimplemented
(perhaps poorly) in a series of drivers.  I know Felix and others think
that 802.11n aggregation makes that impossible, but I'm inclined to
think that is still at least partly from a bias towards throughput
at the expense of latency -- I could be wrong! :-)

Someone suggested that perhaps eBDP/ALT/A*/whatever could be
implemented as a library for drivers to call -- that still requires
individual driver hacking, but maybe it is reasonable?  I'd have to
see the code.

> So there's a queue in the qdisc, and there's a queue in the hardware,
> and eBDP tries to make the latter smaller when possible, allowing the
> former (which is potentially much more intelligent) to do more work.

So that is a possible implementation -- limit the tx queue length
in the driver, similar to manually doing 'ethtool -G'.  But on the
other hand, you can achieve a similar effect by throttling the input
to the driver/hardware tx queue no matter how many hardware tx slots
are physically allowed.

<snip>

> Knowing the occupancy of the hardware buffer is useful if the
> size of the buffer cannot be changed, because it is then possible
> to simply decline to fill the buffer more than a certain amount.
> If you can also assume that packets are sent in order of submission,
> or by some other easy rule, then you can also infer the time that
> the oldest packet has spent there, and use it to tune the future
> occupancy limit even if you can't cancel the old packet.

Yes, I think we agree.

> Cancelling old packets is potentially desirable because it allows
> TCPs and applications to retransmit (which they will do anyway)
> without fear of exacerbating a wireless congestion collapse.  I do
> appreciate that not all hardware will support this, however, and it
> should be totally unnecessary for wired links.

As other said later in the queue, I think trying to reach down into the
driver/hardware to cancel an already posted packet would be difficult,
slow, etc.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.