On Fri, 7 Aug 2015, Jonathan Morton wrote:
On 7 Aug, 2015, at 15:22, Rich Brown <richb.hano...@gmail.com> wrote:
- At that time, the wifi driver requests packets from fq_codel until a) the
the fq_codel queues are empty, or b) the wifi frame is full. In either case,
the wifi driver sends what it has.
There’s one big flaw with this: if packets are available for multiple
destinations, fq_codel will generally give you a variety pack of packets for
each of them. But a wifi TXOP is for a single destination, so only some of
the packets would be eligible for the same aggregate frame.
So what’s needed is a way for the wifi driver to tell the queue that it wants
packets for the *same* destination as it’s transmitting to.
how about when the queue hands packets to the wifi driver, it hands all packets
to that same destination, no matter where they are in the queue (up to a max
size, and the queue may adjust that max size within a range for fairness)
- Once the transmit opportunity has come around, it's a matter of
microseconds (I assume) to pull in a wifi frame's worth of packets from
fq_codel
This is hard to guarantee in software in a general-purpose OS.
you really want to have the pckets assembled and ready to go rather than trying
to pull them at that point.
But what happens right now is that the queue hands packets to the wifi driver,
then the wifi driver has it's own queues that it uses to gather the packets for
each destination.
If we can find a way to make it reasonable to short-circuit the wifi driver
queues by making it efficient to work from the main network queues, we can work
to eliminate the second layer of queues.
so thinking about the requierments from the driver point of view
It needs to be able to pull a chunk of data to transmit (multple packets), it
isn't going to know very much ahead of time what speed it's going to use to talk
to this destination, and this is going to drastically affect how long it takes
to transmit the bits. so when it grabs data from the queue, it needs to feed
back to the queue the transmit time for those bits, and the queue uses that
instead of the count of bits to determine fairness.
The queue will be deciding fairness based on whois behind in their 'fair share'
of transmit time. So the wifi driver isn't going to know when it asks for the
net chunk of data to transmit, who it will be going to. So it will need to get
the destination, see the speed to use to that destination, pass the speed to
a calculation for how much data to send, then grab that much data (rounded to a
packet boundry)
Is this sort of logic useful anywhere other than in wifi?
Wifi is the only place I know of where the transmit bit rate is going to vary
depending on the next hop address.
I know that the inter-packet gap defined for ethernet can amount to a large
percentage of bandwidth at high speeds. Can multiple packets to the same
destination be combined with a smaller gap between packets? (the gap timing was
based on the speed-of-light time needed for the entire shared bus to quiece back
in the 10mb half-duplex hub days). If so, then there's value in bundling packets
to the same destination together.
If this sort of logic is not useful anywhere other than in wifi, maby the right
answer is to have a way of short-circuiting the main OS queues and have a wifi
specific queue that can directly look at the per-client speeds/etc when deciding
who goes next and how much to dispatch?
David Lang
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
