From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andy Furniss <lists@andyfurniss.entadsl.com>
Date: Wed, 17 Jan 2007 21:11:46 +0000
Subject: Re: [LARTC] egress bandwidth not limited / limited extremely
Message-Id: <45AE9112.2000703@andyfurniss.entadsl.com>
List-Id: <lartc.vger.kernel.org>
References: <45AC22ED.4060107@skula.com>
In-Reply-To: <45AC22ED.4060107@skula.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: lartc@vger.kernel.org

Marek Kierdelewicz wrote:
> Hi there,
> 
> 
>>>05:04.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5714
>>>Gigabit Ethernet (rev a3)
> 
> 
>>You may need to turn off segmentation offload with ethtool -k
> 
> 
> That's very interesting. Do you have any more information on this
> subject? Does tso in general distrupt accuracy of tc ops or is it the
> case only with Broadcom nics? Any links would be very much appreciated.

I don't have any gig eth, but it's not just Broadcom.

There have been other posts on here where people have needed to increase 
  htb's mtu parameter to get htb to handle it - despite the interface 
being 1500. For shaping traffic for a slow link that is not going to be 
nice - you could end up dropping multiple tcp segments at once, and it 
will hurt jitter. I don't imagine it's right to do it for shaping at gig 
speed either, maybe the default long queue on eth saves dropping.

I suppose those using gig eth and shaping routed traffic at 1500 MTU 
will not notice unless they try and shape locally generated aswell.

Andy.

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