From: Horatiu Vultur <horatiu.vultur@microchip.com> To: Vladimir Oltean <vladimir.oltean@nxp.com> Cc: "davem@davemloft.net" <davem@davemloft.net>, "kuba@kernel.org" <kuba@kernel.org>, "jiri@resnulli.us" <jiri@resnulli.us>, "ivecera@redhat.com" <ivecera@redhat.com>, "nikolay@nvidia.com" <nikolay@nvidia.com>, "roopa@nvidia.com" <roopa@nvidia.com>, Claudiu Manoil <claudiu.manoil@nxp.com>, "alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>, "UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>, "andrew@lunn.ch" <andrew@lunn.ch>, "vivien.didelot@gmail.com" <vivien.didelot@gmail.com>, "f.fainelli@gmail.com" <f.fainelli@gmail.com>, "rasmus.villemoes@prevas.dk" <rasmus.villemoes@prevas.dk>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "bridge@lists.linux-foundation.org" <bridge@lists.linux-foundation.org> Subject: Re: [PATCH net-next v4 2/8] switchdev: mrp: Extend ring_role_mrp and in_role_mrp Date: Wed, 17 Feb 2021 16:58:45 +0100 [thread overview] Message-ID: <20210217155845.oegbmsnxykkqc6um@soft-dev3.localdomain> (raw) In-Reply-To: <20210217103433.bilnuo2tfvgvjmxy@skbuf> The 02/17/2021 10:34, Vladimir Oltean wrote: Hi Vladimir, > > On Tue, Feb 16, 2021 at 10:41:59PM +0100, Horatiu Vultur wrote: > > Add the member sw_backup to the structures switchdev_obj_ring_role_mrp > > and switchdev_obj_in_role_mrp. In this way the SW can call the driver in > > 2 ways, once when sw_backup is set to false, meaning that the driver > > should implement this completely in HW. And if that is not supported the > > SW will call again but with sw_backup set to true, meaning that the > > HW should help or allow the SW to run the protocol. > > > > For example when role is MRM, if the HW can't detect when it stops > > receiving MRP Test frames but it can trap these frames to CPU, then it > > needs to return -EOPNOTSUPP when sw_backup is false and return 0 when > > sw_backup is true. > > > > Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> > > --- > > include/net/switchdev.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/include/net/switchdev.h b/include/net/switchdev.h > > index 465362d9d063..b7fc7d0f54e2 100644 > > --- a/include/net/switchdev.h > > +++ b/include/net/switchdev.h > > @@ -127,6 +127,7 @@ struct switchdev_obj_ring_role_mrp { > > struct switchdev_obj obj; > > u8 ring_role; > > u32 ring_id; > > + u8 sw_backup; > > }; > > > > #define SWITCHDEV_OBJ_RING_ROLE_MRP(OBJ) \ > > @@ -161,6 +162,7 @@ struct switchdev_obj_in_role_mrp { > > u32 ring_id; > > u16 in_id; > > u8 in_role; > > + u8 sw_backup; > > What was wrong with 'bool'? Yeah, that would be a better match. > > > }; > > > > #define SWITCHDEV_OBJ_IN_ROLE_MRP(OBJ) \ > > -- > > 2.27.0 > > > > If a driver implements full MRP offload for a ring/interconnect > manager/automanager, should it return -EOPNOTSUPP when sw_backup=false? In that case it should return 0. So if the driver can: - fully support MRP, when sw_backup = false, return 0. Then end of story. - partially support MRP, when sw_backup = false, return -EOPNOTSUPP, when sw_backup = true, return 0. - no support at all, return -EOPNOTSUPP. -- /Horatiu
WARNING: multiple messages have this Message-ID (diff)
From: Horatiu Vultur <horatiu.vultur@microchip.com> To: Vladimir Oltean <vladimir.oltean@nxp.com> Cc: "ivecera@redhat.com" <ivecera@redhat.com>, "andrew@lunn.ch" <andrew@lunn.ch>, "alexandre.belloni@bootlin.com" <alexandre.belloni@bootlin.com>, "f.fainelli@gmail.com" <f.fainelli@gmail.com>, "jiri@resnulli.us" <jiri@resnulli.us>, "rasmus.villemoes@prevas.dk" <rasmus.villemoes@prevas.dk>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "bridge@lists.linux-foundation.org" <bridge@lists.linux-foundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "vivien.didelot@gmail.com" <vivien.didelot@gmail.com>, "UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>, Claudiu Manoil <claudiu.manoil@nxp.com>, "nikolay@nvidia.com" <nikolay@nvidia.com>, "roopa@nvidia.com" <roopa@nvidia.com>, "kuba@kernel.org" <kuba@kernel.org>, "davem@davemloft.net" <davem@davemloft.net> Subject: Re: [Bridge] [PATCH net-next v4 2/8] switchdev: mrp: Extend ring_role_mrp and in_role_mrp Date: Wed, 17 Feb 2021 16:58:45 +0100 [thread overview] Message-ID: <20210217155845.oegbmsnxykkqc6um@soft-dev3.localdomain> (raw) In-Reply-To: <20210217103433.bilnuo2tfvgvjmxy@skbuf> The 02/17/2021 10:34, Vladimir Oltean wrote: Hi Vladimir, > > On Tue, Feb 16, 2021 at 10:41:59PM +0100, Horatiu Vultur wrote: > > Add the member sw_backup to the structures switchdev_obj_ring_role_mrp > > and switchdev_obj_in_role_mrp. In this way the SW can call the driver in > > 2 ways, once when sw_backup is set to false, meaning that the driver > > should implement this completely in HW. And if that is not supported the > > SW will call again but with sw_backup set to true, meaning that the > > HW should help or allow the SW to run the protocol. > > > > For example when role is MRM, if the HW can't detect when it stops > > receiving MRP Test frames but it can trap these frames to CPU, then it > > needs to return -EOPNOTSUPP when sw_backup is false and return 0 when > > sw_backup is true. > > > > Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> > > --- > > include/net/switchdev.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/include/net/switchdev.h b/include/net/switchdev.h > > index 465362d9d063..b7fc7d0f54e2 100644 > > --- a/include/net/switchdev.h > > +++ b/include/net/switchdev.h > > @@ -127,6 +127,7 @@ struct switchdev_obj_ring_role_mrp { > > struct switchdev_obj obj; > > u8 ring_role; > > u32 ring_id; > > + u8 sw_backup; > > }; > > > > #define SWITCHDEV_OBJ_RING_ROLE_MRP(OBJ) \ > > @@ -161,6 +162,7 @@ struct switchdev_obj_in_role_mrp { > > u32 ring_id; > > u16 in_id; > > u8 in_role; > > + u8 sw_backup; > > What was wrong with 'bool'? Yeah, that would be a better match. > > > }; > > > > #define SWITCHDEV_OBJ_IN_ROLE_MRP(OBJ) \ > > -- > > 2.27.0 > > > > If a driver implements full MRP offload for a ring/interconnect > manager/automanager, should it return -EOPNOTSUPP when sw_backup=false? In that case it should return 0. So if the driver can: - fully support MRP, when sw_backup = false, return 0. Then end of story. - partially support MRP, when sw_backup = false, return -EOPNOTSUPP, when sw_backup = true, return 0. - no support at all, return -EOPNOTSUPP. -- /Horatiu
next prev parent reply other threads:[~2021-02-17 16:00 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-16 21:41 [PATCH net-next v4 0/8] bridge: mrp: Extend br_mrp_switchdev_* Horatiu Vultur 2021-02-16 21:41 ` [Bridge] " Horatiu Vultur 2021-02-16 21:41 ` [PATCH net-next v4 1/8] switchdev: mrp: Remove CONFIG_BRIDGE_MRP Horatiu Vultur 2021-02-16 21:41 ` [Bridge] " Horatiu Vultur 2021-02-17 10:26 ` Vladimir Oltean 2021-02-17 10:26 ` [Bridge] " Vladimir Oltean 2021-02-16 21:41 ` [PATCH net-next v4 2/8] switchdev: mrp: Extend ring_role_mrp and in_role_mrp Horatiu Vultur 2021-02-16 21:41 ` [Bridge] " Horatiu Vultur 2021-02-17 10:34 ` Vladimir Oltean 2021-02-17 10:34 ` [Bridge] " Vladimir Oltean 2021-02-17 15:58 ` Horatiu Vultur [this message] 2021-02-17 15:58 ` Horatiu Vultur 2021-02-17 16:09 ` Vladimir Oltean 2021-02-17 16:09 ` [Bridge] " Vladimir Oltean 2021-02-16 21:42 ` [PATCH net-next v4 3/8] bridge: mrp: Add 'enum br_mrp_hw_support' Horatiu Vultur 2021-02-16 21:42 ` [Bridge] " Horatiu Vultur 2021-02-16 21:42 ` [PATCH net-next v4 4/8] bridge: mrp: Extend br_mrp_switchdev to detect better the errors Horatiu Vultur 2021-02-16 21:42 ` [Bridge] " Horatiu Vultur 2021-02-17 10:56 ` Vladimir Oltean 2021-02-17 10:56 ` [Bridge] " Vladimir Oltean 2021-02-17 16:02 ` Horatiu Vultur 2021-02-17 16:02 ` [Bridge] " Horatiu Vultur 2021-02-16 21:42 ` [PATCH net-next v4 5/8] bridge: mrp: Update br_mrp to use new return values of br_mrp_switchdev Horatiu Vultur 2021-02-16 21:42 ` [Bridge] " Horatiu Vultur 2021-02-17 10:59 ` Vladimir Oltean 2021-02-17 10:59 ` [Bridge] " Vladimir Oltean 2021-02-17 16:18 ` Horatiu Vultur 2021-02-17 16:18 ` [Bridge] " Horatiu Vultur 2021-02-16 21:42 ` [PATCH net-next v4 6/8] net: mscc: ocelot: Add support for MRP Horatiu Vultur 2021-02-16 21:42 ` [Bridge] " Horatiu Vultur 2021-02-17 11:14 ` Vladimir Oltean 2021-02-17 11:14 ` [Bridge] " Vladimir Oltean 2021-02-17 16:25 ` Horatiu Vultur 2021-02-17 16:25 ` [Bridge] " Horatiu Vultur 2021-02-17 11:51 ` Vladimir Oltean 2021-02-17 11:51 ` [Bridge] " Vladimir Oltean 2021-02-16 21:42 ` [PATCH net-next v4 7/8] net: dsa: add MRP support Horatiu Vultur 2021-02-16 21:42 ` [Bridge] " Horatiu Vultur 2021-02-17 11:23 ` Vladimir Oltean 2021-02-17 11:23 ` [Bridge] " Vladimir Oltean 2021-02-16 21:42 ` [PATCH net-next v4 8/8] net: dsa: felix: Add support for MRP Horatiu Vultur 2021-02-16 21:42 ` [Bridge] " Horatiu Vultur 2021-02-17 10:24 ` Vladimir Oltean 2021-02-17 10:24 ` [Bridge] " Vladimir Oltean 2021-02-16 23:00 ` [PATCH net-next v4 0/8] bridge: mrp: Extend br_mrp_switchdev_* patchwork-bot+netdevbpf 2021-02-16 23:00 ` [Bridge] " patchwork-bot+netdevbpf
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=20210217155845.oegbmsnxykkqc6um@soft-dev3.localdomain \ --to=horatiu.vultur@microchip.com \ --cc=UNGLinuxDriver@microchip.com \ --cc=alexandre.belloni@bootlin.com \ --cc=andrew@lunn.ch \ --cc=bridge@lists.linux-foundation.org \ --cc=claudiu.manoil@nxp.com \ --cc=davem@davemloft.net \ --cc=f.fainelli@gmail.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=nikolay@nvidia.com \ --cc=rasmus.villemoes@prevas.dk \ --cc=roopa@nvidia.com \ --cc=vivien.didelot@gmail.com \ --cc=vladimir.oltean@nxp.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.