[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110713141127.23703590@nehalam.ftrdhcpuser.net>
Date: Wed, 13 Jul 2011 14:11:27 -0700
From: Stephen Hemminger <shemminger@...ux-foundation.org>
To: Jiri Pirko <jpirko@...hat.com>
Cc: netdev@...r.kernel.org, davem@...emloft.net,
eric.dumazet@...il.com, nicolas.2p.debian@...il.com,
andy@...yhouse.net, greearb@...delatech.com, mirqus@...il.com,
bhutchings@...arflare.com
Subject: Re: hypothetical vlan rx path question
On Wed, 13 Jul 2011 22:49:46 +0200
Jiri Pirko <jpirko@...hat.com> wrote:
> Hi guys.
>
> Consider following code taken from 8139cp.c
>
>
> static inline void cp_rx_skb (struct cp_private *cp, struct sk_buff *skb,
> struct cp_desc *desc)
> {
> skb->protocol = eth_type_trans (skb, cp->dev);
>
> cp->dev->stats.rx_packets++;
> cp->dev->stats.rx_bytes += skb->len;
>
> #if CP_VLAN_TAG_USED
> if (cp->vlgrp && (desc->opts2 & cpu_to_le32(RxVlanTagged))) {
> vlan_hwaccel_receive_skb(skb, cp->vlgrp,
> swab16(le32_to_cpu(desc->opts2) & 0xffff));
> } else
> #endif
> netif_receive_skb(skb);
> }
>
>
> Now my question is why the check for cp->vlgrp is needed here. Because
> in hypothetical case it might be possible to receive vlan packet as
> non-vlan packet (vlan tag would be lost).
>
> This is present in many drivers.
>
> How about to kill this check entirely and let the later code to deside
> what to do with the packet?
>
> Thanks.
>
> Jirka
All this is moot with new vlan model. It should always just put
tagged packet up.
I think all drivers with .ndo_vlan_rx_register need to be still converted.
--
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