From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Mon, 17 Apr 2006 19:03:30 +0000 Subject: Re: [LARTC] htb overrate with 2.6.16 Message-Id: <4443E682.2030800@dsl.pipex.com> List-Id: References: <1145095091.18168.26.camel@indigo.declera.com> In-Reply-To: <1145095091.18168.26.camel@indigo.declera.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org 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