The framework should:

• Allow an administrator to configure common aspects of the switch
• The administration interface should be generic (not switch model specific)
• Allow switch model specific configuration extensions
• Enable identification of ports by their label on the device's case

In order to have a generic configuration interface, the framework has the concept of an abstract switch that models the various features and configuration settings of the concrete switch chips. This abstract switch can have these features:

• 2 to 32 physical ports, some of which might be internal to the device (CPU attachment)
• external ports can have PHYs for link control
• max. frame length (std. Ethernet, .1q tagged, q-in-q tagged, jumbo frames)
• .1Q VLAN support with a limited number of VLANs (including tagged/untagged ports)
• .1Q VLAN support with all possible VID values
• .1Q Priority tag support and frame classification
• IPv4/IPv6 DSCP priority
• .1D Spanning Tree management functions
• outsource .1D processing to host CPU (punt frames, adjust forwarding and learning status per port)
• IGMP snooping
• port mirroring
• ACL with forward/drop/punt to CPU actions, filtering on SA, DA, IPv4, IPv6 addresses
• .1X support

Per-por features:

• port-based VLAN support
• per-port settings for ingress and egress handling of tagged and untagged frames (strip/drop/add)
• add VLAN tag to untagged frames with the VID indicating the ingress port of the frame
• QoS queue handling, per-port priority
• forwarding and learning enable/disable (.1D)
• statistics counters
• LED configuration

The following questions likely should be answered:

• How are statistics going to be exposed? sysctl, SNMP/MIB framework, userland utility? How are the various counters offered and discovered, since the switch controllers differ widely in this aspect?
• How can more advanced aspects be modeled in a generic way, how would other system componentes (natd, etc.) tie into these?
• Some of the switches are attached to the CPU via the MII SMI (signals MDC/MDIO). The current PHY code assumes a one-to-one relationship between MII and MAC with one or more PHYs connected to it; these switches use a common SMI, but separate MAC and PHY pairs for the switch ports.
• Many of these controllers allow the CPU to control spanning tree functions; can we reuse the STP code from if_bridge?

This Realtek Ethernet switch is used in the TP-LINK TL-WR1043ND. It has five ports with built-in PHYs and one MII port for connection to an Ethernet MAC. It can be configured through a register interface that is based on I2C (but not I2C protocol compliant). The built-in PHYs are controlled through this register interface, instead of an MDC/MDIO interface through the CPU MAC.