From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: Jiri Pirko <jpirko@redhat.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net,
shemminger@linux-foundation.org, kaber@trash.net,
fubar@us.ibm.com, eric.dumazet@gmail.com, andy@greyhouse.net,
xiaosuo@gmail.com, jesse@nicira.com
Subject: Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel
Date: Sun, 03 Apr 2011 17:23:44 +0200 [thread overview]
Message-ID: <4D989100.1090207@gmail.com> (raw)
In-Reply-To: <1301739966-7604-1-git-send-email-jpirko@redhat.com>
Le 02/04/2011 12:26, Jiri Pirko a écrit :
> Now there are 2 paths for rx vlan frames. When rx-vlan-hw-accel is
> enabled, skb is untagged by NIC, vlan_tci is set and the skb gets into
> vlan code in __netif_receive_skb - vlan_hwaccel_do_receive.
>
> For non-rx-vlan-hw-accel however, tagged skb goes thru whole
> __netif_receive_skb, it's untagged in ptype_base hander and reinjected
>
> This incosistency is fixed by this patch. Vlan untagging happens early in
> __netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers)
> see the skb like it was untagged by hw.
>
> Signed-off-by: Jiri Pirko<jpirko@redhat.com>
<snip>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 3da9fb0..bfe9fce 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3130,6 +3130,12 @@ another_round:
>
> __this_cpu_inc(softnet_data.processed);
>
> + if (skb->protocol == cpu_to_be16(ETH_P_8021Q)) {
> + skb = vlan_untag(skb);
> + if (unlikely(!skb))
> + goto out;
> + }
> +
I like the general idea of this patch, but I don't like the idea of re-inserting specific code
inside __netif_receive_skb.
You made a great work removing most - if not all - device specific parts from __netif_receive_skb,
by introducing rx_handler.
I think the above part (and vlan_untag) should be moved to a vlan_rx_handler that would be set on
the net_devices that are the parent of a vlan net_device and are NOT hwaccel.
vlan_rx_handler would return RX_HANDLER_ANOTHER if skb holds a tagged frame (skb->dev changed) and
RX_HANDLER_PASS if skb holds an untagged frame (skb->dev unchanged).
This would also cause protocol handlers to receive the untouched (tagged) frame, if no setup
required the frame to be untagged, which I think is the right thing to do.
> @@ -3177,7 +3183,7 @@ ncls:
> ret = deliver_skb(skb, pt_prev, orig_dev);
> pt_prev = NULL;
> }
> - if (vlan_hwaccel_do_receive(&skb)) {
> + if (vlan_do_receive(&skb)) {
> ret = __netif_receive_skb(skb);
> goto out;
> } else if (unlikely(!skb))
Why are you calling __netif_receive_skb here? Can't we simply goto another_round?
I really think vlan_untag and vlan_do_receive could me merged in a vlan_rx_handler.
And if someone consider rx_handler processing happens to late for ptype_all handlers, may be it is
time to have a look at one of my previous proposed patch: http://patchwork.ozlabs.org/patch/85578/
Nicolas.
next prev parent reply other threads:[~2011-04-03 15:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-02 10:26 [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar to hw-accel Jiri Pirko
2011-04-02 15:55 ` Stephen Hemminger
2011-04-02 18:27 ` Jiri Pirko
2011-04-03 9:27 ` Nicolas de Pesloüan
2011-04-03 13:22 ` Jiri Pirko
2011-04-03 15:23 ` Nicolas de Pesloüan [this message]
2011-04-03 20:38 ` Jesse Gross
2011-04-04 6:54 ` Nicolas de Pesloüan
2011-04-04 7:14 ` Jiri Pirko
2011-04-04 19:00 ` Nicolas de Pesloüan
2011-04-04 19:51 ` Eric W. Biederman
2011-04-04 20:29 ` Jiri Pirko
2011-04-04 20:47 ` Nicolas de Pesloüan
2011-04-04 20:50 ` Jesse Gross
2011-04-04 21:04 ` Nicolas de Pesloüan
2011-04-05 7:25 ` Jiri Pirko
2011-04-05 7:26 ` Jiri Pirko
2011-04-04 20:30 ` Jiri Pirko
2011-04-04 20:51 ` Nicolas de Pesloüan
2011-04-05 7:19 ` Jiri Pirko
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=4D989100.1090207@gmail.com \
--to=nicolas.2p.debian@gmail.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=fubar@us.ibm.com \
--cc=jesse@nicira.com \
--cc=jpirko@redhat.com \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@linux-foundation.org \
--cc=xiaosuo@gmail.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.