[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MW4PR11MB5776D4B4B3CB687ACCBF49E4FD4DA@MW4PR11MB5776.namprd11.prod.outlook.com>
Date: Mon, 5 Jun 2023 10:47:09 +0000
From: "Drewek, Wojciech" <wojciech.drewek@...el.com>
To: Simon Horman <simon.horman@...igine.com>
CC: "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Lobakin, Aleksander"
<aleksander.lobakin@...el.com>, "Ertman, David M" <david.m.ertman@...el.com>,
"michal.swiatkowski@...ux.intel.com" <michal.swiatkowski@...ux.intel.com>,
"marcin.szycik@...ux.intel.com" <marcin.szycik@...ux.intel.com>,
"Chmielewski, Pawel" <pawel.chmielewski@...el.com>, "Samudrala, Sridhar"
<sridhar.samudrala@...el.com>, "pmenzel@...gen.mpg.de"
<pmenzel@...gen.mpg.de>, "dan.carpenter@...aro.org"
<dan.carpenter@...aro.org>
Subject: RE: [PATCH iwl-next v4 06/13] ice: Implement basic eswitch bridge
setup
> -----Original Message-----
> From: Simon Horman <simon.horman@...igine.com>
> Sent: niedziela, 4 czerwca 2023 15:59
> To: Drewek, Wojciech <wojciech.drewek@...el.com>
> Cc: intel-wired-lan@...ts.osuosl.org; netdev@...r.kernel.org; Lobakin, Aleksander <aleksander.lobakin@...el.com>; Ertman, David M
> <david.m.ertman@...el.com>; michal.swiatkowski@...ux.intel.com; marcin.szycik@...ux.intel.com; Chmielewski, Pawel
> <pawel.chmielewski@...el.com>; Samudrala, Sridhar <sridhar.samudrala@...el.com>; pmenzel@...gen.mpg.de;
> dan.carpenter@...aro.org
> Subject: Re: [PATCH iwl-next v4 06/13] ice: Implement basic eswitch bridge setup
>
> On Wed, May 24, 2023 at 02:21:14PM +0200, Wojciech Drewek wrote:
> > With this patch, ice driver is able to track if the port
> > representors or uplink port were added to the linux bridge in
> > switchdev mode. Listen for NETDEV_CHANGEUPPER events in order to
> > detect this. ice_esw_br data structure reflects the linux bridge
> > and stores all the ports of the bridge (ice_esw_br_port) in
> > xarray, it's created when the first port is added to the bridge and
> > freed once the last port is removed. Note that only one bridge is
> > supported per eswitch.
> >
> > Bridge port (ice_esw_br_port) can be either a VF port representor
> > port or uplink port (ice_esw_br_port_type). In both cases bridge port
> > holds a reference to the VSI, VF's VSI in case of the PR and uplink
> > VSI in case of the uplink. VSI's index is used as an index to the
> > xarray in which ports are stored.
> >
> > Add a check which prevents configuring switchdev mode if uplink is
> > already added to any bridge. This is needed because we need to listen
> > for NETDEV_CHANGEUPPER events to record if the uplink was added to
> > the bridge. Netdevice notifier is registered after eswitch mode
> > is changed top switchdev.
>
> Hi Wojciech,
>
> Does the uplink here model both a physical port and the PF link between the
> host and the NIC? If so, then I think this is ok.
>
> I mention this because I am more familiar with a model where these are
> separated, in which case I think it would probably be an uplink representor
> that is added to the bridge. And I want to make sure make sure that I
> understand the model used here correctly.
In our design we don't have separate uplink rpresentor. PF netdev serves as uplink
repr once the eswitch mode is changed to switchdev.
Powered by blists - more mailing lists