netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Pankratov <ap@swapped.cc>
To: netdev@oss.sgi.com
Subject: ENOBUFS and dev_queue_xmit()
Date: Mon, 14 Jun 2004 21:56:44 -0700	[thread overview]
Message-ID: <40CE818C.2090906@swapped.cc> (raw)

I've been poking around rather weird problem today where send()
on UDP socket was failing with ENETDOWN. When traced down to
the kernel, it happened to originate in dev_queue_xmit() -

	if (!netif_queue_stopped(dev)) {
		...
	}
	...
	$here

meaning that the device's queue was stopped. The comment there
implies that only a broken virtual device may end up $here, but
the fact is that I saw it for a physical interface running
slightly modified via-rhine driver. The original driver code
contains a snippet that stops the queue if its Tx ring buffer
becomes full -

	if (np->cur_tx == np->dirty_tx + TX_QUEUE_LEN)
		netif_stop_queue(dev);

and this code got actually executed with a hack applied.

At this point I thought that dev_queue_xmit() must be mistakenly
returning ENETDOWN instead of ENOBUFS, but looking at 'man 2 send'
I saw that -

	ENOBUFS
         The output queue for a network interface was full...snip...
	(Normally,  this  does  not occur  in Linux. Packets are
	just silently dropped when a device queue overflows.)

Hmmm... so I looked at e100 and tulip and these both stop the queue
too if they run out of buffers. In other words, the 'silently dropped'
clause from man page does not seem to be consistently followed.

Is this a known (pseudo?) issue ? ENOBUFS makes much more sense
in this context. I can certainly check interface status (IFF_UP)
on every ENETDOWN to see what's the real cause, but that's kind
of ugly.

Alex

             reply	other threads:[~2004-06-15  4:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-15  4:56 Alex Pankratov [this message]
2004-06-15 12:54 ` ENOBUFS and dev_queue_xmit() jamal
2004-06-15 15:39   ` Alex Pankratov

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=40CE818C.2090906@swapped.cc \
    --to=ap@swapped.cc \
    --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).