From: Parav Pandit <parav@mellanox.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Jiri Pirko <jiri@resnulli.us>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
Yuval Avnery <yuvalav@mellanox.com>,
"jgg@ziepe.ca" <jgg@ziepe.ca>,
Saeed Mahameed <saeedm@mellanox.com>,
"leon@kernel.org" <leon@kernel.org>,
"andrew.gospodarek@broadcom.com" <andrew.gospodarek@broadcom.com>,
"michael.chan@broadcom.com" <michael.chan@broadcom.com>,
Moshe Shemesh <moshe@mellanox.com>, Aya Levin <ayal@mellanox.com>,
Eran Ben Elisha <eranbe@mellanox.com>,
Vlad Buslov <vladbu@mellanox.com>,
Yevgeny Kliteynik <kliteyn@mellanox.com>,
"dchickles@marvell.com" <dchickles@marvell.com>,
"sburla@marvell.com" <sburla@marvell.com>,
"fmanlunas@marvell.com" <fmanlunas@marvell.com>,
Tariq Toukan <tariqt@mellanox.com>,
"oss-drivers@netronome.com" <oss-drivers@netronome.com>,
"snelson@pensando.io" <snelson@pensando.io>,
"drivers@pensando.io" <drivers@pensando.io>,
"aelior@marvell.com" <aelior@marvell.com>,
"GR-everest-linux-l2@marvell.com"
<GR-everest-linux-l2@marvell.com>,
"grygorii.strashko@ti.com" <grygorii.strashko@ti.com>,
mlxsw <mlxsw@mellanox.com>, Ido Schimmel <idosch@mellanox.com>,
Mark Zhang <markz@mellanox.com>,
"jacob.e.keller@intel.com" <jacob.e.keller@intel.com>,
Alex Vesker <valex@mellanox.com>,
"linyunsheng@huawei.com" <linyunsheng@huawei.com>,
"lihong.yang@intel.com" <lihong.yang@intel.com>,
"vikas.gupta@broadcom.com" <vikas.gupta@broadcom.com>,
"magnus.karlsson@intel.com" <magnus.karlsson@intel.com>
Subject: RE: [RFC] current devlink extension plan for NICs
Date: Wed, 1 Apr 2020 07:32:46 +0000 [thread overview]
Message-ID: <AM0PR05MB4866E76AE83EA4D09449AF05D1C90@AM0PR05MB4866.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <20200331103255.549ea899@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Tuesday, March 31, 2020 11:03 PM
>
> On Tue, 31 Mar 2020 07:45:51 +0000 Parav Pandit wrote:
> > > In fact very little belongs to the port in that model. So why have
> > > PCI ports in the first place?
> > >
> > for few reasons.
> > 1. PCI ports are establishing the relationship between eswitch port
> > and its representor netdevice.
> > Relying on plain netdev name doesn't work in certain pci topology
> > where netdev name exceeds 15 characters.
> > 2. health reporters can be at port level.
>
> Why? The health reporters we have not AFAIK are for FW and for queues
> hanging. Aren't queues on the slice and FW on the device?
There are multiple heath reporters per object.
There are per q health reporters on the representor queues (and representors are attached to devlink port).
Can someone can have representor netdev for an eswitch port without devlink port?
No, net/core/devlink.c cross verify this and do WARN_ON.
So devlink port for eswitch are linked to representors and are needed.
Their existence is not a replacement for representing 'portion of the device'.
>
> > 3. In future at eswitch pci port, I will be adding dpipe support for
> > the internal flow tables done by the driver.
> > 4. There were inconsistency among vendor drivers in using/abusing
> > phys_port_name of the eswitch ports. This is consolidated via devlink
> > port in core. This provides consistent view among all vendor drivers.
> >
> > So PCI eswitch side ports are useful regardless of slice.
> >
> > >> Additionally devlink port object doesn't go through the same state
> > >> machine as that what slice has to go through.
> > >> So its weird that some devlink port has state machine and some doesn't.
> > >
> > > You mean for VFs? I think you can add the states to the API.
> > >
> > As we agreed above that eswitch side objects (devlink port and
> > representor netdev) should not be used for 'portion of device',
>
> We haven't agreed, I just explained how we differ.
You mentioned that " Right, in my mental model representor _is_ a port of the eswitch, so repr would not make sense to me."
With that I infer that 'any object that is directly and _always_ linked to eswitch and represents an eswitch port is out of question, this includes devlink port of eswitch and netdev representor.
Hence, the comment 'we agree conceptually' to not involve devlink port of eswitch and representor netdev to represent 'portion of the device'.
next prev parent reply other threads:[~2020-04-01 7:32 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-19 19:27 [RFC] current devlink extension plan for NICs Jiri Pirko
2020-03-20 3:32 ` Jakub Kicinski
2020-03-20 7:35 ` Jiri Pirko
2020-03-20 21:25 ` Jakub Kicinski
2020-03-21 9:07 ` Parav Pandit
2020-03-23 19:31 ` Jakub Kicinski
2020-03-23 22:50 ` Jason Gunthorpe
2020-03-24 3:41 ` Jakub Kicinski
2020-03-24 13:43 ` Jason Gunthorpe
2020-03-24 5:36 ` Parav Pandit
2020-03-21 9:35 ` Jiri Pirko
2020-03-23 19:21 ` Jakub Kicinski
2020-03-23 22:06 ` Jason Gunthorpe
2020-03-24 3:56 ` Jakub Kicinski
2020-03-24 13:20 ` Jason Gunthorpe
2020-03-26 14:37 ` Jiri Pirko
2020-03-26 14:43 ` Jiri Pirko
2020-03-26 14:47 ` Jiri Pirko
2020-03-26 14:51 ` Jiri Pirko
2020-03-26 20:30 ` Jakub Kicinski
2020-03-27 7:47 ` Jiri Pirko
2020-03-27 16:38 ` Jakub Kicinski
2020-03-27 18:49 ` Samudrala, Sridhar
2020-03-27 19:10 ` Jakub Kicinski
2020-03-27 19:45 ` Saeed Mahameed
2020-03-27 20:42 ` Jakub Kicinski
2020-03-30 9:07 ` Parav Pandit
2020-04-08 6:10 ` Parav Pandit
2020-03-27 20:47 ` Samudrala, Sridhar
2020-03-27 20:59 ` Jakub Kicinski
2020-03-30 7:09 ` Parav Pandit
2020-03-30 7:48 ` Parav Pandit
2020-03-30 19:36 ` Jakub Kicinski
2020-03-31 7:45 ` Parav Pandit
2020-03-31 17:32 ` Jakub Kicinski
2020-04-01 7:32 ` Parav Pandit [this message]
2020-04-01 20:12 ` Jakub Kicinski
2020-04-02 6:16 ` Jiri Pirko
2020-04-08 5:10 ` Parav Pandit
2020-04-08 5:07 ` Parav Pandit
2020-04-08 16:59 ` Jakub Kicinski
2020-04-08 18:13 ` Parav Pandit
2020-04-09 2:07 ` Jakub Kicinski
2020-04-09 6:43 ` Parav Pandit
2020-03-30 5:30 ` Parav Pandit
2020-03-26 14:59 ` Jiri Pirko
2020-03-23 23:32 ` Andy Gospodarek
2020-03-24 0:11 ` Jason Gunthorpe
2020-03-24 5:53 ` Parav Pandit
2020-03-23 21:32 ` Andy Gospodarek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AM0PR05MB4866E76AE83EA4D09449AF05D1C90@AM0PR05MB4866.eurprd05.prod.outlook.com \
--to=parav@mellanox.com \
--cc=GR-everest-linux-l2@marvell.com \
--cc=aelior@marvell.com \
--cc=andrew.gospodarek@broadcom.com \
--cc=ayal@mellanox.com \
--cc=davem@davemloft.net \
--cc=dchickles@marvell.com \
--cc=drivers@pensando.io \
--cc=eranbe@mellanox.com \
--cc=fmanlunas@marvell.com \
--cc=grygorii.strashko@ti.com \
--cc=idosch@mellanox.com \
--cc=jacob.e.keller@intel.com \
--cc=jgg@ziepe.ca \
--cc=jiri@resnulli.us \
--cc=kliteyn@mellanox.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=lihong.yang@intel.com \
--cc=linyunsheng@huawei.com \
--cc=magnus.karlsson@intel.com \
--cc=markz@mellanox.com \
--cc=michael.chan@broadcom.com \
--cc=mlxsw@mellanox.com \
--cc=moshe@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@netronome.com \
--cc=saeedm@mellanox.com \
--cc=sburla@marvell.com \
--cc=snelson@pensando.io \
--cc=tariqt@mellanox.com \
--cc=valex@mellanox.com \
--cc=vikas.gupta@broadcom.com \
--cc=vladbu@mellanox.com \
--cc=yuvalav@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).