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

[d@taht.net (Dave Täht)]

Eric Dumazet <eric.dumazet@gmail.com> writes:

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

To talk to this a bit, the huge dynamic range discrepancy between a
10GigE device and what it may be connected to worries me. Some form of
fair queuing should be applied before the data hits the driver.

It would be good to know what 10Gbps hw was capable of pushing more
smarts (such as nRED) further down into the hardware itself, this may
inform future software abstractions and future hardware designs.

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

Which NICs? For example, a whole bunch of us (at least 7 so far) have
settled on the wndr3700 hardware as a good base for experimenting with
wireless solutions. Finding out what NICs are smart enough to be managed
this way would be a goodness.

(And ultimately help them compete better in the marketplace)

>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

-- 
Dave Taht
http://nex-6.taht.net