From: Matt Mackall <mpm@selenic.com>
To: jamal <hadi@cyberus.ca>
Cc: netdev@oss.sgi.com, Andrew Morton <akpm@osdl.org>,
Jeff Garzik <jgarzik@pobox.com>
Subject: Re: [RFC] [PATCH 1/3] netpoll api
Date: Sat, 4 Oct 2003 15:33:04 -0500 [thread overview]
Message-ID: <20031004203304.GD13573@waste.org> (raw)
In-Reply-To: <1065297729.1031.73.camel@jzny.localdomain>
On Sat, Oct 04, 2003 at 04:02:09PM -0400, jamal wrote:
> On Fri, 2003-10-03 at 15:11, Matt Mackall wrote:
>
> > > Nice.
> > > Is the ethernet card in a case like this almost dedicated for this
> > > kind of work?
> >
> > No, I've had good results with it as the only interface to the
> > machine. As netpoll traffic is fairly infrequent, performance seems
> > little affected.
> >
>
> Ok, I suppose if you are running some serious server you wont be
> debugging either. Did i understand correctly that no netpoll trafic
> translates to a device being removed from the poll list? i.e only when
> theres traffic to send for example would the controller be invoked?
Polling is only on demand. Eg, in the netconsole case, polling only
happens to push a packet out when a printk occurs. In the netdump or
kgdb case, the entire machine is essentially brought to a halt anyway,
so overhead is irrelevant.
> > > Is disable_irq() in the controller safe for shared irqs? Or maybe this
> > > is critical enough that you dont care?
> >
> > I'm not aware of any issues there. I understand Red Hat has banged on
> > this piece pretty heavily recently for their AS kernel.
> >
>
> Lets say you have a vga card and ethernet sharing the same irq and doing
> a lot of debugging ... would disabling that shared irq kill the display
> for example?
Yes. Again, in the netconsole case, this will only happen when a
printk is occurring. Netconsole is primarily of interest for debugging
or replacing serial console for headless servers. In the 'replacing
serial console' case, it actually reduces overhead because polling the
network is much faster than polling serial.
> > > Its a little wasteful to call the controller when there are is no work
> > > to be done; we have found in NAPI that any extra PCI transactions cost.
> > > (some IBM people doing benchmarking have complained about specweb not
> > > looking good where NAPI will have one extra PCI transaction per packet.
> > > You do it twice the rate NAPI would do it at low speeds).
> > > Again, the answer maybe who cares, this is critical work.
> >
> > Just to be sure you read this right, the poll method (NAPI) is
> > different from poll_controller (netpoll). The name is unfortunate, but
> > it's what Ingo had in his early 2.4 netconsole patches. I could
> > s/poll_controller/netpoll/ perhaps.
> >
>
> Actually the name is proper since polling is involved. I can see the
> confusion with NAPI - so from that angle changing it to something
> more descriptive of its function rather than how it achieves it would
> help.
Ok, netpoll it is.
--
Matt Mackall : http://www.selenic.com : of or relating to the moon
prev parent reply other threads:[~2003-10-04 20:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-03 1:41 [RFC] [PATCH 1/3] netpoll api Matt Mackall
2003-10-03 7:09 ` Andi Kleen
2003-10-03 11:09 ` jamal
2003-10-03 19:11 ` Matt Mackall
2003-10-04 20:02 ` jamal
2003-10-04 20:33 ` Matt Mackall [this message]
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=20031004203304.GD13573@waste.org \
--to=mpm@selenic.com \
--cc=akpm@osdl.org \
--cc=hadi@cyberus.ca \
--cc=jgarzik@pobox.com \
--cc=netdev@oss.sgi.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;
as well as URLs for NNTP newsgroup(s).