[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 04 Apr 2011 22:47:48 +0200
From: Nicolas de Pesloüan
<nicolas.2p.debian@...il.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: Jiri Pirko <jpirko@...hat.com>, Jesse Gross <jesse@...nel.org>,
netdev@...r.kernel.org, davem@...emloft.net,
shemminger@...ux-foundation.org, kaber@...sh.net, fubar@...ibm.com,
eric.dumazet@...il.com, andy@...yhouse.net, xiaosuo@...il.com
Subject: Re: [patch net-next-2.6] net: vlan: make non-hw-accel rx path similar
to hw-accel
Le 04/04/2011 21:51, Eric W. Biederman a écrit :
>
> __netif_receive_skb is actually late for untagging. eth_type_trans
> would be better but not path of control into __netif_receive_skb
> actually calls eth_type_trans.
Because vlan may nest, we need to keep some sort of frame untagging inside __netif_receive_skb.
In order to avoid duplicate code, I suggest to manage the first level untagging (for non hwaccel)
the same way we manage other levels of untagging (which are by design non hwaccell).
Hence my proposal to use a rx_handler on the parent device of the vlan device, if we know the parent
device lack hwaccel vlan handling.
So, instead of trying to mimic the hwaccel path in software, I suggest to simply disable software
untagging when we know hwaccel untagging is present, by removing (or not installing) the vlan
rx_handler from the hwaccel net_device.
Can someone clarify whether hwaccel capable NIC will always untag tagged frames or will only do so
if requested at device setup?
Nicolas.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists