[Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps?

[Rick Jones]

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)
> 
>