[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110714063152.GA1822@minipsycho>
Date: Thu, 14 Jul 2011 08:31:53 +0200
From: Jiri Pirko <jpirko@...hat.com>
To: Stephen Hemminger <shemminger@...ux-foundation.org>
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
Wed, Jul 13, 2011 at 11:11:27PM CEST, shemminger@...ux-foundation.org wrote:
>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.
That's what I thought.
>
>I think all drivers with .ndo_vlan_rx_register need to be still converted.
Yes, I'm kinda on the way to do that.
Thanks Stephen.
--
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