Re: [RFC patch net-next-2.6] net: allow multiple rx_handler registration
From: Ben Greear <hidden>
Date: 2011-07-01 16:49:23
On 07/01/2011 09:45 AM, Nicolas de Pesloüan wrote:
Le 01/07/2011 17:01, Michał Mirosław a écrit :quoted
quoted
quoted
We could introduce a catch-all macvlan/vlan device that would take addresses/VLANs which are not covered by other configured macvlans/vlans. This would allow clearer configuration and would make the evaluation order explicit. As a bonus, this will give another device to put tcpdump on. ;-)'Sounds like what I had in mind in http://marc.info/?l=linux-netdev&m=130622112921245&w=2 .Almost. My idea assumes that eth0.any won't strip VLAN headers (so its just looks like a filtered eth0).I originally thought unstripped packets should go to eth0. But, if eth0.any get untagged packets, we face two problems: 1/ We need a way to retrieve the original tag. 2/ We need a way to force the tag on output (or we consider eth0.any a pure tcpdump device, which is less useful). But if eth0.any get the exact same packets as those delivered to eth0, this seems useless. Or maybe, eth0.any should get only packets that weren't delivered to any eth0.XXXX devices... and should be named eth0.unmatched instead of eth0.any :-) Do we need eth0.untagged too (which would only get packets that were originally *not* tagged)? eth0 - Get everything, untouched. (I know several people except tagged packets to be untagged here, but I disagree with this part. eth0 is the raw device and should deliver raw packets, possibly retagging packets that were untagged by hw-accel). eth0.100 - Get VLAN 100 packet, untagged. eth0.untagged - Get only non-tagged packets, untouched. eth0.unmatched - Get only tagged packets, untouched.
Lets let the current vlan tagging changes settle a while before adding yet more cruft in this area. Packet filters should be able to filter on tags or not, so I don't think these extra interfaces would be useful or needed. We may need to fix up the sk-filter logic a bit to deal with the stripped tags, however. Thanks, Ben -- Ben Greear [off-list ref] Candela Technologies Inc http://www.candelatech.com