All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [RFC net 00/03]: dev_queue_xmit error propagation
Date: Thu, 11 Jun 2009 18:33:26 +0200	[thread overview]
Message-ID: <4A3131D6.40807@trash.net> (raw)
In-Reply-To: <20090611.031852.90563118.davem@davemloft.net>

David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Tue,  9 Jun 2009 18:16:59 +0200 (MEST)
> 
>> Currently the ->ndo_hard_start_xmit() callbacks are only permitted to return
>> one of the NETDEV_TX codes. This prevents any kind of error propagation for
>> virtual devices, like queue congestion of the underlying device in case of
>> layered devices, or unreachability in case of tunnels.
>>
>> These patches change the return conventions so hard_start_xmit() can return
>> a NETDEV_TX code, an errno code or a NET_XMIT code. This means it can
>> additionally to the NETDEV_TX codes simply return the value of dev_queue_xmit().
>>

> These changes look fine to me.
> 
> That one if() conditional checking 'ret' for three different
> properties is stretching the brain a bit.  Maybe you can
> encapsulate that sucker into an inline function with suitable
> comments.  That way when someone reads the test, it just says
> what it is looking for, rather than being some complicated
> set of tests.

Yeah, I mainly failed to come up with a suitable name, but I've now
moved it to an inline function called "dev_xmit_skb_consumed".
Better suggestions are still welcome though :)

> Once you fix that up and the problem Eric spotted in patch #3
> feel free to formally submit this.

I still need to verify that no drivers are using the raw values for
the NETDEV_TX codes since NETDEV_TX_LOCKED is using a different
value with my patch. I'll probably submit them later today.

  reply	other threads:[~2009-06-11 16:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-09 16:16 [RFC net 00/03]: dev_queue_xmit error propagation Patrick McHardy
2009-06-09 16:17 ` [RFC net-sched 01/03]: use symbolic NET_XMIT constants in qdiscs Patrick McHardy
2009-06-09 16:17 ` [RFC net 02/03]: allow to propagate errors through ->ndo_hard_start_xmit() Patrick McHardy
2009-06-16  9:25   ` Jarek Poplawski
2009-06-19 12:23     ` Patrick McHardy
2009-06-09 16:17 ` [RFC vlan 03/03]: propagate transmission state Patrick McHardy
2009-06-09 16:34   ` Eric Dumazet
2009-06-09 16:37     ` Patrick McHardy
2009-06-11 10:18 ` [RFC net 00/03]: dev_queue_xmit error propagation David Miller
2009-06-11 16:33   ` Patrick McHardy [this message]
2009-06-12  0:05     ` David Miller
2009-06-12  0:10       ` Patrick McHardy

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=4A3131D6.40807@trash.net \
    --to=kaber@trash.net \
    --cc=davem@davemloft.net \
    --cc=netdev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.