From: Chris Leech <chris.leech@gmail.com>
To: Jeff Garzik <jgarzik@pobox.com>,
Li Shaohua <shaohua.li@intel.com>, Andrew Morton <akpm@osdl.org>,
lkml <linux-kernel@vger.kernel.org>,
"David S. Miller" <davem@redhat.com>
Subject: Re: hotplug e1000 failed after 32 times
Date: Sun, 19 Sep 2004 21:15:43 -0700 [thread overview]
Message-ID: <41b516cb0409192115151fe38c@mail.gmail.com> (raw)
In-Reply-To: <414E46B7.70901@pobox.com>
On Sun, 19 Sep 2004 22:55:51 -0400, Jeff Garzik <jgarzik@pobox.com> wrote:
> Li Shaohua wrote:
> > I'm not familiar with the NIC driver, but this problem really is
> > annoying. The gurus, please consider a solution. It's not an uncommon
> > case. I believe it's common in a big system with hotplug support. I can
> > understand why the driver doesn't support more than 32 a card, but one
> > card with 32 times hotplug failed is a little ugly.
>
> There should be no problem at all with the driver supporting 32 NICs...
> in fact if it cannot support at least 99 NICs, I would consider that a
> bug.
I'd like to hear more about what the failure condition actually is,
see any system messages logged.
The 32 NIC limitation is for configuration via the module parameters,
but e1000 itself doesn't impose any other limitations on the number of
NICs. I know of testing situations where 360 e1000 ports were in use
on a large system. I've run hotplug tests, powering slots on and off
while passing traffic in a fail-over teaming configuration, for weeks
without problem. I'll run a hotplug test myself as soon as I get a
chance, but I don't see any reason why it should be failing.
As for the module parameter limitations, yes only 32 ports can be
configured that way and the counter doesn't roll back with
hot-removes. I think we can live with those limitations. Indexed
parameters make no sense in a hotplug environment, use ethtool.
The module parameters in e1000 work for a large number or users who
can live with those limitations. That's why they're still in the
driver. As long as they work, I think they should stay. But I'm not
in favor of adding more code, or making the existing code more
complex, to try and remove those limitations. That's why everything
can be configured through ethtool.
- Chris
next prev parent reply other threads:[~2004-09-20 4:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-17 4:53 hotplug e1000 failed after 32 times Li Shaohua
2004-09-17 5:14 ` Andrew Morton
2004-09-17 5:48 ` Li Shaohua
2004-09-17 9:05 ` Li Shaohua
2004-09-17 23:19 ` Andrew Morton
2004-09-17 23:34 ` Jeff Garzik
2004-09-19 16:04 ` Jonathan Lundell
2004-09-19 16:50 ` Dr. David Alan Gilbert
2004-09-20 0:30 ` Jonathan Lundell
2004-09-20 0:51 ` Li Shaohua
2004-09-20 2:55 ` Jeff Garzik
2004-09-20 4:15 ` Chris Leech [this message]
2004-09-20 4:35 ` Li Shaohua
2004-09-17 9:06 ` Li Shaohua
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=41b516cb0409192115151fe38c@mail.gmail.com \
--to=chris.leech@gmail.com \
--cc=akpm@osdl.org \
--cc=davem@redhat.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shaohua.li@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox