On Tue, 2011-03-15 at 23:52 +0100, Eric Dumazet wrote: > Le mardi 15 mars 2011 à 15:36 -0700, Rick Jones a écrit : > > 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. > > There are two different use cases : > > 1) Wired devices, where we want to push more 10+ Gbps, so we can assume > a posted skb is transmitted immediately. Even a basic qdisc can be a > performance bottleneck. Set TX ring size to 256 or 1024+ buffers to > avoid taking too many interrupts. > > 2) wireless, were typical bandwidth is small enough we can afford a > qdisc with a trafic shaper, good flow classification, whatever limit on > "maximum waiting time in qdisc queue or drop it" and a very small queue > on hardware ?
So, I've no worries that my home system has plenty of "oomph" for fancy things when speaking over wireless, but that is a desktop. How much "oomph" relative to wireless bandwidth exists in hand-helds? Right now I think of "wireless" as being, in essence, 100BTto1GbE (wild handwaving) - do the CPUs in handhelds possess that much more "oomph" than "regular" systems did when 100BT or 1GbE first appeared? rick jones > > In both cases, we dont need to "cancel" a packet post to NIC hardware, > or we need special hardware support (some NICS already provide hardware > TX completion times) > > _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
