Message ID | 20210316112419.1304230-10-olteanv@gmail.com (mailing list archive) |
---|---|
State | Accepted |
Commit | f8f3c20af1ea27989e01dfc11a3136b380eb6120 |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | Documentation updates for switchdev and DSA | expand |
Context | Check | Description |
---|---|---|
netdev/cover_letter | success | Link |
netdev/fixes_present | success | Link |
netdev/patch_count | success | Link |
netdev/tree_selection | success | Clearly marked for net-next |
netdev/subject_prefix | success | Link |
netdev/cc_maintainers | warning | 5 maintainers not CCed: linux-doc@vger.kernel.org rdunlap@infradead.org corbet@lwn.net davem@davemloft.net kuba@kernel.org |
netdev/source_inline | success | Was 0 now: 0 |
netdev/verify_signedoff | success | Link |
netdev/module_param | success | Was 0 now: 0 |
netdev/build_32bit | success | Errors and warnings before: 0 this patch: 0 |
netdev/kdoc | success | Errors and warnings before: 0 this patch: 0 |
netdev/verify_fixes | success | Link |
netdev/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 36 lines checked |
netdev/build_allmodconfig_warn | success | Errors and warnings before: 0 this patch: 0 |
netdev/header_inline | success | Link |
The 03/16/2021 13:24, Vladimir Oltean wrote: > > From: Vladimir Oltean <vladimir.oltean@nxp.com> > > Add a short summary of the methods that a driver writer must implement > for getting an MRP instance to work on top of a DSA switch. > > Cc: Horatiu Vultur <horatiu.vultur@microchip.com> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> > --- > Documentation/networking/dsa/dsa.rst | 30 ++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > > diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst > index e8576e81735c..0daafa2fb9eb 100644 > --- a/Documentation/networking/dsa/dsa.rst > +++ b/Documentation/networking/dsa/dsa.rst > @@ -757,6 +757,36 @@ can optionally populate ``ds->num_lag_ids`` from the ``dsa_switch_ops::setup`` > method. The LAG ID associated with a bonding/team interface can then be > retrieved by a DSA switch driver using the ``dsa_lag_id`` function. > > +IEC 62439-2 (MRP) > +----------------- > + > +The Media Redundancy Protocol is a topology management protocol optimized for > +fast fault recovery time for ring networks, which has some components > +implemented as a function of the bridge driver. MRP uses management PDUs > +(Test, Topology, LinkDown/Up, Option) sent at a multicast destination MAC > +address range of 01:15:4e:00:00:0x and with an EtherType of 0x88e3. > +Depending on the node's role in the ring (MRM: Media Redundancy Manager, > +MRC: Media Redundancy Client, MRA: Media Redundancy Automanager), certain MRP > +PDUs might need to be terminated locally and others might need to be forwarded. > +An MRM might also benefit from offloading to hardware the creation and > +transmission of certain MRP PDUs (Test). > + > +Normally an MRP instance can be created on top of any network interface, > +however in the case of a device with an offloaded data path such as DSA, it is > +necessary for the hardware, even if it is not MRP-aware, to be able to extract > +the MRP PDUs from the fabric before the driver can proceed with the software > +implementation. DSA today has no driver which is MRP-aware, therefore it only > +listens for the bare minimum switchdev objects required for the software assist > +to work properly. The operations are detailed below. > + > +- ``port_mrp_add`` and ``port_mrp_del``: notifies driver when an MRP instance > + with a certain ring ID, priority, primary port and secondary port is > + created/deleted. > +- ``port_mrp_add_ring_role`` and ``port_mrp_del_ring_role``: function invoked > + when an MRP instance changes ring roles between MRM or MRC. This affects > + which MRP PDUs should be trapped to software and which should be autonomously > + forwarded. > + > TODO > ==== > > -- > 2.25.1 > Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com>
diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index e8576e81735c..0daafa2fb9eb 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -757,6 +757,36 @@ can optionally populate ``ds->num_lag_ids`` from the ``dsa_switch_ops::setup`` method. The LAG ID associated with a bonding/team interface can then be retrieved by a DSA switch driver using the ``dsa_lag_id`` function. +IEC 62439-2 (MRP) +----------------- + +The Media Redundancy Protocol is a topology management protocol optimized for +fast fault recovery time for ring networks, which has some components +implemented as a function of the bridge driver. MRP uses management PDUs +(Test, Topology, LinkDown/Up, Option) sent at a multicast destination MAC +address range of 01:15:4e:00:00:0x and with an EtherType of 0x88e3. +Depending on the node's role in the ring (MRM: Media Redundancy Manager, +MRC: Media Redundancy Client, MRA: Media Redundancy Automanager), certain MRP +PDUs might need to be terminated locally and others might need to be forwarded. +An MRM might also benefit from offloading to hardware the creation and +transmission of certain MRP PDUs (Test). + +Normally an MRP instance can be created on top of any network interface, +however in the case of a device with an offloaded data path such as DSA, it is +necessary for the hardware, even if it is not MRP-aware, to be able to extract +the MRP PDUs from the fabric before the driver can proceed with the software +implementation. DSA today has no driver which is MRP-aware, therefore it only +listens for the bare minimum switchdev objects required for the software assist +to work properly. The operations are detailed below. + +- ``port_mrp_add`` and ``port_mrp_del``: notifies driver when an MRP instance + with a certain ring ID, priority, primary port and secondary port is + created/deleted. +- ``port_mrp_add_ring_role`` and ``port_mrp_del_ring_role``: function invoked + when an MRP instance changes ring roles between MRM or MRC. This affects + which MRP PDUs should be trapped to software and which should be autonomously + forwarded. + TODO ====