[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ3xEMhi1J7w=oCBiAvBEEQ0R=yVxRVVJYb2HygURBqgYEL-BA@mail.gmail.com>
Date: Mon, 3 Sep 2018 12:43:38 +0300
From: Or Gerlitz <gerlitz.or@...il.com>
To: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Cc: Jakub Kicinski <jakub.kicinski@...ronome.com>,
Florian Fainelli <f.fainelli@...il.com>,
Simon Horman <simon.horman@...ronome.com>,
Andy Gospodarek <andy@...yhouse.net>,
"mchan@...adcom.com" <mchan@...adcom.com>,
Jiri Pirko <jiri@...nulli.us>,
Alexander Duyck <alexander.duyck@...il.com>,
Frederick Botha <frederick.botha@...ronome.com>,
nick viljoen <nick.viljoen@...ronome.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: phys_port_id in switchdev mode?
On Fri, Aug 31, 2018 at 11:13 PM, Marcelo Ricardo Leitner
<marcelo.leitner@...il.com> wrote:
> On Tue, Aug 28, 2018 at 08:43:51PM +0200, Jakub Kicinski wrote:
>> Ugh, CC: netdev..
>>
>> On Tue, 28 Aug 2018 20:05:39 +0200, Jakub Kicinski wrote:
>> > Hi!
>> >
>> > I wonder if we can use phys_port_id in switchdev to group together
>> > interfaces of a single PCI PF? Here is the problem:
>
> On Mellanox cards, this is already possible via phys_switch_id, as
> each PF has its own phys_switch_id. So all VFs with a given
> phys_switch_id belong to the PF with that same phys_switch_id.
This is due to the fact that currently when getting into switchdev mode
the PF netdev becomes the uplink representor. This is problematic and we
are working to have an uplink repr as nfp and others have. Bottom line,
this is not the correct way to group PF with it's VFs, switch id is something
that relates to switch port reprs not the entities behind them.
Powered by blists - more mailing lists