LWN: Comments on "TSO sizing and the FQ scheduler"

TSO sizing and the FQ scheduler

sandymac — 2013-09-06T21:35:13+00:00

connection tracking is likely fine for the home or the office router/gateways performing NAT. At the ISP level that may not be cost effective.

TSO sizing and the FQ scheduler

robbe — 2013-09-03T19:50:33+00:00

> nothing can tell the scheduler [when a particular flow is shut down] for
> flows without local endpoints

What about connection tracking that lives right next door in the same kernel?

TSO sizing and the FQ scheduler

DavidS — 2013-09-03T09:11:04+00:00

I'd rather guess that the three seconds come from "if a connection hadn't had packets in three seconds, the scheduler might as well treat the next packet like a new one."

TSO sizing and the FQ scheduler

k3ninho — 2013-08-29T12:01:01+00:00

>Whenever a new flow is added, a pass is made over the associated red-black tree to clean out flows that have been detached for a sufficiently long time — three seconds in the current patch.

Given the discussion is of flow rates and queues which reflect known information about the state of the network, it seems crazy that this is a fixed number. Maybe the maths has been done offline to find the 99th percentile of an appropriate lognormal for TCP flow duration, but the approach of sampling and making predictions which is used in the other components of this patch suggests that calculating an estimate of the mean at clean-up time could inform the clean-out expiry timer. That might be best done with some floating point maths, unfortunately a kernel no-no. But like many statisticians say, 'we can make an approximation'..!

K3n.