[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<CH0PR18MB433945FE2481BF86CA5309FBCD912@CH0PR18MB4339.namprd18.prod.outlook.com>
Date: Sun, 1 Sep 2024 10:01:02 +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: 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.
>
>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.
Powered by blists - more mailing lists