| Message ID | 20210310121452.552070-1-ciorneiioana@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | dpaa2-switch: CPU terminated traffic and move out of staging | expand |
On Wed, Mar 10, 2021 at 02:14:37PM +0200, Ioana Ciornei wrote: > From: Ioana Ciornei <ioana.ciornei@nxp.com> > > This patch set adds support for Rx/Tx capabilities on DPAA2 switch port > interfaces as well as fixing up some major blunders in how we take care > of the switching domains. The last patch actually moves the driver out > of staging now that the minimum requirements are met. > > I am sending this directly towards the net-next tree so that I can use > the rest of the development cycle adding new features on top of the > current driver without worrying about merge conflicts between the > staging and net-next tree. > > The control interface is comprised of 3 queues in total: Rx, Rx error > and Tx confirmation. In this patch set we only enable Rx and Tx conf. > All switch ports share the same queues when frames are redirected to the > CPU. Information regarding the ingress switch port is passed through > frame metadata - the flow context field of the descriptor. > > NAPI instances are also shared between switch net_devices and are > enabled when at least on one of the switch ports .dev_open() was called > and disabled when no switch port is still up. > > Since the last version of this feature was submitted to the list, I > reworked how the switching and flooding domains are taken care of by the > driver, thus the switch is now able to also add the control port (the > queues that the CPU can dequeue from) into the flooding domains of a > port (broadcast, unknown unicast etc). With this, we are able to receive > and sent traffic from the switch interfaces. > > Also, the capability to properly partition the DPSW object into multiple > switching domains was added so that when not under a bridge, the ports > are not actually capable to switch between them. This is possible by > adding a private FDB table per switch interface. When multiple switch > interfaces are under the same bridge, they will all use the same FDB > table. > > Another thing that is fixed in this patch set is how the driver handles > VLAN awareness. The DPAA2 switch is not capable to run as VLAN unaware > but this was not reflected in how the driver responded to requests to > change the VLAN awareness. In the last patch, this is fixed by > describing the switch interfaces as Rx VLAN filtering on [fixed] and > declining any request to join a VLAN unaware bridge. I'll take the first 14 patches now, and then you will have a "clean" place to ask for the movement of this out of staging. thanks, greg k-h
On Wed, Mar 10, 2021 at 01:44:46PM +0100, Greg KH wrote: > On Wed, Mar 10, 2021 at 02:14:37PM +0200, Ioana Ciornei wrote: > > From: Ioana Ciornei <ioana.ciornei@nxp.com> > > > > This patch set adds support for Rx/Tx capabilities on DPAA2 switch port > > interfaces as well as fixing up some major blunders in how we take care > > of the switching domains. The last patch actually moves the driver out > > of staging now that the minimum requirements are met. > > > > I am sending this directly towards the net-next tree so that I can use > > the rest of the development cycle adding new features on top of the > > current driver without worrying about merge conflicts between the > > staging and net-next tree. > > > > The control interface is comprised of 3 queues in total: Rx, Rx error > > and Tx confirmation. In this patch set we only enable Rx and Tx conf. > > All switch ports share the same queues when frames are redirected to the > > CPU. Information regarding the ingress switch port is passed through > > frame metadata - the flow context field of the descriptor. > > > > NAPI instances are also shared between switch net_devices and are > > enabled when at least on one of the switch ports .dev_open() was called > > and disabled when no switch port is still up. > > > > Since the last version of this feature was submitted to the list, I > > reworked how the switching and flooding domains are taken care of by the > > driver, thus the switch is now able to also add the control port (the > > queues that the CPU can dequeue from) into the flooding domains of a > > port (broadcast, unknown unicast etc). With this, we are able to receive > > and sent traffic from the switch interfaces. > > > > Also, the capability to properly partition the DPSW object into multiple > > switching domains was added so that when not under a bridge, the ports > > are not actually capable to switch between them. This is possible by > > adding a private FDB table per switch interface. When multiple switch > > interfaces are under the same bridge, they will all use the same FDB > > table. > > > > Another thing that is fixed in this patch set is how the driver handles > > VLAN awareness. The DPAA2 switch is not capable to run as VLAN unaware > > but this was not reflected in how the driver responded to requests to > > change the VLAN awareness. In the last patch, this is fixed by > > describing the switch interfaces as Rx VLAN filtering on [fixed] and > > declining any request to join a VLAN unaware bridge. > > I'll take the first 14 patches now, and then you will have a "clean" > place to ask for the movement of this out of staging. > I was about to respond but it seems that you already applied them into the staging tree. By the way, I was expecting a bit of review from the netdev community since these changes are mainly to get the driver in a proper state for the move. Ok, I am mainly interested in getting all these patches into net-next as well so that other general switchdev changes do not generate conflicts. I assume that the next step would be to get acks from the netdev maintainers especially on the last patch, merge the move in the staging tree and then get all these changes into net-next through some kind of cross-tree merge? Ioana
On Wed, Mar 10, 2021 at 03:47:44PM +0200, Ioana Ciornei wrote: > On Wed, Mar 10, 2021 at 01:44:46PM +0100, Greg KH wrote: > > On Wed, Mar 10, 2021 at 02:14:37PM +0200, Ioana Ciornei wrote: > > > From: Ioana Ciornei <ioana.ciornei@nxp.com> > > > > > > This patch set adds support for Rx/Tx capabilities on DPAA2 switch port > > > interfaces as well as fixing up some major blunders in how we take care > > > of the switching domains. The last patch actually moves the driver out > > > of staging now that the minimum requirements are met. > > > > > > I am sending this directly towards the net-next tree so that I can use > > > the rest of the development cycle adding new features on top of the > > > current driver without worrying about merge conflicts between the > > > staging and net-next tree. > > > > > > The control interface is comprised of 3 queues in total: Rx, Rx error > > > and Tx confirmation. In this patch set we only enable Rx and Tx conf. > > > All switch ports share the same queues when frames are redirected to the > > > CPU. Information regarding the ingress switch port is passed through > > > frame metadata - the flow context field of the descriptor. > > > > > > NAPI instances are also shared between switch net_devices and are > > > enabled when at least on one of the switch ports .dev_open() was called > > > and disabled when no switch port is still up. > > > > > > Since the last version of this feature was submitted to the list, I > > > reworked how the switching and flooding domains are taken care of by the > > > driver, thus the switch is now able to also add the control port (the > > > queues that the CPU can dequeue from) into the flooding domains of a > > > port (broadcast, unknown unicast etc). With this, we are able to receive > > > and sent traffic from the switch interfaces. > > > > > > Also, the capability to properly partition the DPSW object into multiple > > > switching domains was added so that when not under a bridge, the ports > > > are not actually capable to switch between them. This is possible by > > > adding a private FDB table per switch interface. When multiple switch > > > interfaces are under the same bridge, they will all use the same FDB > > > table. > > > > > > Another thing that is fixed in this patch set is how the driver handles > > > VLAN awareness. The DPAA2 switch is not capable to run as VLAN unaware > > > but this was not reflected in how the driver responded to requests to > > > change the VLAN awareness. In the last patch, this is fixed by > > > describing the switch interfaces as Rx VLAN filtering on [fixed] and > > > declining any request to join a VLAN unaware bridge. > > > > I'll take the first 14 patches now, and then you will have a "clean" > > place to ask for the movement of this out of staging. > > > > I was about to respond but it seems that you already applied them into > the staging tree. By the way, I was expecting a bit of review from the > netdev community since these changes are mainly to get the driver in a > proper state for the move. They are only in my "testing" branch, I can easily drop them right now if you want me to. > Ok, I am mainly interested in getting all these patches into net-next as > well so that other general switchdev changes do not generate conflicts. What other general switchdev changes? > I assume that the next step would be to get acks from the netdev > maintainers especially on the last patch, merge the move in the staging > tree and then get all these changes into net-next through some kind of > cross-tree merge? Yes, either I can provide a stable tag to pull from for the netdev maintainers, or they can just add the whole driver to the "proper" place in the network tree and I can drop the one in staging entirely. Or people can wait until 5.13-rc1 when this all shows up in Linus's tree, whatever works best for the networking maintainers, after reviewing it. thanks, greg k-h
Hey Greg, On Wed, Mar 10, 2021 at 03:12:57PM +0100, Greg KH wrote: > > Ok, I am mainly interested in getting all these patches into net-next as > > well so that other general switchdev changes do not generate conflicts. > > What other general switchdev changes? During the merge window I sent some RFC patches that change the interaction between all switchdev drivers and the bridge: https://patchwork.kernel.org/project/netdevbpf/patch/20210224114350.2791260-17-olteanv@gmail.com/ I would like to be able to submit that patch as non-RFC (to the net-next tree, of course) during this release cycle, and it touches the dpaa2 switch. Let's see what the network maintainers think about dealing with this cross-tree situation.
On Wed, Mar 10, 2021 at 03:12:57PM +0100, Greg KH wrote: > On Wed, Mar 10, 2021 at 03:47:44PM +0200, Ioana Ciornei wrote: > > On Wed, Mar 10, 2021 at 01:44:46PM +0100, Greg KH wrote: > > > On Wed, Mar 10, 2021 at 02:14:37PM +0200, Ioana Ciornei wrote: > > > > From: Ioana Ciornei <ioana.ciornei@nxp.com> > > > > > > > > This patch set adds support for Rx/Tx capabilities on DPAA2 switch port > > > > interfaces as well as fixing up some major blunders in how we take care > > > > of the switching domains. The last patch actually moves the driver out > > > > of staging now that the minimum requirements are met. > > > > > > > > I am sending this directly towards the net-next tree so that I can use > > > > the rest of the development cycle adding new features on top of the > > > > current driver without worrying about merge conflicts between the > > > > staging and net-next tree. > > > > > > > > The control interface is comprised of 3 queues in total: Rx, Rx error > > > > and Tx confirmation. In this patch set we only enable Rx and Tx conf. > > > > All switch ports share the same queues when frames are redirected to the > > > > CPU. Information regarding the ingress switch port is passed through > > > > frame metadata - the flow context field of the descriptor. > > > > > > > > NAPI instances are also shared between switch net_devices and are > > > > enabled when at least on one of the switch ports .dev_open() was called > > > > and disabled when no switch port is still up. > > > > > > > > Since the last version of this feature was submitted to the list, I > > > > reworked how the switching and flooding domains are taken care of by the > > > > driver, thus the switch is now able to also add the control port (the > > > > queues that the CPU can dequeue from) into the flooding domains of a > > > > port (broadcast, unknown unicast etc). With this, we are able to receive > > > > and sent traffic from the switch interfaces. > > > > > > > > Also, the capability to properly partition the DPSW object into multiple > > > > switching domains was added so that when not under a bridge, the ports > > > > are not actually capable to switch between them. This is possible by > > > > adding a private FDB table per switch interface. When multiple switch > > > > interfaces are under the same bridge, they will all use the same FDB > > > > table. > > > > > > > > Another thing that is fixed in this patch set is how the driver handles > > > > VLAN awareness. The DPAA2 switch is not capable to run as VLAN unaware > > > > but this was not reflected in how the driver responded to requests to > > > > change the VLAN awareness. In the last patch, this is fixed by > > > > describing the switch interfaces as Rx VLAN filtering on [fixed] and > > > > declining any request to join a VLAN unaware bridge. > > > > > > I'll take the first 14 patches now, and then you will have a "clean" > > > place to ask for the movement of this out of staging. > > > > > > > I was about to respond but it seems that you already applied them into > > the staging tree. By the way, I was expecting a bit of review from the > > netdev community since these changes are mainly to get the driver in a > > proper state for the move. > > They are only in my "testing" branch, I can easily drop them right now > if you want me to. Well, it seems that I added some checks at the last minute, forgot to compile-test patch by patch and the checks were added too early in the series therefore it fails to build now on patches 10 and 11. Could you please just drop this so that that I can respin them with that addressed as well as any other review feedback? Ioana
From: Greg KH <gregkh@linuxfoundation.org> Date: Wed, 10 Mar 2021 15:12:57 +0100 > Yes, either I can provide a stable tag to pull from for the netdev > maintainers, or they can just add the whole driver to the "proper" place > in the network tree and I can drop the one in staging entirely. Or > people can wait until 5.13-rc1 when this all shows up in Linus's tree, > whatever works best for the networking maintainers, after reviewing it. I've added this whole series to my tree as I think that makes things easiest for everyone. Thanks!
Hello: This series was applied to netdev/net-next.git (refs/heads/master): On Wed, 10 Mar 2021 14:14:37 +0200 you wrote: > From: Ioana Ciornei <ioana.ciornei@nxp.com> > > This patch set adds support for Rx/Tx capabilities on DPAA2 switch port > interfaces as well as fixing up some major blunders in how we take care > of the switching domains. The last patch actually moves the driver out > of staging now that the minimum requirements are met. > > [...] Here is the summary with links: - [net-next,01/15] staging: dpaa2-switch: remove broken learning and flooding support https://git.kernel.org/netdev/net-next/c/93a4d0ab1e44 - [net-next,02/15] staging: dpaa2-switch: fix up initial forwarding configuration done by firmware https://git.kernel.org/netdev/net-next/c/282d47de29c7 - [net-next,03/15] staging: dpaa2-switch: remove obsolete .ndo_fdb_{add|del} callbacks https://git.kernel.org/netdev/net-next/c/5dda9a7921c7 - [net-next,04/15] staging: dpaa2-switch: get control interface attributes https://git.kernel.org/netdev/net-next/c/26d419f36a23 - [net-next,05/15] staging: dpaa2-switch: setup buffer pool and RX path rings https://git.kernel.org/netdev/net-next/c/2877e4f7e189 - [net-next,06/15] staging: dpaa2-switch: setup dpio https://git.kernel.org/netdev/net-next/c/04abc97d3ef7 - [net-next,07/15] staging: dpaa2-switch: handle Rx path on control interface https://git.kernel.org/netdev/net-next/c/0b1b71370458 - [net-next,08/15] staging: dpaa2-switch: add .ndo_start_xmit() callback https://git.kernel.org/netdev/net-next/c/7fd94d86b7f4 - [net-next,09/15] staging: dpaa2-switch: enable the control interface https://git.kernel.org/netdev/net-next/c/613c0a5810b7 - [net-next,10/15] staging: dpaa2-switch: properly setup switching domains https://git.kernel.org/netdev/net-next/c/539dda3c5d19 - [net-next,11/15] staging: dpaa2-switch: move the notifier register to module_init() https://git.kernel.org/netdev/net-next/c/16abb6ad6abc - [net-next,12/15] staging: dpaa2-switch: accept only vlan-aware upper devices https://git.kernel.org/netdev/net-next/c/d671407fccbb - [net-next,13/15] staging: dpaa2-switch: add fast-ageing on bridge leave https://git.kernel.org/netdev/net-next/c/685b480145c1 - [net-next,14/15] staging: dpaa2-switch: prevent joining a bridge while VLAN uppers are present https://git.kernel.org/netdev/net-next/c/1c4928fc2929 - [net-next,15/15] staging: dpaa2-switch: move the driver out of staging https://git.kernel.org/netdev/net-next/c/f48298d3fbfa You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
On Wed, Mar 10, 2021 at 03:13:10PM -0800, David Miller wrote: > From: Greg KH <gregkh@linuxfoundation.org> > Date: Wed, 10 Mar 2021 15:12:57 +0100 > > > Yes, either I can provide a stable tag to pull from for the netdev > > maintainers, or they can just add the whole driver to the "proper" place > > in the network tree and I can drop the one in staging entirely. Or > > people can wait until 5.13-rc1 when this all shows up in Linus's tree, > > whatever works best for the networking maintainers, after reviewing it. > > I've added this whole series to my tree as I think that makes things easiest > for everyone. > > Thanks! Sorry for bothering you again.. but it seems that Greg has also added the first 14 patches to staging-next. I just want to make sure that the linux-next will be happy with these patches being in 2 trees. Thanks!
On Thu, Mar 11, 2021 at 08:54:37AM +0200, Ioana Ciornei wrote: > On Wed, Mar 10, 2021 at 03:13:10PM -0800, David Miller wrote: > > From: Greg KH <gregkh@linuxfoundation.org> > > Date: Wed, 10 Mar 2021 15:12:57 +0100 > > > > > Yes, either I can provide a stable tag to pull from for the netdev > > > maintainers, or they can just add the whole driver to the "proper" place > > > in the network tree and I can drop the one in staging entirely. Or > > > people can wait until 5.13-rc1 when this all shows up in Linus's tree, > > > whatever works best for the networking maintainers, after reviewing it. > > > > I've added this whole series to my tree as I think that makes things easiest > > for everyone. > > > > Thanks! > > Sorry for bothering you again.. but it seems that Greg has also added > the first 14 patches to staging-next. I just want to make sure that the > linux-next will be happy with these patches being in 2 trees. It should, git is nice :) I can also just drop them from my staging tree as well, that's trivial. thanks, greg k-h
On Thu, Mar 11, 2021 at 08:04:29AM +0100, Greg KH wrote: > On Thu, Mar 11, 2021 at 08:54:37AM +0200, Ioana Ciornei wrote: > > On Wed, Mar 10, 2021 at 03:13:10PM -0800, David Miller wrote: > > > From: Greg KH <gregkh@linuxfoundation.org> > > > Date: Wed, 10 Mar 2021 15:12:57 +0100 > > > > > > > Yes, either I can provide a stable tag to pull from for the netdev > > > > maintainers, or they can just add the whole driver to the "proper" place > > > > in the network tree and I can drop the one in staging entirely. Or > > > > people can wait until 5.13-rc1 when this all shows up in Linus's tree, > > > > whatever works best for the networking maintainers, after reviewing it. > > > > > > I've added this whole series to my tree as I think that makes things easiest > > > for everyone. > > > > > > Thanks! > > > > Sorry for bothering you again.. but it seems that Greg has also added > > the first 14 patches to staging-next. I just want to make sure that the > > linux-next will be happy with these patches being in 2 trees. > > It should, git is nice :) > > I can also just drop them from my staging tree as well, that's trivial. Ah, just saw your "these are broken" email, I'll go drop these. thanks, greg k-h
From: Ioana Ciornei <ioana.ciornei@nxp.com> This patch set adds support for Rx/Tx capabilities on DPAA2 switch port interfaces as well as fixing up some major blunders in how we take care of the switching domains. The last patch actually moves the driver out of staging now that the minimum requirements are met. I am sending this directly towards the net-next tree so that I can use the rest of the development cycle adding new features on top of the current driver without worrying about merge conflicts between the staging and net-next tree. The control interface is comprised of 3 queues in total: Rx, Rx error and Tx confirmation. In this patch set we only enable Rx and Tx conf. All switch ports share the same queues when frames are redirected to the CPU. Information regarding the ingress switch port is passed through frame metadata - the flow context field of the descriptor. NAPI instances are also shared between switch net_devices and are enabled when at least on one of the switch ports .dev_open() was called and disabled when no switch port is still up. Since the last version of this feature was submitted to the list, I reworked how the switching and flooding domains are taken care of by the driver, thus the switch is now able to also add the control port (the queues that the CPU can dequeue from) into the flooding domains of a port (broadcast, unknown unicast etc). With this, we are able to receive and sent traffic from the switch interfaces. Also, the capability to properly partition the DPSW object into multiple switching domains was added so that when not under a bridge, the ports are not actually capable to switch between them. This is possible by adding a private FDB table per switch interface. When multiple switch interfaces are under the same bridge, they will all use the same FDB table. Another thing that is fixed in this patch set is how the driver handles VLAN awareness. The DPAA2 switch is not capable to run as VLAN unaware but this was not reflected in how the driver responded to requests to change the VLAN awareness. In the last patch, this is fixed by describing the switch interfaces as Rx VLAN filtering on [fixed] and declining any request to join a VLAN unaware bridge. Ioana Ciornei (15): staging: dpaa2-switch: remove broken learning and flooding support staging: dpaa2-switch: fix up initial forwarding configuration done by firmware staging: dpaa2-switch: remove obsolete .ndo_fdb_{add|del} callbacks staging: dpaa2-switch: get control interface attributes staging: dpaa2-switch: setup buffer pool and RX path rings staging: dpaa2-switch: setup dpio staging: dpaa2-switch: handle Rx path on control interface staging: dpaa2-switch: add .ndo_start_xmit() callback staging: dpaa2-switch: enable the control interface staging: dpaa2-switch: properly setup switching domains staging: dpaa2-switch: move the notifier register to module_init() staging: dpaa2-switch: accept only vlan-aware upper devices staging: dpaa2-switch: add fast-ageing on bridge leave staging: dpaa2-switch: prevent joining a bridge while VLAN uppers are present staging: dpaa2-switch: move the driver out of staging MAINTAINERS | 6 +- drivers/net/ethernet/freescale/dpaa2/Kconfig | 8 + drivers/net/ethernet/freescale/dpaa2/Makefile | 2 + .../freescale/dpaa2/dpaa2-switch-ethtool.c} | 2 +- .../ethernet/freescale/dpaa2/dpaa2-switch.c} | 1704 +++++++++++++---- .../ethernet/freescale/dpaa2/dpaa2-switch.h | 178 ++ .../ethernet/freescale/dpaa2}/dpsw-cmd.h | 128 +- .../ethernet/freescale/dpaa2}/dpsw.c | 328 +++- .../ethernet/freescale/dpaa2}/dpsw.h | 199 +- drivers/staging/Kconfig | 2 - drivers/staging/Makefile | 1 - drivers/staging/fsl-dpaa2/Kconfig | 19 - drivers/staging/fsl-dpaa2/Makefile | 6 - drivers/staging/fsl-dpaa2/ethsw/Makefile | 10 - drivers/staging/fsl-dpaa2/ethsw/README | 106 - drivers/staging/fsl-dpaa2/ethsw/TODO | 13 - drivers/staging/fsl-dpaa2/ethsw/ethsw.h | 80 - 17 files changed, 2097 insertions(+), 695 deletions(-) rename drivers/{staging/fsl-dpaa2/ethsw/ethsw-ethtool.c => net/ethernet/freescale/dpaa2/dpaa2-switch-ethtool.c} (99%) rename drivers/{staging/fsl-dpaa2/ethsw/ethsw.c => net/ethernet/freescale/dpaa2/dpaa2-switch.c} (51%) create mode 100644 drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.h rename drivers/{staging/fsl-dpaa2/ethsw => net/ethernet/freescale/dpaa2}/dpsw-cmd.h (76%) rename drivers/{staging/fsl-dpaa2/ethsw => net/ethernet/freescale/dpaa2}/dpsw.c (83%) rename drivers/{staging/fsl-dpaa2/ethsw => net/ethernet/freescale/dpaa2}/dpsw.h (73%) delete mode 100644 drivers/staging/fsl-dpaa2/Kconfig delete mode 100644 drivers/staging/fsl-dpaa2/Makefile delete mode 100644 drivers/staging/fsl-dpaa2/ethsw/Makefile delete mode 100644 drivers/staging/fsl-dpaa2/ethsw/README delete mode 100644 drivers/staging/fsl-dpaa2/ethsw/TODO delete mode 100644 drivers/staging/fsl-dpaa2/ethsw/ethsw.h