Re: [EXTERNAL] Re: [net-next PATCH v11 00/11] Introduce RVU representors

[Jiri Pirko]

Mon, Sep 02, 2024 at 06:37:32PM CEST, gakula@xxxxxxxxxxx wrote:
>
>
>>-----Original Message-----
>>From: Jiri Pirko <jiri@xxxxxxxxxxx>
>>Sent: Monday, September 2, 2024 5:03 PM
>>To: Geethasowjanya Akula <gakula@xxxxxxxxxxx>
>>Cc: netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; kuba@xxxxxxxxxx;
>>davem@xxxxxxxxxxxxx; pabeni@xxxxxxxxxx; edumazet@xxxxxxxxxx; Sunil
>>Kovvuri Goutham <sgoutham@xxxxxxxxxxx>; Subbaraya Sundeep Bhatta
>><sbhatta@xxxxxxxxxxx>; Hariprasad Kelam <hkelam@xxxxxxxxxxx>
>>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@xxxxxxxxxxx wrote:
>>>
>>>
>>>>-----Original Message-----
>>>>From: Jiri Pirko <jiri@xxxxxxxxxxx>
>>>>Sent: Thursday, August 22, 2024 8:12 PM
>>>>To: Geethasowjanya Akula <gakula@xxxxxxxxxxx>
>>>>Cc: netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
>>>>kuba@xxxxxxxxxx; davem@xxxxxxxxxxxxx; pabeni@xxxxxxxxxx;
>>>>edumazet@xxxxxxxxxx; Sunil Kovvuri Goutham <sgoutham@xxxxxxxxxxx>;
>>>>Subbaraya Sundeep Bhatta <sbhatta@xxxxxxxxxxx>; Hariprasad Kelam
>>>><hkelam@xxxxxxxxxxx>
>>>>Subject: [EXTERNAL] Re: [net-next PATCH v11 00/11] Introduce RVU
>>>>representors
>>>>
>>>>Thu, Aug 22, 2024 at 03:20:20PM CEST, gakula@xxxxxxxxxxx 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.
>>>
>>>