From: Horatiu Vultur <horatiu.vultur@microchip.com>
To: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Cc: <roopa@cumulusnetworks.com>, <davem@davemloft.net>,
<kuba@kernel.org>, <andrew@lunn.ch>,
<UNGLinuxDriver@microchip.com>,
<bridge@lists.linux-foundation.org>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: MRP netlink interface
Date: Mon, 25 May 2020 11:48:07 +0000 [thread overview]
Message-ID: <20200525114807.w7g77ybflb67en3h@soft-dev3.localdomain> (raw)
In-Reply-To: <2176b58f-35f3-36c1-8ba7-d18649eb29f7@cumulusnetworks.com>
The 05/25/2020 12:33, Nikolay Aleksandrov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On 25/05/2020 14:28, Horatiu Vultur wrote:
> > Hi,
> >
> > While I was working on adding support for MRA role to MRP, I noticed that I
> > might have some issues with the netlink interface, so it would be great if you
> > can give me an advice on how to continue.
> >
> > First a node with MRA role can behave as a MRM(Manager) or as a
> > MRC(Client). The behaviour is decided by the priority of each node. So
> > to have this functionality I have to extend the MRP netlink interface
> > and this brings me to my issues.
> >
> > My first approach was to extend the 'struct br_mrp_instance' with a field that
> > contains the priority of the node. But this breaks the backwards compatibility,
> > and then every time when I need to change something, I will break the backwards
> > compatibility. Is this a way to go forward?
> >
> > Another approach is to restructure MRP netlink interface. What I was thinking to
> > keep the current attributes (IFLA_BRIDGE_MRP_INSTANCE,
> > IFLA_BRIDGE_MRP_PORT_STATE,...) but they will be nested attributes and each of
> > this attribute to contain the fields of the structures they represents.
> > For example:
> > [IFLA_AF_SPEC] = {
> > [IFLA_BRIDGE_FLAGS]
> > [IFLA_BRIDGE_MRP]
> > [IFLA_BRIDGE_MRP_INSTANCE]
> > [IFLA_BRIDGE_MRP_INSTANCE_RING_ID]
> > [IFLA_BRIDGE_MRP_INSTANCE_P_IFINDEX]
> > [IFLA_BRIDGE_MRP_INSTANCE_S_IFINDEX]
> > [IFLA_BRIDGE_MRP_RING_ROLE]
> > [IFLA_BRIDGE_MRP_RING_ROLE_RING_ID]
> > [IFLA_BRIDGE_MRP_RING_ROLE_ROLE]
> > ...
> > }
> > And then I can parse each field separately and then fill up the structure
> > (br_mrp_instance, br_mrp_port_role, ...) which will be used forward.
> > Then when this needs to be extended with the priority it would have the
> > following format:
> > [IFLA_AF_SPEC] = {
> > [IFLA_BRIDGE_FLAGS]
> > [IFLA_BRIDGE_MRP]
> > [IFLA_BRIDGE_MRP_INSTANCE]
> > [IFLA_BRIDGE_MRP_INSTANCE_RING_ID]
> > [IFLA_BRIDGE_MRP_INSTANCE_P_IFINDEX]
> > [IFLA_BRIDGE_MRP_INSTANCE_S_IFINDEX]
> > [IFLA_BRIDGE_MRP_INSTANCE_PRIO]
> > [IFLA_BRIDGE_MRP_RING_ROLE]
> > [IFLA_BRIDGE_MRP_RING_ROLE_RING_ID]
> > [IFLA_BRIDGE_MRP_RING_ROLE_ROLE]
> > ...
> > }
> > And also the br_mrp_instance will have a field called prio.
> > So now, if the userspace is not updated to have support for setting the prio
> > then the kernel will use a default value. Then if the userspace contains a field
> > that the kernel doesn't know about, then it would just ignore it.
> > So in this way every time when the netlink interface will be extended it would
> > be backwards compatible.
> >
> > If it is not possible to break the compatibility then the safest way is to
> > just add more attributes under IFLA_BRIDGE_MRP but this would just complicate
> > the kernel and the userspace and it would make it much harder to be extended in
> > the future.
> >
> > My personal choice would be the second approach, even if it breaks the backwards
> > compatibility. Because it is the easier to go forward and there are only 3
> > people who cloned the userspace application
> > (https://github.com/microchip-ung/mrp/graphs/traffic). And two of
> > these unique cloners is me and Allan.
> >
> > So if you have any advice on how to go forward it would be great.
> >
>
> IIRC this is still in net-next only, right? If so - now would be the time to change it.
> Once it goes into a release, we'll be stuck with workarounds. So I'd go for solution 2).
Yes, this is only in net-next. Then I should ASAP update this with
solution 2.
>
> I haven't cloned it, but I do sync your user-space mrp repo to check against the patches. :)
>
--
/Horatiu
next prev parent reply other threads:[~2020-05-25 9:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-25 11:28 MRP netlink interface Horatiu Vultur
2020-05-25 9:33 ` Nikolay Aleksandrov
2020-05-25 11:48 ` Horatiu Vultur [this message]
2020-05-25 10:03 ` Michal Kubecek
2020-05-25 10:26 ` Nikolay Aleksandrov
2020-05-25 13:14 ` Horatiu Vultur
2020-05-25 13:18 ` Michal Kubecek
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=20200525114807.w7g77ybflb67en3h@soft-dev3.localdomain \
--to=horatiu.vultur@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.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;
as well as URLs for NNTP newsgroup(s).