Re: [LARTC] htb overrate with 2.6.16

From: Andy Furniss <andy.furniss@dsl.pipex.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] htb overrate with 2.6.16
Date: Mon, 17 Apr 2006 19:03:30 +0000	[thread overview]
Message-ID: <4443E682.2030800@dsl.pipex.com> (raw)
In-Reply-To: <1145095091.18168.26.camel@indigo.declera.com>

Yanko Kaneti wrote:
> On Sun, 2006-04-16 at 19:40 +0100, Andy Furniss wrote:
> 
>>Yanko Kaneti wrote:
>>
>>>On Sun, 2006-04-16 at 03:03 +0100, Andy Furniss wrote: 
>>>
>>>
>>>>Yanko Kaneti wrote:
>>>>
>>>>
>>>>
>>>>>Setting mtu 16500  for the class fixed it. But I wonder where did these
>>>>>giants come from in the first place? The mtu of the interface is and was
>>>>>1500. Or so ifconfig and ip link tell me. Or this is some other mtu we
>>>>>are talking about...
>>>>
>>>>Hmm I didn't expect that - maybe there is some problem with the nic 
>>>>drivers not obeying kernel - is there any tso offload etc. at work here ?
>>>
>>>
>>>Yes and its on by default. The interface mtu still says 1500.
>>>I've tried deleting and attaching the qdisc+class (without explicit
>>>large mtu) with both tso on (ethtool -K eth0 tso on) and tso off , it
>>>doesnt seem to matter - giants appear in both cases. 
>>>With large mtu for the class no giants with both tso on and off.
>>>
>>
>>I think you need to ask fedora or intel driver maintainer about this. 
>>AIUI tso is not in vanilla kernels and the patches are quite invasive.
> 
> 
> Well, as much as google tells me TSO has been in the kernel and enabled
> since 2.5.33 and e1000 was the first driver to support it. 
> The FC4 2.6.16 kernel doesn't have any tso related patches as can be
> seen here http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/FC-4/
> 
> Since my immediate problem was solved with the mtu param I plan on
> forgetting about htb and traffic control in general for the time
> being :) Thanks again.

One more thing I just thought - sfq sets its quantum from the dev mtu.

While I always thought that the "must be >=mtu" comment in the source 
was a bit OTT, it still "should" be >= mtu for the drr to be 0(1) for 
cpu work.

You can set it explicitly by adding quantum=X on the sfq line.

For ethernet X is mtu + 14.

Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc