Re: VLAN/bridge "compression" in wifi (was: Re: [PATCH 3/8] qtnfmac: implement AP_VLAN iftype support)
Hi, > > To clarify, I think what you - conceptually - want is the following > > topology: > > > > +--- eth0.1 --- br.1 --- wlan0.1 > > | > > eth0 ---+--- eth0.2 --- br.2 --- wlan0.2 > > | > > +--- eth0.3 --- br.3 --- wlan0.3 [...] > That's right. In fact, hostapd is able to create this kind of network > bridge infrastructure automatically when it is built > with CONFIG_FULL_DYNAMIC_VLAN option enabled. Cool, I was unaware of the exact functionality of this build-time option. :) > > Now, you seem to want to compress this to > > > > +--- wlan0.1 > > | > > eth0 --- br ---+--- wlan0.2 > > | > > +--- wlan0.3 [...] > Exactly. And yes, the only purpose of this 'non-conventional' mode > was to have 802.1Q acceleration on the ethernet port. Right. You can still have acceleration in the top picture by placing the feature into the Ethernet hardware, so that tagging/untagging doesn't have to touch the packet data but just touches (skb) metadata. But obviously that's something that happens on the other side and you don't have control over it. Anyway, I'm happy we cleared up what was going on and also that you decided to leave it for now and work with the regular Linux topology model. Thanks, johannes
Re: VLAN/bridge "compression" in wifi (was: Re: [PATCH 3/8] qtnfmac: implement AP_VLAN iftype support)
Hi Johannes and all, > > In a way this feature seems mis-designed - you never have 802.1Q tags > > over the air, but you're inserting them on RX and stripping them on > > TX, probably in order to make bridging to ethernet easier and not > > have to have 802.1Q acceleration on the ethernet port, or - well - in > > order to have an ability to do this with an ethernet card that only > > has a single CPU port. > > Ok this isn't really right either - it's only for saving the 802.1Q > acceleration on the Ethernet port, really - and saving the extra > bridges. > > To clarify, I think what you - conceptually - want is the following > topology: > > +--- eth0.1 --- br.1 --- wlan0.1 > | > eth0 ---+--- eth0.2 --- br.2 --- wlan0.2 > | > +--- eth0.3 --- br.3 --- wlan0.3 > > where eth0.N is just "ip link add link eth0 name eth0.N type vlan id N" > and br.N is obviously a bridge for each, and the wlan0.N are AP_VLAN > type interfaces that isolate the clients against each other as far as > wifi is concerned. > > Is this correct? As far as I understand, that's the baseline topology > that you're trying to achieve, expressed in terms of Linux networking. That's right. In fact, hostapd is able to create this kind of network bridge infrastructure automatically when it is built with CONFIG_FULL_DYNAMIC_VLAN option enabled. > Now, you seem to want to compress this to > > +--- wlan0.1 > | > eth0 --- br ---+--- wlan0.2 > | > +--- wlan0.3 > > and have the 802.1Q tag insertion/removal that's normally configured to > happen in eth0.N already be handled in wlan0.N. > > Also correct? Exactly. And yes, the only purpose of this 'non-conventional' mode was to have 802.1Q acceleration on the ethernet port. > > > We clearly don't have APIs for this, and I don't think it makes sense > in the Linux space - the bridge and wlan0.N suddenly have tagged > traffic rather than untagged, and the VLAN tagging is completely hidden > from the management view. > > johannes
VLAN/bridge "compression" in wifi (was: Re: [PATCH 3/8] qtnfmac: implement AP_VLAN iftype support)
+netdev On Tue, 2017-09-05 at 15:45 +0200, Johannes Berg wrote: > > In a way this feature seems mis-designed - you never have 802.1Q tags > over the air, but you're inserting them on RX and stripping them on > TX, probably in order to make bridging to ethernet easier and not > have to have 802.1Q acceleration on the ethernet port, or - well - in > order to have an ability to do this with an ethernet card that only > has a single CPU port. Ok this isn't really right either - it's only for saving the 802.1Q acceleration on the Ethernet port, really - and saving the extra bridges. To clarify, I think what you - conceptually - want is the following topology: +--- eth0.1 --- br.1 --- wlan0.1 | eth0 ---+--- eth0.2 --- br.2 --- wlan0.2 | +--- eth0.3 --- br.3 --- wlan0.3 where eth0.N is just "ip link add link eth0 name eth0.N type vlan id N" and br.N is obviously a bridge for each, and the wlan0.N are AP_VLAN type interfaces that isolate the clients against each other as far as wifi is concerned. Is this correct? As far as I understand, that's the baseline topology that you're trying to achieve, expressed in terms of Linux networking. Now, you seem to want to compress this to +--- wlan0.1 | eth0 --- br ---+--- wlan0.2 | +--- wlan0.3 and have the 802.1Q tag insertion/removal that's normally configured to happen in eth0.N already be handled in wlan0.N. Also correct? We clearly don't have APIs for this, and I don't think it makes sense in the Linux space - the bridge and wlan0.N suddenly have tagged traffic rather than untagged, and the VLAN tagging is completely hidden from the management view. johannes
