Re: [Bloat] lwn.net's tcp small queues vs wifi aggregation solved

[Michael Richardson <mcr@sandelman.ca>]

Jonathan Morton <chromatix99@gmail.com> wrote:
    >> Your original note was looking for a way
    >> for finding out if the probability of seeing more data in the next 10us
    >> was sufficiently large to delay "a teeny bit" so that would be the
    >> problem statement.

    > I would instead frame the problem as "how can we get hardware to
    > incorporate extra packets, which arrive between the request and grant
    > phases of the MAC, into the same TXOP?"  Then we no longer need to
    > think probabilistically, or induce unnecessary delay in the case that
    > no further packets arrive.

I've never looked at the ring/buffer/descriptor structure of the ath9k, but
with most ethernet devices, they would just continue reading descriptors
until it was empty.   Is there some reason that something similar can not
occur?

Or is the problem at a higher level?
Or is that we don't want to enqueue packets so early, because it's a source
of bloat?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [