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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <CH0PR18MB433993BD0B4FF3B1F98A7628CD922@CH0PR18MB4339.namprd18.prod.outlook.com>
Date: Mon, 2 Sep 2024 16:37:32 +0000
From: Geethasowjanya Akula <gakula@...vell.com>
To: Jiri Pirko <jiri@...nulli.us>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "davem@...emloft.net"
	<davem@...emloft.net>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        Sunil Kovvuri Goutham
	<sgoutham@...vell.com>,
        Subbaraya Sundeep Bhatta <sbhatta@...vell.com>,
        Hariprasad Kelam <hkelam@...vell.com>
Subject: RE: [EXTERNAL] Re: [net-next PATCH v11 00/11] Introduce RVU
 representors



>-----Original Message-----
>From: Jiri Pirko <jiri@...nulli.us>
>Sent: Monday, September 2, 2024 5:03 PM
>To: Geethasowjanya Akula <gakula@...vell.com>
>Cc: netdev@...r.kernel.org; linux-kernel@...r.kernel.org; kuba@...nel.org;
>davem@...emloft.net; pabeni@...hat.com; edumazet@...gle.com; Sunil
>Kovvuri Goutham <sgoutham@...vell.com>; Subbaraya Sundeep Bhatta
><sbhatta@...vell.com>; Hariprasad Kelam <hkelam@...vell.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@...vell.com wrote:
>>
>>
>>>-----Original Message-----
>>>From: Jiri Pirko <jiri@...nulli.us>
>>>Sent: Thursday, August 22, 2024 8:12 PM
>>>To: Geethasowjanya Akula <gakula@...vell.com>
>>>Cc: netdev@...r.kernel.org; linux-kernel@...r.kernel.org;
>>>kuba@...nel.org; davem@...emloft.net; pabeni@...hat.com;
>>>edumazet@...gle.com; Sunil Kovvuri Goutham <sgoutham@...vell.com>;
>>>Subbaraya Sundeep Bhatta <sbhatta@...vell.com>; Hariprasad Kelam
>>><hkelam@...vell.com>
>>>Subject: [EXTERNAL] Re: [net-next PATCH v11 00/11] Introduce RVU
>>>representors
>>>
>>>Thu, Aug 22, 2024 at 03:20:20PM CEST, gakula@...vell.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.
>>
>>