From: Tommy Christensen <tommy.christensen@tpack.net>
To: Michael Renzmann <netdev@nospam.otaku42.de>
Cc: netdev@oss.sgi.com
Subject: Re: Network driver behaviour when loosing link
Date: Sun, 22 May 2005 02:52:31 +0200 [thread overview]
Message-ID: <428FD7CF.3050904@tpack.net> (raw)
In-Reply-To: <428F949C.8080707@otaku42.de>
Michael Renzmann wrote:
> Hi all.
>
> I'm playing with a network driver and came across one thing I'd like to
> ask something about.
>
> Let's assume a driver detects a link status change (for example, the
> link is dropped). I would have expected that the driver should signal
> the change via netif_carrier_on/_off (if used at all) and tell the
> kernel to stop/resume sending packets to the driver (via
> netif_wake_queue/netif_stop_queue).
>
> When checking several drivers I found some that call
> netif_[wake|stop]_queue (e100, e1000), while others don't (natsemi, tg3).
>
> Hence the question: what is the recommended behaviour in such a case? Is
netif_carrier_on/off should certainly be used.
The use of netif_stop_queue depends on your HW:
A) If your NIC continues taking packets from the ring buffer while link
is down, then just let it do so. No need to call netif_stop_queue.
Since recently, the stack will seize sending packets to your driver
anyway. NB: this doesn't happen instantly, but typically within 1 sec.
after calling netif_carrier_off.
B) If your NIC stops DMA'ing packets when link is down, you have two
options:
1) Check netif_carrier_ok in your hard_start_xmit function.
2) Call netif_stop_queue when link is lost.
In both cases you have to flush the NIC's TX ring buffer, in order not
to hold up resources (and not to send out stale packets when link is
restored).
> it ok to call netif_[stop|wake]_queue? How about adjusting the
The queue state is assumed stable when holding dev->xmit_lock, so you can
only call netif_stop_queue/wake_queue when this lock is held. However,
this requirement doesn't seem do be followed everywhere. And then there
is the LLTX drivers...
> IFF_RUNNING flag accordingly? Is there any documentation available on
> this topic?
Drivers shouldn't touch IFF_RUNNING. It is maintained by the stack.
Documentation? I haven't really seen any myself, except for the usual:
source code, and mailing-list discussions. Any pointers are welcome'd.
-Tommy
prev parent reply other threads:[~2005-05-22 0:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-21 20:05 Network driver behaviour when loosing link Michael Renzmann
2005-05-22 0:52 ` Tommy Christensen [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=428FD7CF.3050904@tpack.net \
--to=tommy.christensen@tpack.net \
--cc=netdev@nospam.otaku42.de \
--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).