netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).