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@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
