Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| docs:techref:swconfig [2019/07/14 09:58] – [swconfig] linus | docs:techref:swconfig [2021/03/08 10:46] (current) – Fixed broken link jaimet | ||
|---|---|---|---|
| Line 7: | Line 7: | ||
| ===== Supported hardware ====== | ===== Supported hardware ====== | ||
| - | |||
| '' | '' | ||
| Line 23: | Line 22: | ||
| ===== Usage examples ===== | ===== Usage examples ===== | ||
| - | |||
| ===== Show ===== | ===== Show ===== | ||
| - | |||
| * < | * < | ||
| * < | * < | ||
| Line 94: | Line 91: | ||
| ===== Change ===== | ===== Change ===== | ||
| - | |||
| Note: Make sure to apply any changes made previously with the " | Note: Make sure to apply any changes made previously with the " | ||
| Line 103: | Line 99: | ||
| ==== Design and rationale ==== | ==== Design and rationale ==== | ||
| - | |||
| Generic Netlink Switch configuration API | Generic Netlink Switch configuration API | ||
| ===== Introduction ===== | ===== Introduction ===== | ||
| - | + | The following documentation covers the Linux Ethernet switch configuration API which is based on the Generic Netlink infrastructure. | |
| - | The following documentation covers the Linux Ethernet switch configuration API | + | |
| - | which is based on the Generic Netlink infrastructure. | + | |
| ===== Scope and rationale ===== | ===== Scope and rationale ===== | ||
| - | + | Most Ethernet switches found in small routers are managed switches which allow the following operations: | |
| - | Most Ethernet switches found in small routers are managed switches which allow | + | |
| - | the following operations: | + | |
| * configure a port to belong to a particular set of VLANs either as tagged or untagged | * configure a port to belong to a particular set of VLANs either as tagged or untagged | ||
| * configure a particular port to advertise specific link/ | * configure a particular port to advertise specific link/ | ||
| Line 121: | Line 111: | ||
| * any other vendor specific feature: rate limiting, single/ | * any other vendor specific feature: rate limiting, single/ | ||
| - | Such switches can be connected to the controlling CPU using different hardware | + | Such switches can be connected to the controlling CPU using different hardware busses, but most commonly: |
| - | busses, but most commonly: | + | |
| * SPI/ | * SPI/ | ||
| * MDIO | * MDIO | ||
| * Memory mapped into the CPU register address space | * Memory mapped into the CPU register address space | ||
| - | As of today the usual way to configure such a switch was either to write a | + | As of today the usual way to configure such a switch was either to write a specific driver or to write an user-space application which would have to know about the hardware differences and figure out a way to access the switch registers (spidev, SIOCIGGMIIREG, |
| - | specific driver or to write an user-space application which would have to know | + | |
| - | about the hardware differences and figure out a way to access the switch | + | |
| - | registers (spidev, SIOCIGGMIIREG, | + | |
| This has multiple issues: | This has multiple issues: | ||
| - | |||
| * proliferation of ad-hoc solutions to configure a switch both open source and proprietary | * proliferation of ad-hoc solutions to configure a switch both open source and proprietary | ||
| * absence of common software reference for switches commonly found on the market (Broadcom, Lantiq/ | * absence of common software reference for switches commonly found on the market (Broadcom, Lantiq/ | ||
| * inability to leverage existing hardware representation mechanisms such as Device Tree (spidev, i2c-dev.. do not belong in Device Tree and rely on Linux-specific " | * inability to leverage existing hardware representation mechanisms such as Device Tree (spidev, i2c-dev.. do not belong in Device Tree and rely on Linux-specific " | ||
| - | The goal of the switch configuration API is to provide a common basis to build | + | The goal of the switch configuration API is to provide a common basis to build re-usable and extensible switch drivers with the following ideas in mind: |
| - | re-usable and extensible switch drivers with the following ideas in mind: | + | |
| * having a central point of configuration on top of which a reference user-space implementation can be provided but also allow for other user-space implementations to exist | * having a central point of configuration on top of which a reference user-space implementation can be provided but also allow for other user-space implementations to exist | ||
| * ensure the Linux kernel is in control of the actual hardware access | * ensure the Linux kernel is in control of the actual hardware access | ||
| * be extensible enough to support per-switch features without making the generic implementation too heavy weighted and without making user-space changes each and every time a new feature is added | * be extensible enough to support per-switch features without making the generic implementation too heavy weighted and without making user-space changes each and every time a new feature is added | ||
| - | Based on these design goals the Generic Netlink kernel/ | + | Based on these design goals the Generic Netlink kernel/ |
| - | mechanism was chosen because it allows for all design goals to be met. | + | |
| ===== Distributed Switch Architecture vs. swconfig ===== | ===== Distributed Switch Architecture vs. swconfig ===== | ||
| + | The Marvell Distributed Switch Architecture (DSA) drivers is an existing solution which is a heavy switch driver infrastructure, | ||
| + | [[docs: | ||
| - | The Marvell Distributed Switch Architecture (DSA) drivers is an existing | + | swconfig is vendor agnostic, does not mangle the transmit/ |
| - | solution which is a heavy switch driver infrastructure, | + | It is based on Generic Netlink to allow for each switch driver to easily extend the swconfig API without causing major core parts rework |
| - | [[docs: | + | each and every time someone has a specific feature to implement and offers a central configuration point with a well-defined API. |
| - | connected switches, mangles an Ethernet driver transmit/ | + | |
| - | and does not offer a central control path for the user. | + | |
| - | + | ||
| - | swconfig is vendor agnostic, does not mangle the transmit/ | + | |
| - | of an Ethernet driver and is focused on the control path of the switch rather | + | |
| - | that the data path. It is based on Generic Netlink to allow for each switch | + | |
| - | driver to easily extend the swconfig API without causing major core parts rework | + | |
| - | each and every time someone has a specific feature to implement and offers a | + | |
| - | central configuration point with a well-defined API. | + | |
| * More info e.g. at [[https:// | * More info e.g. at [[https:// | ||
| - | "The Linux kernel manipulates switches with three different operation structures: '' | + | "The Linux kernel manipulates switches with three different operation structures: '' |
| - | + | Certain switches, however, also need distributed switch architecture (DSA). | |
| - | DSA's development was parallel to swconfig, written by the OpenWrt project. The main difference between swconfig and DSA is that DSA-supported switches show one network interface per port, whereas swconfig-configured switches show up as a single port, which limits the amount of information that can be extracted from the switch. For example, you cannot have per-port traffic statistics with swconfig. That limitation is what led to the creation of the switchdev framework, when swconfig was proposed (then refused) for inclusion in mainline. Another goal of switchdev was to support bridge hardware offloading and network interface card (NIC) virtualization…" | + | |
| + | DSA's development was parallel to swconfig, written by the OpenWrt project. | ||
| + | The main difference between swconfig and DSA is that DSA-supported switches show one network interface per port, whereas swconfig-configured switches show up as a single port, which limits the amount of information that can be extracted from the switch. | ||
| + | For example, you cannot have per-port traffic statistics with swconfig. | ||
| + | That limitation is what led to the creation of the switchdev framework, when swconfig was proposed (then refused) for inclusion in mainline. | ||
| + | Another goal of switchdev was to support bridge hardware offloading and network interface card (NIC) virtualization…" | ||
| ===== Switch configuration API ====== | ===== Switch configuration API ====== | ||
| - | + | The main data structure of the switch configuration API is a " | |
| - | The main data structure of the switch configuration API is a " | + | |
| - | which contains the following members: | + | |
| * a set of common operations to all switches (struct switch_dev_ops) | * a set of common operations to all switches (struct switch_dev_ops) | ||
| Line 182: | Line 158: | ||
| * a CPU specific port index | * a CPU specific port index | ||
| - | A particular switch device is registered/ | + | A particular switch device is registered/ |
| - | of functions: | + | |
| register_switch(struct switch_dev *sw_dev, struct net_device *dev); | register_switch(struct switch_dev *sw_dev, struct net_device *dev); | ||
| unregister_switch(struct switch_dev); | unregister_switch(struct switch_dev); | ||
| - | A given switch driver can be backed by any kind of underlying bus driver (i2c | + | A given switch driver can be backed by any kind of underlying bus driver (i2c client, GPIO driver, MMIO driver, directly into the Ethernet MAC driver...). |
| - | client, GPIO driver, MMIO driver, directly into the Ethernet MAC driver...). | + | |
| - | + | ||
| - | The set of common operations to all switches is represented by the " | + | |
| - | switch_dev_ops" | + | |
| + | The set of common operations to all switches is represented by the " | ||
| * get the port list of a VLAN identifier | * get the port list of a VLAN identifier | ||
| * set the port list of a VLAN identifier | * set the port list of a VLAN identifier | ||
| Line 203: | Line 175: | ||
| * get a port statistics counters | * get a port statistics counters | ||
| - | The switch_dev_ops structure also contains an extensible way of representing and | + | The switch_dev_ops structure also contains an extensible way of representing and querying switch specific features, 3 different types of attributes are available: |
| - | querying switch specific features, 3 different types of attributes are | + | |
| - | available: | + | |
| * global attributes: attributes global to a switch (name, identifier, number of ports) | * global attributes: attributes global to a switch (name, identifier, number of ports) | ||
| * port attributes: per-port specific attributes (MIB counters, enabling port mirroring...) | * port attributes: per-port specific attributes (MIB counters, enabling port mirroring...) | ||
| * vlan attributes: per-VLAN specific attributes (VLAN id, specific VLAN information) | * vlan attributes: per-VLAN specific attributes (VLAN id, specific VLAN information) | ||
| - | Each of these 3 categories must be represented using an array of " | + | Each of these 3 categories must be represented using an array of " |
| - | switch_attr" | + | This structure must be filed with: |
| * an unique name for the operation | * an unique name for the operation | ||
| * a description for the operation | * a description for the operation | ||
| Line 221: | Line 189: | ||
| * eventual min/max limits to validate user input data | * eventual min/max limits to validate user input data | ||
| - | The " | + | The " |
| - | will be automatically discovered by the " | + | |
| - | requiring user-space changes. | + | |
| ===== References ===== | ===== References ===== | ||
| - | * [[http:// | + | * [[https:// |
| * [[https:// | * [[https:// | ||
| * [[http:// | * [[http:// | ||
| Line 235: | Line 200: | ||
| * [[https:// | * [[https:// | ||
| - | ===== Tags ===== | ||
| - | {{tag> | ||