> Computing the buffering in bytes is better than in packets; but since on > wireless multicast/broadcast is transmitted at a radically different > rate than other packets, I expect something based on time is really the > long term solution; and only the driver has any idea how long a packet > of a given flavour will likely take to transmit. The generalization of BQL would be to set the queue limit in terms of a cost function implemented by the driver. The cost function would most likely be an estimate of time to transmit a packet. So C(P) could represent cost of a packet, sum(C(P) for P queued) is aggregate cost of queue packets, and queue limit is the maximum cost sum. For wired Ethernet, number of bytes in packet might be a reasonable function (although framing cost could be included, but I'm not sure that would make a material difference). For wireless, maybe the function could be more complex possibly taking multicast, previous history of transmission times, or other arbitrary characteristics of the packet into account... I can post a new patch with this generalization if this is interesting. Tom -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
