[Codel] sprout

[Kathleen Nichols]

Yes. In point of fact, that is not what I think. I've pointed out the
differences a
few places. I did do a simulator version of the sfqcodel code that could be
configured closer to the fq_codel code at the request/expense of CableLabs.

Dave, not completely sure which reservation about maxpacket is in reference.

	Kathie

On 7/10/13 3:44 PM, Dave Taht wrote:
> On Wed, Jul 10, 2013 at 3:10 PM, Kathleen Nichols <nichols at pollere.com> wrote:
>> Is that indeed what I think?
> 
> Heh. On another topic, at my stanford talk, you pointed at maxpacket
> being a thing
> you were a bit dubious about. After fiddling with the concept in
> presence of offloads
> (which bloat up maxpacket to the size of a tso packet (20k or more))
> I'm more than a bit dubious about it and in my next build of ns2_codel
> and nfq_codel
>  in linux I just capped it at a mtu in the codel_should_drop function:
> 
>         if (unlikely(qdisc_pkt_len(skb) > stats->maxpacket &&
> qdisc_pkt_len(skb) < 1514 ))
>                 stats->maxpacket = qdisc_pkt_len(skb);
> 
> Perhaps in fq_codel the entire maxpacket idea can be junked?
> 
> The problem that I see is that codel switches out of a potential drop
> state here and
> at almost any workload maxpacket hits a TSO-like size, and at higher workloads
> it's too high. I think eric is working on something that will let
> overlarge packets just
> work and begin to break them down into smaller packets at higher workloads?
> 
> Also
> 
> I'd made a suggestion elsewhere that TSQ migrate down in size from 128k to
> lower as the number of active flows increased. Something like
> tcp_limit_output_size = max((2*BQL's limit)/(number of flows),mtu)
> 
> but I realize now that tcp has no idea what interface it's going out
> at any given
> time... still I'm on a quest to minimize latency and let offloads still work..
> 
> 
> 
>