From: "Samudrala, Sridhar" <sridhar.samudrala@intel.com>
To: Jiri Pirko <jiri@resnulli.us>, netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, parav@mellanox.com,
yuvalav@mellanox.com, jgg@ziepe.ca, saeedm@mellanox.com,
leon@kernel.org, andrew.gospodarek@broadcom.com,
michael.chan@broadcom.com, moshe@mellanox.com, ayal@mellanox.com,
eranbe@mellanox.com, vladbu@mellanox.com, kliteyn@mellanox.com,
dchickles@marvell.com, sburla@marvell.com, fmanlunas@marvell.com,
tariqt@mellanox.com, oss-drivers@netronome.com,
snelson@pensando.io, drivers@pensando.io, aelior@marvell.com,
GR-everest-linux-l2@marvell.com, grygorii.strashko@ti.com,
mlxsw@mellanox.com, idosch@mellanox.com, markz@mellanox.com,
jacob.e.keller@intel.com, valex@mellanox.com,
linyunsheng@huawei.com, lihong.yang@intel.com,
vikas.gupta@broadcom.com
Subject: Re: [RFC v2] current devlink extension plan for NICs
Date: Sun, 3 May 2020 19:12:18 -0700 [thread overview]
Message-ID: <80453af6-7cb3-59a7-910e-2fc69263ebde@intel.com> (raw)
In-Reply-To: <20200501091449.GA25211@nanopsycho.orion>
On 5/1/2020 2:14 AM, Jiri Pirko wrote:
> Hi all.
>
> First, I would like to apologize for very long email. But I think it
> would be beneficial to the see the whole picture, where we are going.
>
> Currently we are working internally on several features with
> need of extension of the current devlink infrastructure. I took a stab
> at putting it all together in a single txt file, inlined below.
>
> Most of the stuff is based on a new port sub-object called "func"
> (called "slice" previously" and "subdev" originally in Yuval's patchsets
> sent some while ago).
>
> The text describes how things should behave and provides a draft
> of user facing console input/outputs. I think it is important to clear
> that up before we go in and implement the devlink core and
> driver pieces.
>
> I would like to ask you to read this and comment. Especially, I would
> like to ask vendors if what is described fits the needs of your
> NIC/e-switch.
>
> Please note that something is already implemented, but most of this
> isn't (see "what needs to be implemented" section).
>
> v1->v2
> - mainly move from separate slice object into port/func subobject
> - couple of small fixes here and there
>
<snip>
>
>
>
> ==================================================================
> || ||
> || Port func user cmdline API draft ||
> || ||
> ==================================================================
>
> Note that some of the "devlink port" attributes may be forgotten or misordered.
>
> Funcs are created as sub-objects of ports where it makes sense to have them
> The driver takes care of that. The "func" is a handle to configure "the other
> side of the wire". The original port object has port leve properties,
> the new "func" sub-object on the other hand has device level properties".
>
> This is example for the HOST A from the example above:
>
> $ devlink port show
> pci/0000:06:00.0/0: flavour physical pfnum 0 type eth netdev enp6s0f0np1
> pci/0000:06:00.0/1: flavour physical pfnum 1 type eth netdev enp6s0f0np2
> pci/0000:06:00.0/2: flavour pcipf pfnum 2 type eth netdev enp6s0pf2
> func: hw_addr 10:22:33:44:55:66 state active
> pci/0000:06:00.0/3: flavour pcivf pfnum 2 vfnum 0 type eth netdev enp6s0pf2vf0
> func: hw_addr 10:22:33:44:55:77 state active
> pci/0000:06:00.0/4: flavour pcivf pfnum 0 vfnum 0 type eth netdev enp6s0pf0vf0
> func: hw_addr 10:22:33:44:55:88 state active
> pci/0000:06:00.0/5: flavour pcisf pfnum 0 sfnum 1 type eth netdev enp6s0pf0sf1
> func: hw_addr 10:22:33:44:55:99 state active
> pci/0000:06:00.0/6: flavour pcivf pfnum 1 vfnum 2 type nvme
> func: state active
I am trying to understand how the current implementation of 'devlink
port' is being refactored to support this new model.
Today 'devlink port show' on a system with 2 port mlx5 NIC with 1 VFs
created on each PF shows
pci/0000:af:00.0/1: type eth netdev enp175s0f0np0 flavour physical port 0
pci/0000:af:00.1/1: type eth netdev enp175s0f1np1 flavour physical port 1
pci/0000:af:00.2/1: type eth netdev enp175s0f2np0 flavour virtual port 0
pci/0000:af:08.2/1: type eth netdev enp175s8f2np0 flavour virtual port 0
Can you tell me how this will be represented in the new model?
It looks like you are assigning a pfnum to physical port as well as PCI
PF. However, i am little confused as both pfnum 0 and pfnum 1 which seem
to be 2 physical ports have the same bus/dev/func 06:00.0 and also the
VF ports.
Thanks
Sridhar
next prev parent reply other threads:[~2020-05-04 2:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-01 9:14 [RFC v2] current devlink extension plan for NICs Jiri Pirko
2020-05-04 2:12 ` Samudrala, Sridhar [this message]
2020-05-04 11:42 ` Jiri Pirko
2020-05-10 14:45 ` Jiri Pirko
2020-05-10 16:30 ` Dave Taht
2020-05-11 5:32 ` Jiri Pirko
2020-05-11 22:37 ` Jacob Keller
2020-05-13 13:00 ` [oss-drivers] " Simon Horman
2020-05-14 6:07 ` Jiri Pirko
2020-05-14 23:52 ` Jacob Keller
2020-05-15 9:30 ` Jiri Pirko
2020-05-15 21:36 ` Jacob Keller
2020-05-18 6:52 ` Jiri Pirko
2020-05-18 21:05 ` Jacob Keller
2020-05-19 5:17 ` Parav Pandit
2020-05-19 19:45 ` Jacob Keller
2020-05-20 12:58 ` Parav Pandit
2020-05-19 5:19 ` Jiri Pirko
2020-05-19 9:22 ` [RFC v3] " Jiri Pirko
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=80453af6-7cb3-59a7-910e-2fc69263ebde@intel.com \
--to=sridhar.samudrala@intel.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=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=parav@mellanox.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).