From: Horatiu Vultur <horatiu.vultur@microchip.com> To: Andrew Lunn <andrew@lunn.ch> Cc: <linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>, <bridge@lists.linux-foundation.org>, <davem@davemloft.net>, <roopa@cumulusnetworks.com>, <nikolay@cumulusnetworks.com>, <jakub.kicinski@netronome.com>, <vivien.didelot@gmail.com>, <olteanv@gmail.com>, <anirudh.venkataramanan@intel.com>, <dsahern@gmail.com>, <jiri@resnulli.us>, <ivecera@redhat.com>, <UNGLinuxDriver@microchip.com> Subject: Re: [RFC net-next Patch v2 4/4] net: bridge: mrp: switchdev: Add HW offload Date: Tue, 14 Jan 2020 17:46:15 +0100 [thread overview] Message-ID: <20200114164615.yvidcidrj24x4gcy@soft-dev3.microsemi.net> (raw) In-Reply-To: <20200114132047.GG11788@lunn.ch> The 01/14/2020 14:20, Andrew Lunn wrote: > > On Tue, Jan 14, 2020 at 09:08:56AM +0100, Horatiu Vultur wrote: > > The 01/14/2020 00:30, Andrew Lunn wrote: > > > > > > Hi Horatiu > > > > > > It has been said a few times what the basic state machine should be in > > > user space. A pure software solution can use raw sockets to send and > > > receive MRP_Test test frames. When considering hardware acceleration, > > > the switchdev API you have proposed here seems quite simple. It should > > > not be too hard to map it to a set of netlink messages from userspace. > > > > Yes and we will try to go with this approach, to have a user space > > application that contains the state machines and then in the kernel to > > extend the netlink messages to map to the switchdev API. > > So we will create a new RFC once we will have the user space and the > > definition of the netlink messages. > > Cool. > > Before you get too far, we might want to discuss exactly how you pass > these netlink messages. Do we want to make this part of the new > ethtool Netlink implementation? Part of devlink? Extend the current > bridge netlink interface used by userspae RSTP daemons? A new generic > netlink socket? We are not yet 100% sure. We were thinking to choose between extending the bridge netlink interface or adding a new netlink socket. I was leaning to create a new netlink socket, because I think that would be clearer and easier to understand. But I don't have much experience with this, so in both cases I need to sit down and actually try to implement it to see exactly. > > Extending the bridge netlink interface might seem the most logical. > The argument against it, is that the kernel bridge code probably does > not need to know anything about this offloading. But it does allow you > to make use of the switchdev API, so we have a uniform API between the > network stack and drivers implementing offloading. > > Andrew -- /Horatiu
WARNING: multiple messages have this Message-ID (diff)
From: Horatiu Vultur <horatiu.vultur@microchip.com> To: Andrew Lunn <andrew@lunn.ch> Cc: ivecera@redhat.com, jakub.kicinski@netronome.com, nikolay@cumulusnetworks.com, netdev@vger.kernel.org, roopa@cumulusnetworks.com, bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org, vivien.didelot@gmail.com, UNGLinuxDriver@microchip.com, anirudh.venkataramanan@intel.com, dsahern@gmail.com, jiri@resnulli.us, olteanv@gmail.com, davem@davemloft.net Subject: Re: [Bridge] [RFC net-next Patch v2 4/4] net: bridge: mrp: switchdev: Add HW offload Date: Tue, 14 Jan 2020 17:46:15 +0100 [thread overview] Message-ID: <20200114164615.yvidcidrj24x4gcy@soft-dev3.microsemi.net> (raw) In-Reply-To: <20200114132047.GG11788@lunn.ch> The 01/14/2020 14:20, Andrew Lunn wrote: > > On Tue, Jan 14, 2020 at 09:08:56AM +0100, Horatiu Vultur wrote: > > The 01/14/2020 00:30, Andrew Lunn wrote: > > > > > > Hi Horatiu > > > > > > It has been said a few times what the basic state machine should be in > > > user space. A pure software solution can use raw sockets to send and > > > receive MRP_Test test frames. When considering hardware acceleration, > > > the switchdev API you have proposed here seems quite simple. It should > > > not be too hard to map it to a set of netlink messages from userspace. > > > > Yes and we will try to go with this approach, to have a user space > > application that contains the state machines and then in the kernel to > > extend the netlink messages to map to the switchdev API. > > So we will create a new RFC once we will have the user space and the > > definition of the netlink messages. > > Cool. > > Before you get too far, we might want to discuss exactly how you pass > these netlink messages. Do we want to make this part of the new > ethtool Netlink implementation? Part of devlink? Extend the current > bridge netlink interface used by userspae RSTP daemons? A new generic > netlink socket? We are not yet 100% sure. We were thinking to choose between extending the bridge netlink interface or adding a new netlink socket. I was leaning to create a new netlink socket, because I think that would be clearer and easier to understand. But I don't have much experience with this, so in both cases I need to sit down and actually try to implement it to see exactly. > > Extending the bridge netlink interface might seem the most logical. > The argument against it, is that the kernel bridge code probably does > not need to know anything about this offloading. But it does allow you > to make use of the switchdev API, so we have a uniform API between the > network stack and drivers implementing offloading. > > Andrew -- /Horatiu
next prev parent reply other threads:[~2020-01-14 16:46 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-13 12:46 [RFC net-next Patch v2 0/4] net: bridge: mrp: Add support for Media Redundancy Protocol(MRP) Horatiu Vultur 2020-01-13 12:46 ` [Bridge] " Horatiu Vultur 2020-01-13 12:46 ` [RFC net-next Patch v2 1/4] net: bridge: mrp: Add support for Media Redundancy Protocol Horatiu Vultur 2020-01-13 12:46 ` [Bridge] " Horatiu Vultur 2020-01-13 12:46 ` [RFC net-next Patch v2 2/4] net: bridge: mrp: Integrate MRP into the bridge Horatiu Vultur 2020-01-13 12:46 ` [Bridge] " Horatiu Vultur 2020-01-13 12:46 ` [RFC net-next Patch v2 3/4] net: bridge: mrp: Add netlink support to configure MRP Horatiu Vultur 2020-01-13 12:46 ` [Bridge] " Horatiu Vultur 2020-01-13 12:46 ` [RFC net-next Patch v2 4/4] net: bridge: mrp: switchdev: Add HW offload Horatiu Vultur 2020-01-13 12:46 ` [Bridge] " Horatiu Vultur 2020-01-13 14:00 ` Andrew Lunn 2020-01-13 14:00 ` [Bridge] " Andrew Lunn 2020-01-13 22:57 ` Horatiu Vultur 2020-01-13 22:57 ` [Bridge] " Horatiu Vultur 2020-01-13 23:30 ` Andrew Lunn 2020-01-13 23:30 ` [Bridge] " Andrew Lunn 2020-01-14 8:08 ` Horatiu Vultur 2020-01-14 8:08 ` [Bridge] " Horatiu Vultur 2020-01-14 13:20 ` Andrew Lunn 2020-01-14 13:20 ` [Bridge] " Andrew Lunn 2020-01-14 16:46 ` Horatiu Vultur [this message] 2020-01-14 16:46 ` Horatiu Vultur
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=20200114164615.yvidcidrj24x4gcy@soft-dev3.microsemi.net \ --to=horatiu.vultur@microchip.com \ --cc=UNGLinuxDriver@microchip.com \ --cc=andrew@lunn.ch \ --cc=anirudh.venkataramanan@intel.com \ --cc=bridge@lists.linux-foundation.org \ --cc=davem@davemloft.net \ --cc=dsahern@gmail.com \ --cc=ivecera@redhat.com \ --cc=jakub.kicinski@netronome.com \ --cc=jiri@resnulli.us \ --cc=linux-kernel@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=nikolay@cumulusnetworks.com \ --cc=olteanv@gmail.com \ --cc=roopa@cumulusnetworks.com \ --cc=vivien.didelot@gmail.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.