Re: RouterBoard 133 support

[David Young <dyoung%pobox.com@localhost>]

On Tue, Nov 18, 2008 at 11:47:45PM -0500, Arnaud Lacombe wrote:
> 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.

That's right.  And if I recall right, bridge(4) lets us control at least
as much as the hardware does.  So it is a fine fit.

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

The matrix you have drawn corresponds to this setup:

        ifconfig bridge0 create
        brconfig bridge0 add admsw1 add admsw2 up

        ifconfig admsw0 up

        ifconfig admsw3 down
        ifconfig admsw4 down
        ifconfig admsw5 down

But I think that you may have misplaced your x's in the VLAN3, 4, and
5 rows.  I thought that you intended to bridge together ports 3, 4, and 5?

          MII0 MII1 MII2 MII3 MII4 MII5 CPU
    VLAN0      x    x                   x
    VLAN1 x                             x
    VLAN2                               x
    VLAN3                x    x    x
    VLAN4
    VLAN5

That matrix roughly corresponds to this setup:

        ifconfig bridge0 create
        brconfig bridge0 add admsw1 add admsw2 up

        ifconfig admsw0 up

        ifconfig bridge1 create
        brconfig bridge1 add admsw3 add admsw4 add admsw5 up

I believe that we can infer that there should be no 'x' in the CPU
column on rows 3, 4, and 5, if there are neither BPF listeners attached
to bridge1, admsw3..5, nor addresses assigned to admsw3..5.

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

Not if vlan(4) delegates to the hardware, as I propose.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24