public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Abraham vd Merwe <abraham@2d3d.co.za>,
	Linux Kernel Development <linux-kernel@vger.kernel.org>
Subject: Re: questions about network device drivers
Date: Tue, 30 Jul 2002 10:54:35 -0400	[thread overview]
Message-ID: <3D46A8AB.4030308@mandrakesoft.com> (raw)
In-Reply-To: 1028044126.6726.35.camel@irongate.swansea.linux.org.uk

Alan Cox wrote:
> On Tue, 2002-07-30 at 15:15, Abraham vd Merwe wrote:
> 
>>hard_start_xmit() method
>>========================
>>
>>when should this function return 0 and when should it return 1 and in which
>>cases should it do netif_stop_queue() and/or free the dev_kfree_skb() ?
> 
> 
> 0 - OK
> 1 - I am busy, give me it later.
> 
> If you return 1 be sure to netif_stop_queue. The netif_wake_queue will
> continue transmission

I was recently corrected in this...  for modern drivers it's really a 
bug (see drivers/net/tg3.c::tg3_start_xmit).  The queue should be 
managed such that it is awake only when there is room for more packets.

For example, one code path (not the default one) in dev_queue_xmit will 
just drop the skb, not requeue it for later.


>>tx_timeout() method
>>=================
>>
>>there is no way to return an error in the tx_timeout method. what should I
>>do when an error occurs in that function (e.g. I'm unable to reset the
>>controller)? panic? that seems a bit excessive...
> 
> 
> Try again ? If that fails I guess you initiate the self destruct
> sequence for just that driver.


The typical method is to reset the NIC hardware, and either requeue 
waiting packets or drop all the packets you have waiting on the floor. 
tx_timeout is a generic catch-all that normally happens when the NIC is 
wedged.

	Jeff



  parent reply	other threads:[~2002-07-30 14:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-30 14:15 questions about network device drivers Abraham vd Merwe
2002-07-30 15:48 ` Alan Cox
2002-07-30 14:48   ` Abraham vd Merwe
2002-07-30 14:57     ` Jeff Garzik
2002-07-30 14:54   ` Jeff Garzik [this message]
2002-07-30 15:04     ` Russell King
2002-07-31  8:53       ` Abraham vd Merwe
  -- strict thread matches above, loose matches on Subject: below --
2002-07-31 11:14 jamal

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=3D46A8AB.4030308@mandrakesoft.com \
    --to=jgarzik@mandrakesoft.com \
    --cc=abraham@2d3d.co.za \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox