mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
To: Horatiu Vultur <horatiu.vultur@microchip.com>,
	davem@davemloft.net, jiri@resnulli.us, ivecera@redhat.com,
	kuba@kernel.org, roopa@cumulusnetworks.com, olteanv@gmail.com,
	andrew@lunn.ch, UNGLinuxDriver@microchip.com,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	bridge@lists.linux-foundation.org
Subject: Re: [PATCH net-next v3 05/11] bridge: mrp: Add MRP interface.
Date: Fri, 24 Apr 2020 16:13:19 +0300	[thread overview]
Message-ID: <67f65f7e-9c1e-a420-b527-bc379f9563c1@cumulusnetworks.com> (raw)
In-Reply-To: <20200422161833.1123-6-horatiu.vultur@microchip.com>

On 22/04/2020 19:18, Horatiu Vultur wrote:
> Define the MRP interface.
> This interface is used by the netlink to update the MRP instances and by the MRP
> to make the calls to switchdev to offload it to HW.
> 
> It defines an MRP instance 'struct br_mrp' which is a list of MRP instances.
> Which will be part of the 'struct net_bridge'. Each instance has 2 ring ports,
> a bridge and an ID.
> 
> In case the HW can't generate MRP Test frames then the SW will generate those.
> 
> br_mrp_add - adds a new MRP instance.
> 
> br_mrp_del - deletes an existing MRP instance. Each instance has an ID(ring_id).
> 
> br_mrp_set_port_state - changes the port state. The port can be in forwarding
>   state, which means that the frames can pass through or in blocked state which
>   means that the frames can't pass through except MRP frames. This will
>   eventually call the switchdev API to notify the HW. This information is used
>   also by the SW bridge to know how to forward frames in case the HW doesn't
>   have this capability.
> 
> br_mrp_set_port_role - a port role can be primary or secondary. This
>   information is required to be pushed to HW in case the HW can generate
>   MRP_Test frames.  Because the MRP_Test frames contains a file with this
>   information. Otherwise the HW will not be able to generate the frames
>   correctly.
> 
> br_mrp_set_ring_state - a ring can be in state open or closed. State open means
>   that the mrp port stopped receiving MRP_Test frames, while closed means that
>   the mrp port received MRP_Test frames. Similar with br_mrp_port_role, this
>   information is pushed in HW because the MRP_Test frames contain this
>   information.
> 
> br_mrp_set_ring_role - a ring can have the following roles MRM or MRC. For the
>   role MRM it is expected that the HW can terminate the MRP frames, notify the
>   SW that it stopped receiving MRP_Test frames and trapp all the other MRP
>   frames.  While for MRC mode it is expected that the HW can forward the MRP
>   frames only between the MRP ports and copy MRP_Topology frames to CPU. In
>   case the HW doesn't support a role it needs to return an error code different
>   than -EOPNOTSUPP.
> 
> br_mrp_start_test - this starts/stops the generation of MRP_Test frames. To stop
>   the generation of frames the interval needs to have a value of 0. In this case
>   the userspace needs to know if the HW supports this or not. Not to have
>   duplicate frames(generated by HW and SW). Because if the HW supports this then
>   the SW will not generate anymore frames and will expect that the HW will
>   notify when it stopped receiving MRP frames using the function
>   br_mrp_port_open.
> 
> br_mrp_port_open - this function is used by drivers to notify the userspace via
>   a netlink callback that one of the ports stopped receiving MRP_Test frames.
>   This function is called only when the node has the role MRM. It is not
>   supposed to be called from userspace.
> 
> br_mrp_port_switchdev_add - this corresponds to the function br_mrp_add,
>   and will notify the HW that a MRP instance is added. The function gets
>   as parameter the MRP instance.
> 
> br_mrp_port_switchdev_del - this corresponds to the function br_mrp_del,
>   and will notify the HW that a MRP instance is removed. The function
>   gets as parameter the ID of the MRP instance that is removed.
> 
> br_mrp_port_switchdev_set_state - this corresponds to the function
>   br_mrp_set_port_state. It would notify the HW if it should block or not
>   non-MRP frames.
> 
> br_mrp_port_switchdev_set_port - this corresponds to the function
>   br_mrp_set_port_role. It would set the port role, primary or secondary.
> 
> br_mrp_switchdev_set_role - this corresponds to the function
>   br_mrp_set_ring_role and would set one of the role MRM or MRC.
> 
> br_mrp_switchdev_set_ring_state - this corresponds to the function
>   br_mrp_set_ring_state and would set the ring to be open or closed.
> 
> br_mrp_switchdev_send_ring_test - this corresponds to the function
>   br_mrp_start_test. This will notify the HW to start or stop generating
>   MRP_Test frames. Value 0 for the interval parameter means to stop generating
>   the frames.
> 
> br_mrp_port_open - this function is used to notify the userspace that the port
>   lost the continuity of MRP Test frames.
> 
> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
> ---
>  net/bridge/br_private_mrp.h | 63 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 63 insertions(+)
>  create mode 100644 net/bridge/br_private_mrp.h
> 

Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>



  reply	other threads:[~2020-04-24 13:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-22 16:18 [PATCH net-next v3 00/11] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP) Horatiu Vultur
2020-04-22 16:18 ` [PATCH net-next v3 01/11] bridge: uapi: mrp: Add mrp attributes Horatiu Vultur
2020-04-24 13:11   ` Nikolay Aleksandrov
2020-04-22 16:18 ` [PATCH net-next v3 02/11] bridge: mrp: Update Kconfig Horatiu Vultur
2020-04-24 13:11   ` Nikolay Aleksandrov
2020-04-22 16:18 ` [PATCH net-next v3 03/11] bridge: mrp: Extend bridge interface Horatiu Vultur
2020-04-24 13:11   ` Nikolay Aleksandrov
2020-04-22 16:18 ` [PATCH net-next v3 04/11] net: bridge: Add port attribute IFLA_BRPORT_MRP_RING_OPEN Horatiu Vultur
2020-04-24 13:12   ` Nikolay Aleksandrov
2020-04-22 16:18 ` [PATCH net-next v3 05/11] bridge: mrp: Add MRP interface Horatiu Vultur
2020-04-24 13:13   ` Nikolay Aleksandrov [this message]
2020-04-22 16:18 ` [PATCH net-next v3 06/11] switchdev: mrp: Extend switchdev API to offload MRP Horatiu Vultur
2020-04-22 16:18 ` [PATCH net-next v3 07/11] bridge: switchdev: mrp: Implement MRP API for switchdev Horatiu Vultur
2020-04-22 16:18 ` [PATCH net-next v3 08/11] bridge: mrp: Connect MRP API with the switchdev API Horatiu Vultur
2020-04-24 13:47   ` Nikolay Aleksandrov
2020-04-25  8:57     ` Horatiu Vultur
2020-04-22 16:18 ` [PATCH net-next v3 09/11] bridge: mrp: Implement netlink interface to configure MRP Horatiu Vultur
2020-04-22 16:18 ` [PATCH net-next v3 10/11] bridge: mrp: Integrate MRP into the bridge Horatiu Vultur
2020-04-24 13:49   ` Nikolay Aleksandrov
2020-04-22 16:18 ` [PATCH net-next v3 11/11] net: bridge: Add checks for enabling the STP Horatiu Vultur
2020-04-24 13:20   ` Nikolay Aleksandrov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=67f65f7e-9c1e-a420-b527-bc379f9563c1@cumulusnetworks.com \
    --to=nikolay@cumulusnetworks.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=horatiu.vultur@microchip.com \
    --cc=ivecera@redhat.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=roopa@cumulusnetworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®