hypothetical vlan rx path question

3 messages, 2 authors, 2011-07-14 · open the first message on its own page

hypothetical vlan rx path question

From: Jiri Pirko <hidden>
Date: 2011-07-13 20:50:28

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

Re: hypothetical vlan rx path question

From: Stephen Hemminger <hidden>
Date: 2011-07-13 21:11:37

On Wed, 13 Jul 2011 22:49:46 +0200
Jiri Pirko [off-list ref] 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.

Re: hypothetical vlan rx path question

From: Jiri Pirko <hidden>
Date: 2011-07-14 06:32:05

Wed, Jul 13, 2011 at 11:11:27PM CEST, shemminger@linux-foundation.org wrote:
On Wed, 13 Jul 2011 22:49:46 +0200
Jiri Pirko [off-list ref] wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help