Message ID | 20240822132031.29494-1-gakula@marvell.com (mailing list archive) |
---|---|
Headers | show |
Series | Introduce RVU representors | expand |
Thu, Aug 22, 2024 at 03:20:20PM CEST, gakula@marvell.com wrote: >This series adds representor support for each rvu devices. >When switchdev mode is enabled, representor netdev is registered >for each rvu device. In implementation of representor model, >one NIX HW LF with multiple SQ and RQ is reserved, where each >RQ and SQ of the LF are mapped to a representor. A loopback channel >is reserved to support packet path between representors and VFs. >CN10K silicon supports 2 types of MACs, RPM and SDP. This >patch set adds representor support for both RPM and SDP MAC >interfaces. > >- Patch 1: Refactors and exports the shared service functions. >- Patch 2: Implements basic representor driver. >- Patch 3: Add devlink support to create representor netdevs that > can be used to manage VFs. >- Patch 4: Implements basec netdev_ndo_ops. >- Patch 5: Installs tcam rules to route packets between representor and > VFs. >- Patch 6: Enables fetching VF stats via representor interface >- Patch 7: Adds support to sync link state between representors and VFs . >- Patch 8: Enables configuring VF MTU via representor netdevs. >- Patch 9: Add representors for sdp MAC. >- Patch 10: Add devlink port support. > > >Command to create PF/VF representor >#devlink dev eswitch set pci/0002:1c:00.0 mode switchdev > >VF representors are created for each VF when switch mode is set switchdev on >representor PCI device. Each PF support upto 3VFs. Representor can be created >before or after the VFs creation. What do you mean by the last sentence? I don't understand it. > >#devlink dev >pci/0002:1c:00.0 > >#devlink dev eswitch set pci/0002:1c:00.0 mode switchdev > ># ip link show > pf1vf0rep: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 7e:5a:66:ea:fe:d6 brd ff:ff:ff:ff:ff:ff > pf1vf1rep: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether de:29:be:10:9e:bf brd ff:ff:ff:ff:ff:ff > pf1vf2rep: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 4a:12:c7:a2:66:ad brd ff:ff:ff:ff:ff:ff > pf1vf3rep: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether c2:b8:a8:0e:73:fd brd ff:ff:ff:ff:ff:ff Where do you have physical port netdev? Looks like all macs are made up. I would expect the phisical port netdev to have some fixed vendor-based mac. > > >~# devlink port >pci/0002:1c:00.0/0: type eth netdev pf1vf0rep flavour physical port 1 splittable false vf0? What does it mean? Could you please let udev do it's work and let it rename netdevices properly? >pci/0002:1c:00.0/1: type eth netdev pf1vf1rep flavour pcivf controller 0 pfnum 1 vfnum 1 external false splittable false Do you have pf 0 or you start with 1? If yes, why? >pci/0002:1c:00.0/2: type eth netdev pf1vf2rep flavour pcivf controller 0 pfnum 1 vfnum 2 external false splittable false >pci/0002:1c:00.0/3: type eth netdev pf1vf3rep flavour pcivf controller 0 pfnum 1 vfnum 3 external false splittable false > >----------- >v1-v2: > -Fixed build warnings. > -Address review comments provided by "Kalesh Anakkur Purayil". > >v2-v3: > - Used extack for error messages. > - As suggested reworked commit messages. > - Fixed sparse warning. > >v3-v4: > - Patch 2 & 3: Fixed coccinelle reported warnings. > - Patch 10: Added devlink port support. > >v4-v5: > - Patch 3: Removed devm_* usage in rvu_rep_create() > - Patch 3: Fixed build warnings. > >v5-v6: > - Addressed review comments provided by "Simon Horman". > - Added review tag. > >v6-v7: > - Rebased on top net-next branch. > >v7-v8: > - Implemented offload stats ndo. > - Added documentation. > >v8-v9: > - Updated the documentation. > >v9-v10: > - Fixed build warning w.r.t documentation. > >v10-v11: > - As suggested by "Jiri Pirko" adjusted the documentation. > - Added more commit description to patch1. > >Geetha sowjanya (11): > octeontx2-pf: Refactoring RVU driver > octeontx2-pf: RVU representor driver > octeontx2-pf: Create representor netdev > octeontx2-pf: Add basic net_device_ops > octeontx2-af: Add packet path between representor and VF > octeontx2-pf: Get VF stats via representor > octeontx2-pf: Add support to sync link state between representor and > VFs > octeontx2-pf: Configure VF mtu via representor > octeontx2-pf: Add representors for sdp MAC > octeontx2-pf: Add devlink port support > octeontx2-pf: Implement offload stats ndo for representors > > .../ethernet/marvell/octeontx2.rst | 85 ++ > .../net/ethernet/marvell/octeontx2/Kconfig | 8 + > .../ethernet/marvell/octeontx2/af/Makefile | 3 +- > .../ethernet/marvell/octeontx2/af/common.h | 2 + > .../net/ethernet/marvell/octeontx2/af/mbox.h | 74 ++ > .../net/ethernet/marvell/octeontx2/af/npc.h | 1 + > .../net/ethernet/marvell/octeontx2/af/rvu.c | 11 + > .../net/ethernet/marvell/octeontx2/af/rvu.h | 30 +- > .../marvell/octeontx2/af/rvu_debugfs.c | 27 - > .../marvell/octeontx2/af/rvu_devlink.c | 6 + > .../ethernet/marvell/octeontx2/af/rvu_nix.c | 81 +- > .../marvell/octeontx2/af/rvu_npc_fs.c | 5 + > .../ethernet/marvell/octeontx2/af/rvu_reg.h | 4 + > .../ethernet/marvell/octeontx2/af/rvu_rep.c | 464 +++++++++++ > .../marvell/octeontx2/af/rvu_struct.h | 26 + > .../marvell/octeontx2/af/rvu_switch.c | 20 +- > .../ethernet/marvell/octeontx2/nic/Makefile | 2 + > .../ethernet/marvell/octeontx2/nic/cn10k.c | 4 +- > .../ethernet/marvell/octeontx2/nic/cn10k.h | 2 +- > .../marvell/octeontx2/nic/otx2_common.c | 58 +- > .../marvell/octeontx2/nic/otx2_common.h | 84 +- > .../marvell/octeontx2/nic/otx2_devlink.c | 49 ++ > .../ethernet/marvell/octeontx2/nic/otx2_pf.c | 305 ++++--- > .../marvell/octeontx2/nic/otx2_txrx.c | 38 +- > .../marvell/octeontx2/nic/otx2_txrx.h | 3 +- > .../ethernet/marvell/octeontx2/nic/otx2_vf.c | 19 +- > .../net/ethernet/marvell/octeontx2/nic/rep.c | 744 ++++++++++++++++++ > .../net/ethernet/marvell/octeontx2/nic/rep.h | 53 ++ > 28 files changed, 1981 insertions(+), 227 deletions(-) > create mode 100644 drivers/net/ethernet/marvell/octeontx2/af/rvu_rep.c > create mode 100644 drivers/net/ethernet/marvell/octeontx2/nic/rep.c > create mode 100644 drivers/net/ethernet/marvell/octeontx2/nic/rep.h > >-- >2.25.1 >
Thu, Aug 22, 2024 at 03:20:20PM CEST, gakula@marvell.com wrote: >This series adds representor support for each rvu devices. >When switchdev mode is enabled, representor netdev is registered >for each rvu device. In implementation of representor model, >one NIX HW LF with multiple SQ and RQ is reserved, where each >RQ and SQ of the LF are mapped to a representor. A loopback channel >is reserved to support packet path between representors and VFs. >CN10K silicon supports 2 types of MACs, RPM and SDP. This >patch set adds representor support for both RPM and SDP MAC >interfaces. > >- Patch 1: Refactors and exports the shared service functions. >- Patch 2: Implements basic representor driver. >- Patch 3: Add devlink support to create representor netdevs that > can be used to manage VFs. >- Patch 4: Implements basec netdev_ndo_ops. >- Patch 5: Installs tcam rules to route packets between representor and > VFs. >- Patch 6: Enables fetching VF stats via representor interface >- Patch 7: Adds support to sync link state between representors and VFs . >- Patch 8: Enables configuring VF MTU via representor netdevs. >- Patch 9: Add representors for sdp MAC. >- Patch 10: Add devlink port support. What is the fastpath? Where do you offload any configuration that actually ensures VF<->physical_port and VF<->VF traffic? There should be some bridge/tc/route offload. Or, what I fear, do you use some implicit mac-based steering? If yes, you should not. In switchdev mode, if user does not configure representors to forward packets, there is no packet forwarding.
>-----Original Message----- >From: Jiri Pirko <jiri@resnulli.us> >Sent: Thursday, August 22, 2024 8:12 PM >To: Geethasowjanya Akula <gakula@marvell.com> >Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; kuba@kernel.org; >davem@davemloft.net; pabeni@redhat.com; edumazet@google.com; Sunil >Kovvuri Goutham <sgoutham@marvell.com>; Subbaraya Sundeep Bhatta ><sbhatta@marvell.com>; Hariprasad Kelam <hkelam@marvell.com> >Subject: [EXTERNAL] Re: [net-next PATCH v11 00/11] Introduce RVU >representors > >Thu, Aug 22, 2024 at 03:20:20PM CEST, gakula@marvell.com wrote: >>This series adds representor support for each rvu devices. >>When switchdev mode is enabled, representor netdev is registered for >>each rvu device. In implementation of representor model, one NIX HW LF >>with multiple SQ and RQ is reserved, where each RQ and SQ of the LF are >>mapped to a representor. A loopback channel is reserved to support >>packet path between representors and VFs. >>CN10K silicon supports 2 types of MACs, RPM and SDP. This patch set >>adds representor support for both RPM and SDP MAC interfaces. >> >>- Patch 1: Refactors and exports the shared service functions. >>- Patch 2: Implements basic representor driver. >>- Patch 3: Add devlink support to create representor netdevs that >> can be used to manage VFs. >>- Patch 4: Implements basec netdev_ndo_ops. >>- Patch 5: Installs tcam rules to route packets between representor and >> VFs. >>- Patch 6: Enables fetching VF stats via representor interface >>- Patch 7: Adds support to sync link state between representors and VFs . >>- Patch 8: Enables configuring VF MTU via representor netdevs. >>- Patch 9: Add representors for sdp MAC. >>- Patch 10: Add devlink port support. > >What is the fastpath? Where do you offload any configuration that actually >ensures VF<->physical_port and VF<->VF traffic? There should be some >bridge/tc/route offload. Packet between VFs and VF -> physical ports are done based on tcam rules installed by TC only. > >Or, what I fear, do you use some implicit mac-based steering? If yes, you No, we don’t do any mac based traffic steerring. >should not. In switchdev mode, if user does not configure representors to >forward packets, there is no packet forwarding.
Sun, Sep 01, 2024 at 12:01:02PM CEST, gakula@marvell.com wrote: > > >>-----Original Message----- >>From: Jiri Pirko <jiri@resnulli.us> >>Sent: Thursday, August 22, 2024 8:12 PM >>To: Geethasowjanya Akula <gakula@marvell.com> >>Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; kuba@kernel.org; >>davem@davemloft.net; pabeni@redhat.com; edumazet@google.com; Sunil >>Kovvuri Goutham <sgoutham@marvell.com>; Subbaraya Sundeep Bhatta >><sbhatta@marvell.com>; Hariprasad Kelam <hkelam@marvell.com> >>Subject: [EXTERNAL] Re: [net-next PATCH v11 00/11] Introduce RVU >>representors >> >>Thu, Aug 22, 2024 at 03:20:20PM CEST, gakula@marvell.com wrote: >>>This series adds representor support for each rvu devices. >>>When switchdev mode is enabled, representor netdev is registered for >>>each rvu device. In implementation of representor model, one NIX HW LF >>>with multiple SQ and RQ is reserved, where each RQ and SQ of the LF are >>>mapped to a representor. A loopback channel is reserved to support >>>packet path between representors and VFs. >>>CN10K silicon supports 2 types of MACs, RPM and SDP. This patch set >>>adds representor support for both RPM and SDP MAC interfaces. >>> >>>- Patch 1: Refactors and exports the shared service functions. >>>- Patch 2: Implements basic representor driver. >>>- Patch 3: Add devlink support to create representor netdevs that >>> can be used to manage VFs. >>>- Patch 4: Implements basec netdev_ndo_ops. >>>- Patch 5: Installs tcam rules to route packets between representor and >>> VFs. >>>- Patch 6: Enables fetching VF stats via representor interface >>>- Patch 7: Adds support to sync link state between representors and VFs . >>>- Patch 8: Enables configuring VF MTU via representor netdevs. >>>- Patch 9: Add representors for sdp MAC. >>>- Patch 10: Add devlink port support. >> >>What is the fastpath? Where do you offload any configuration that actually >>ensures VF<->physical_port and VF<->VF traffic? There should be some >>bridge/tc/route offload. >Packet between VFs and VF -> physical ports are done based on tcam rules installed by TC only. Where is the code implementing that? >> >>Or, what I fear, do you use some implicit mac-based steering? If yes, you >No, we don’t do any mac based traffic steerring. > >>should not. In switchdev mode, if user does not configure representors to >>forward packets, there is no packet forwarding. > >
>-----Original Message----- >From: Jiri Pirko <jiri@resnulli.us> >Sent: Monday, September 2, 2024 5:03 PM >To: Geethasowjanya Akula <gakula@marvell.com> >Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; kuba@kernel.org; >davem@davemloft.net; pabeni@redhat.com; edumazet@google.com; Sunil >Kovvuri Goutham <sgoutham@marvell.com>; Subbaraya Sundeep Bhatta ><sbhatta@marvell.com>; Hariprasad Kelam <hkelam@marvell.com> >Subject: Re: [EXTERNAL] Re: [net-next PATCH v11 00/11] Introduce RVU >representors > >Sun, Sep 01, 2024 at 12: 01: 02PM CEST, gakula@ marvell. com wrote: > > >>----- >Original Message----- >>From: Jiri Pirko <jiri@ resnulli. us> >>Sent: Thursday, >August 22, 2024 8: 12 PM >>To: Geethasowjanya Akula ><gakula@ marvell. com >Sun, Sep 01, 2024 at 12:01:02PM CEST, gakula@marvell.com wrote: >> >> >>>-----Original Message----- >>>From: Jiri Pirko <jiri@resnulli.us> >>>Sent: Thursday, August 22, 2024 8:12 PM >>>To: Geethasowjanya Akula <gakula@marvell.com> >>>Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; >>>kuba@kernel.org; davem@davemloft.net; pabeni@redhat.com; >>>edumazet@google.com; Sunil Kovvuri Goutham <sgoutham@marvell.com>; >>>Subbaraya Sundeep Bhatta <sbhatta@marvell.com>; Hariprasad Kelam >>><hkelam@marvell.com> >>>Subject: [EXTERNAL] Re: [net-next PATCH v11 00/11] Introduce RVU >>>representors >>> >>>Thu, Aug 22, 2024 at 03:20:20PM CEST, gakula@marvell.com wrote: >>>>This series adds representor support for each rvu devices. >>>>When switchdev mode is enabled, representor netdev is registered for >>>>each rvu device. In implementation of representor model, one NIX HW >>>>LF with multiple SQ and RQ is reserved, where each RQ and SQ of the >>>>LF are mapped to a representor. A loopback channel is reserved to >>>>support packet path between representors and VFs. >>>>CN10K silicon supports 2 types of MACs, RPM and SDP. This patch set >>>>adds representor support for both RPM and SDP MAC interfaces. >>>> >>>>- Patch 1: Refactors and exports the shared service functions. >>>>- Patch 2: Implements basic representor driver. >>>>- Patch 3: Add devlink support to create representor netdevs that >>>> can be used to manage VFs. >>>>- Patch 4: Implements basec netdev_ndo_ops. >>>>- Patch 5: Installs tcam rules to route packets between representor and >>>> VFs. >>>>- Patch 6: Enables fetching VF stats via representor interface >>>>- Patch 7: Adds support to sync link state between representors and VFs . >>>>- Patch 8: Enables configuring VF MTU via representor netdevs. >>>>- Patch 9: Add representors for sdp MAC. >>>>- Patch 10: Add devlink port support. >>> >>>What is the fastpath? Where do you offload any configuration that >>>actually ensures VF<->physical_port and VF<->VF traffic? There should >>>be some bridge/tc/route offload. >>Packet between VFs and VF -> physical ports are done based on tcam rules >installed by TC only. > >Where is the code implementing that? We planned to submit basic RVU representor driver first followed by TC HW offload support for the representors. > > >>> >>>Or, what I fear, do you use some implicit mac-based steering? If yes, >>>you >>No, we don’t do any mac based traffic steerring. >> >>>should not. In switchdev mode, if user does not configure representors >>>to forward packets, there is no packet forwarding. >> >>
Mon, Sep 02, 2024 at 06:37:32PM CEST, gakula@marvell.com wrote: > > >>-----Original Message----- >>From: Jiri Pirko <jiri@resnulli.us> >>Sent: Monday, September 2, 2024 5:03 PM >>To: Geethasowjanya Akula <gakula@marvell.com> >>Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; kuba@kernel.org; >>davem@davemloft.net; pabeni@redhat.com; edumazet@google.com; Sunil >>Kovvuri Goutham <sgoutham@marvell.com>; Subbaraya Sundeep Bhatta >><sbhatta@marvell.com>; Hariprasad Kelam <hkelam@marvell.com> >>Subject: Re: [EXTERNAL] Re: [net-next PATCH v11 00/11] Introduce RVU >>representors >> >>Sun, Sep 01, 2024 at 12: 01: 02PM CEST, gakula@ marvell. com wrote: > > >>----- >>Original Message----- >>From: Jiri Pirko <jiri@ resnulli. us> >>Sent: Thursday, >>August 22, 2024 8: 12 PM >>To: Geethasowjanya Akula >><gakula@ marvell. com >>Sun, Sep 01, 2024 at 12:01:02PM CEST, gakula@marvell.com wrote: >>> >>> >>>>-----Original Message----- >>>>From: Jiri Pirko <jiri@resnulli.us> >>>>Sent: Thursday, August 22, 2024 8:12 PM >>>>To: Geethasowjanya Akula <gakula@marvell.com> >>>>Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; >>>>kuba@kernel.org; davem@davemloft.net; pabeni@redhat.com; >>>>edumazet@google.com; Sunil Kovvuri Goutham <sgoutham@marvell.com>; >>>>Subbaraya Sundeep Bhatta <sbhatta@marvell.com>; Hariprasad Kelam >>>><hkelam@marvell.com> >>>>Subject: [EXTERNAL] Re: [net-next PATCH v11 00/11] Introduce RVU >>>>representors >>>> >>>>Thu, Aug 22, 2024 at 03:20:20PM CEST, gakula@marvell.com wrote: >>>>>This series adds representor support for each rvu devices. >>>>>When switchdev mode is enabled, representor netdev is registered for >>>>>each rvu device. In implementation of representor model, one NIX HW >>>>>LF with multiple SQ and RQ is reserved, where each RQ and SQ of the >>>>>LF are mapped to a representor. A loopback channel is reserved to >>>>>support packet path between representors and VFs. >>>>>CN10K silicon supports 2 types of MACs, RPM and SDP. This patch set >>>>>adds representor support for both RPM and SDP MAC interfaces. >>>>> >>>>>- Patch 1: Refactors and exports the shared service functions. >>>>>- Patch 2: Implements basic representor driver. >>>>>- Patch 3: Add devlink support to create representor netdevs that >>>>> can be used to manage VFs. >>>>>- Patch 4: Implements basec netdev_ndo_ops. >>>>>- Patch 5: Installs tcam rules to route packets between representor and >>>>> VFs. >>>>>- Patch 6: Enables fetching VF stats via representor interface >>>>>- Patch 7: Adds support to sync link state between representors and VFs . >>>>>- Patch 8: Enables configuring VF MTU via representor netdevs. >>>>>- Patch 9: Add representors for sdp MAC. >>>>>- Patch 10: Add devlink port support. >>>> >>>>What is the fastpath? Where do you offload any configuration that >>>>actually ensures VF<->physical_port and VF<->VF traffic? There should >>>>be some bridge/tc/route offload. >>>Packet between VFs and VF -> physical ports are done based on tcam rules >>installed by TC only. >> >>Where is the code implementing that? >We planned to submit basic RVU representor driver first followed by >TC HW offload support for the representors. Would be good to describe your plans in the cover letter. At least the once that are in near future. Without TC offload this patchset has no meaning. >> >> >>>> >>>>Or, what I fear, do you use some implicit mac-based steering? If yes, >>>>you >>>No, we don’t do any mac based traffic steerring. >>> >>>>should not. In switchdev mode, if user does not configure representors >>>>to forward packets, there is no packet forwarding. >>> >>>