From: Ben Greear <greearb@candelatech.com>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>,
"Linux 802.1Q VLAN" <vlan@candelatech.com>
Subject: Re: [PATCH] 802.1Q VLAN
Date: Fri, 22 Oct 2004 15:09:10 -0700 [thread overview]
Message-ID: <41798506.1030909@candelatech.com> (raw)
In-Reply-To: <20041022214611.GA4948@electric-eye.fr.zoreil.com>
Francois Romieu wrote:
> Minor nits below.
>
> [...]
>
>>@@ -484,13 +484,32 @@
>> veth->h_vlan_proto, veth->h_vlan_TCI,
>> veth->h_vlan_encapsulated_proto);
>> #endif
>>
>>- stats->tx_packets++; /* for statics only */
>>- stats->tx_bytes += skb->len;
>>-
>> skb->dev = VLAN_DEV_INFO(dev)->real_dev;
>>- dev_queue_xmit(skb);
>>
>>- return 0;
>>+ {
>>+ /* Please note, dev_queue_xmit consumes the pkt regardless of the
>>+ * error value. So, will copy the skb first and free if successful.
>>+ */
>>+ struct sk_buff* skb2 = skb_get(skb);
>>+ int rv = dev_queue_xmit(skb2);
>>+ if (rv != 0) {
>>+ /* The skb memory should still be valid since we made a copy,
>>+ * so can return error code here.
>>+ */
>>+ return rv;
>>+ }
>>+ else {
>>+ /* Was success, need to free the skb reference since we bumped up the
>>+ * user count above.
>>+ */
>>+
>>+ stats->tx_packets++; /* for statics only */
>>+ stats->tx_bytes += skb->len;
>>+
>>+ kfree_skb(skb);
>>+ return 0;
>>+ }
>>+ }
>
>
>
> Why not use a single return point, say:
>
> struct sk_buff *skb2 = skb_get(skb);
> int rv = dev_queue_xmit(skb2);
>
> if (!rv) {
> /*
> * Was success, need to free the skb reference since
> * we bumped up the user count above.
> */
>
> stats->tx_packets++; /* for statics only */
> stats->tx_bytes += skb->len;
>
> kfree_skb(skb);
> }
> return rv;
That should be OK. I think I was worried that I would have to further
translate the error codes. There appears to be no documentation on what
valid return values are for the dev_queue_xmit or the hard_start_xmit
method... I think someone should add comments to the netdevice.h
file to specify the proper return codes (maybe even return an enum).
In my own code, I have this patch to dev.c. I think it is correct,
but I could be wrong:
@@ -1253,6 +1272,17 @@
* A negative errno code is returned on a failure. A success does not
* guarantee the frame will be transmitted as it may be dropped due
* to congestion or traffic shaping.
+ *
+ * -----------------------------------------------------------------------------------
+ * I notice this method can also return errors from the queue disciplines,
+ * including NET_XMIT_DROP, which is a positive value. So, errors can also
+ * be positive.
+ *
+ * Regardless of the return value, the skb is consumed, so it is currently
+ * impossible to retry a send to this method. This implies that virtual devices,
+ * such as VLANs, can ONLY return 0 from their hard_start_xmit method, making
+ * it difficult to apply pressure back up the stack.
+ * --Ben
*/
int dev_queue_xmit(struct sk_buff *skb)
> vlan_dev_get_realdev_name() and vlan_dev_get_vid() can be tidy up
> a bit (factoring dev_put() or handling debug code differently for instance).
Agreed, will fix this and the white-space issue.
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2004-10-22 22:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-22 21:07 [PATCH] 802.1Q VLAN Ben Greear
2004-10-22 21:46 ` Francois Romieu
2004-10-22 22:09 ` Ben Greear [this message]
2004-10-23 0:24 ` Francois Romieu
2004-10-25 20:51 ` Ben Greear
2004-10-25 23:56 ` Ben Greear
2004-10-27 1:02 ` David S. Miller
2004-10-27 23:49 ` David S. Miller
2004-10-28 1:28 ` Ben Greear
2004-10-28 4:42 ` David S. Miller
2004-10-28 23:40 ` Tommy Christensen
2004-10-28 23:35 ` David S. Miller
2004-10-29 0:23 ` Ben Greear
2004-10-29 0:38 ` Krzysztof Halasa
2004-10-29 8:29 ` Tommy Christensen
2004-10-29 17:45 ` Ben Greear
2004-10-29 23:37 ` Tommy Christensen
2004-10-29 23:56 ` Ben Greear
2004-10-30 0:05 ` Ben Greear
2004-10-30 0:31 ` Tommy Christensen
2004-11-01 18:58 ` Ben Greear
2004-11-01 23:08 ` Tommy Christensen
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=41798506.1030909@candelatech.com \
--to=greearb@candelatech.com \
--cc=netdev@oss.sgi.com \
--cc=romieu@fr.zoreil.com \
--cc=vlan@candelatech.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 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.