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

[Eric Dumazet]

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 ?

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)