On Wed, 2011-03-16 at 00:26 +0200, Jonathan Morton wrote: > On 16 Mar, 2011, at 12:19 am, Stephen Hemminger wrote: > > >> 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. > >> > >> 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. > > > > Have you looked at actual hardware interfaces. They usually are designed to > > be "fire and go" with little to no checking by CPU. This is intentional > > because > > of the overhead of bus and CPU access. Once packets go into the tx ring > > there > > is no choice but to send or shutdown the device. > > For a wired device that would certainly make sense. For a wireless > device some extra flexibility is plausible, even if it doesn't exist > in practice.
Back and forth synchronization between driver and device is doubleplusungood. Being able to remove a packet on the tx queue already made known to the NIC sounds like it could become a rathole. If you are lucky, you *might* have a "valid/invalid" bit in a packet descriptor that the driver could hope to set before the NIC had pulled-in a copy across the I/O bus. rick jones _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
