netdev - Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path similar to hw-accel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4DD7BB61.9050200@gmail.com>
Date:	Sat, 21 May 2011 15:17:21 +0200
From:	Nicolas de Pesloüan 
	<nicolas.2p.debian@...il.com>
To:	Changli Gao <xiaosuo@...il.com>, Jiri Pirko <jpirko@...hat.com>
CC:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	shemminger@...ux-foundation.org, kaber@...sh.net, fubar@...ibm.com,
	eric.dumazet@...il.com, andy@...yhouse.net, jesse@...ira.com,
	ebiederm@...ssion.com
Subject: Re: [patch net-next-2.6 v2] net: vlan: make non-hw-accel rx path
 similar to hw-accel

Le 21/05/2011 12:43, Changli Gao a écrit :
> On Sat, May 21, 2011 at 3:29 PM, Jiri Pirko<jpirko@...hat.com>  wrote:
>>
>> I do not see a reason why to not emulate that. To make paths as much
>> similar as they can be, that is the point of this patch.
>>
>> I think it would be better to fix an issue you are pointing at
>> rather that revert this.
>>
>
> In my opinion, the hardware accelerated VLAN RX is just a special case
> of the non hardware accelerated VLAN RX with header reordering. For
> promiscuous NICs and bridges, hw-accel-vlan-rx is just disabled.

I strongly agree with that.

The fact that a skb holds a VLAN tag is not a good enough reason to always remove this tag before 
giving the skb to protocol handlers.

If the user ask for VLAN tag removal, we should remove the tag, possibly using hw-accel untagging if 
available else software untagging. And if the user doesn't ask for tag removal, we should not untag.

In other words, if the user doesn't setup any vlan interface on top of another interface, there is 
no reason to untag the skb : both hw-accel untagging and software untagging should be disabled.

Also, the skb should be delivered untagged or tagged to protocol handlers, depending on the 
particular device the protocol handlers registered at. The same skb might need to be delivered 
tagged to a ptype_all handler registered at eth0 and untagged to a ptype_base handler registered at 
eth0.100.

rx_handler still sounds the right place to do software untagging, because software untagging is a 
per-device process. A vlan_untagging rx_handler should be installed on the devices that have vlan 
child device and (that lack hw-accel or where hw-accel is disabled). This would also cause 
__netif_receive_skb() not to hold any vlan specific code, which is cleaner.

I perfectly understand that this might require several rx_handlers per device, for advanced setup, 
but I think for long that several rx_handlers is a powerful feature we need.

	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