From: Franco Fichtner <franco@lastsummer.de>
To: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
Cc: Netdev <netdev@vger.kernel.org>,
"Allan, Bruce W" <bruce.w.allan@intel.com>
Subject: Re: e1000e: reset of tx_queue_len
Date: Tue, 02 Mar 2010 20:52:15 +0100 [thread overview]
Message-ID: <4B8D6C6F.9050306@lastsummer.de> (raw)
In-Reply-To: <alpine.WNT.2.00.1003021020160.2888@jbrandeb-desk1.amr.corp.intel.com>
Brandeburg, Jesse wrote:
> On Tue, 2 Mar 2010, Franco Fichtner wrote:
>
>> while working on a new server, I noticed that tx_queue_len is reset
>> to the default of 1000 while ADDRCONF(NETDEV_CHANGE).
>> This happens with 2.6.30.8, but I could not see any obvious
>> differences to the current state of e1000e, while trying to find the
>> problem in the code.
>>
>
> The driver tries to set the queuelen back to 1000 if the link changes
> speed, because the driver tries to shorten the txqueuelen to 100 to reduce
> latency when the link changes to 100/10 Mb/s
>
Thanks, that explains it. Since we don't connect ports at startup, the
plugging causes
a speed "change".
>> The interface has been configured including a customized qlen
>> via /etc/network/interfaces. The ports are not connected at startup
>> so obviously the Kernel reports
>>
>> ADDRCONF(NETDEV_UP): eth2: link is not ready
>>
>
> do your scripts try to configure the queuelen when link is not up? Why
> are the ports not connected at startup?
>
I have a modified up command that sets appropriate values of mtu and
qlen via ip. The device is
brought up at startup automatically with the correct values. At least
that's what ifconfig shows
even though the port is not yet connected.
There has been a lot of testing back and forth with single hosts and
much larger quantities of traffic.
This got really messy when testing single host first (connected via 100
Mb/s, so qlen to 100) and then
switching to 1000 Mb/s. qlen would still be 100, causing lots of packet
drops. This took a few
days to track down, unfortunately.
> Hope this helps
Greatly appreciated, thanks again. :)
Franco
next prev parent reply other threads:[~2010-03-02 19:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 17:44 e1000e: reset of tx_queue_len Franco Fichtner
2010-03-02 18:27 ` Brandeburg, Jesse
2010-03-02 19:52 ` Franco Fichtner [this message]
2010-03-03 14:22 ` Franco Fichtner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B8D6C6F.9050306@lastsummer.de \
--to=franco@lastsummer.de \
--cc=bruce.w.allan@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.