Re: RouterBoard 133 support

[Arnaud Lacombe <lacombar%gmail.com@localhost>]

David Young wrote:
> > If I trust the Vlan_GI and Vlan_GII, I have the following mapping:
> >          MII0 MII1 MII2 MII3 MII4 MII5 CPU
> >    VLAN0 x                             x
> >    VLAN1      x                        x
> >    VLAN2           x                   x
> >    VLAN3                x              x
> >    VLAN4                     x         x
> >    VLAN5                          x    x
>
> Huh.  Is that before or after NetBSD has configured those registers?
after, before, there is the following mapping:
          MII0 MII1 MII2 MII3 MII4 MII5 CPU
    VLAN0                x              x

All other VLAN are cleared. This explain the behavior seen.

> We should not have Yet Another Tool to configure VLANs and to bridge
> ethernets, but we should use bridge(4) and vlan(4) for that purpose.
> The kernel needs both to give bridge(4) member devices the opportunity
> to use hardware features to optimize the data plane.
except that here the bridging is done in hardware inside the switch and 
you can't control that much.

> Similarly,
> vlan(4) needs to let the physical interface assume some of the tagging.
> The idea is to use familiar interfaces to configure bridges and VLANs,
> even on unfamiliar hardware.
I see it in another way. Currently vlan(4) provide in software the 
feature provided by the adm5120 VLAN feature. The current architecture 
is to bind each interface to a VLAN. In this configuration we have 6 
separate interface. If I understand correctly the doc, a packet is 
forwarded to te CPU only if its destination address match the MAC 
associated with the VLAN.

We can think of use case where people would like to have 1 WAN port on 
VLAN1, 2 bridged port on VLAN0 seen by the CPU and 3 bridged port 
isolated from the CPU and other traffic. In this setup, we would have 
the following matrix:
          MII0 MII1 MII2 MII3 MII4 MII5 CPU
    VLAN0      x    x                   x
    VLAN1 x                             x
    VLAN2                               x
    VLAN3                x
    VLAN4                     x
    VLAN5                          x

In which case the OS would only see 3 interfaces from which it 
send/receive traffic, one for each VLAN.

AFAIK linux based router use this setup, I'm not sure they provide the 
flexibility to define the vlan matrix.

Using vlan(4) would move the processing from the hardware to the kernel 
and thus software processing of the data.

> > Btw, the current interface mapping will attach 6 interfaces which does
> > not fit with the hardware (only 3 ethernet plug on the board)
>
> I do not know how to find out which ports are present.  Is there some
> indication by MII?  Does the BIOS configuration tell us?
I don't think, it needs to be hard-wired at compile time.

 - Arnaud