Re: VLAN/bridge "compression" in wifi (was: Re: [PATCH 3/8] qtnfmac: implement AP_VLAN iftype support)

Hi Johannes and all,

quoted

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

Hi,

quoted

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. :)

quoted

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