From: Jiri Pirko <jiri@resnulli.us>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Parav Pandit <parav@mellanox.com>,
"Samudrala, Sridhar" <sridhar.samudrala@intel.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"oss-drivers@netronome.com" <oss-drivers@netronome.com>
Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI ports
Date: Mon, 18 Mar 2019 13:11:54 +0100 [thread overview]
Message-ID: <20190318121154.GG2270@nanopsycho> (raw)
In-Reply-To: <20190315134454.581f47ca@cakuba.netronome.com>
Fri, Mar 15, 2019 at 09:44:54PM CET, jakub.kicinski@netronome.com wrote:
>On Fri, 15 Mar 2019 21:08:14 +0100, Jiri Pirko wrote:
>> >> IIUC, Jiri/Jakub are proposing creation of 2 devlink objects for each port -
>> >> host facing ports and switch facing ports. This is in addition to the netdevs
>> >> that are created today.
>
>To be clear I'm not in favour of the dual-object proposal.
>
>> >I am not proposing any different.
>> >I am proposing only two changes.
>> >1. control hostport params via referring hostport (not via indirect peer)
>>
>> Not really possible. If you passthrough VF into VM, the hostport goes
>> along with it.
>>
>> >2. flavour should not be vf/pf, flavour should be hostport, switchport.
>> >Because switch is flat and agnostic of pf/vf/mdev.
>>
>> Not sure. It's good to have this kind of visibility.
>
>Yes, this subthread honestly makes me go from 60% sure to 95% sure we
>shouldn't do the dual object thing :( Seems like Parav is already
>confused by it and suggests host port can exist without switch port :(
Although I understand your hesitation, the host ports are also
associated with the asic and should be under the devlink instance.
It is just a matter of proper documentation and clear code to avoid
confusions.
>
>> >> Are you suggesting that all the devlink objects should be visible only at the
>> >> hypervisor layer?
>> >>
>> >Of course not.
>> >
>> >Ports and params controlled by hypervisor should be exposed at hypervisor/eswitch wherever its parent devlink instance exist.
>> >Ports which should be visible inside a VM should be exposed inside a VM.
>> >So for a given VF,
>> >
>> >If eswitch is at hypervisor level,
>> >$ devlink port show
>> >pci/0000:05:00.0/10002 eth netdev flavour switchport switch_id 00154d130d2f peer pci/0000:05:10.1/0
>> >pci/0000:05:10.1/0 eth netdev flavour hostport switch_id 00154d130d2f peer pci/0000:05:00.0/10002
>> >
>> >where VF is enumerated,
>> >$ devlink port show
>> >pci/0000:05:10.1/0 eth netdev flavour hostport
>>
>> So this is how it looks like in VM, right?
>>
>> >This is because unprivileged VF doesn't have visibility to eswitch and its links.
>
next prev parent reply other threads:[~2019-03-18 12:22 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-01 18:04 [PATCH net-next v2 0/7] devlink: expose PF and VF representors as ports Jakub Kicinski
2019-03-01 18:04 ` [PATCH net-next v2 1/7] nfp: split devlink port init from registration Jakub Kicinski
2019-03-01 18:04 ` [PATCH net-next v2 2/7] devlink: add PF and VF port flavours Jakub Kicinski
2019-03-01 18:04 ` [PATCH net-next v2 3/7] nfp: register devlink ports of all reprs Jakub Kicinski
2019-03-02 8:43 ` Jiri Pirko
2019-03-02 19:07 ` Jakub Kicinski
2019-03-04 7:36 ` Jiri Pirko
2019-03-04 23:32 ` Jakub Kicinski
2019-03-01 18:04 ` [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI ports Jakub Kicinski
2019-03-02 9:41 ` Jiri Pirko
2019-03-02 19:48 ` Jakub Kicinski
2019-03-04 7:56 ` Jiri Pirko
2019-03-05 0:33 ` Jakub Kicinski
2019-03-05 11:06 ` Jiri Pirko
2019-03-05 17:15 ` Jakub Kicinski
2019-03-05 19:59 ` Parav Pandit
2019-03-06 12:20 ` Jiri Pirko
2019-03-06 17:56 ` Jakub Kicinski
2019-03-07 3:56 ` Parav Pandit
2019-03-07 9:48 ` Jiri Pirko
2019-03-08 2:52 ` Jakub Kicinski
2019-03-08 14:54 ` Jiri Pirko
2019-03-08 19:09 ` Jakub Kicinski
2019-03-11 8:52 ` Jiri Pirko
2019-03-12 2:10 ` Jakub Kicinski
2019-03-12 14:02 ` Jiri Pirko
2019-03-12 20:56 ` Jakub Kicinski
2019-03-13 6:07 ` Jiri Pirko
2019-03-13 16:17 ` Jakub Kicinski
2019-03-13 16:22 ` Jiri Pirko
2019-03-13 16:55 ` Jakub Kicinski
2019-03-14 7:38 ` Jiri Pirko
2019-03-14 22:09 ` Jakub Kicinski
2019-03-14 22:35 ` Parav Pandit
2019-03-14 23:39 ` Jakub Kicinski
2019-03-15 1:28 ` Parav Pandit
2019-03-15 1:31 ` Parav Pandit
2019-03-15 2:15 ` Samudrala, Sridhar
2019-03-15 2:40 ` Parav Pandit
[not found] ` <ae938b4f-5fa9-3c33-8ae6-eab2d3d9f1ec@intel.com>
2019-03-15 15:32 ` Parav Pandit
2019-03-15 20:08 ` Jiri Pirko
2019-03-15 20:44 ` Jakub Kicinski
2019-03-15 22:12 ` Parav Pandit
2019-03-16 1:16 ` Jakub Kicinski
2019-03-18 15:43 ` Parav Pandit
2019-03-18 19:29 ` Jakub Kicinski
2019-03-18 12:11 ` Jiri Pirko [this message]
2019-03-18 19:16 ` Jakub Kicinski
2019-03-21 8:45 ` Jiri Pirko
2019-03-21 15:14 ` Parav Pandit
2019-03-21 16:14 ` Jiri Pirko
2019-03-21 16:52 ` Parav Pandit
2019-03-21 17:20 ` Jiri Pirko
2019-03-21 17:34 ` Parav Pandit
2019-03-22 16:27 ` Jiri Pirko
2019-03-23 0:37 ` Parav Pandit
2019-03-15 21:59 ` Parav Pandit
2019-03-18 12:21 ` Jiri Pirko
2019-03-18 15:56 ` Parav Pandit
2019-03-18 16:22 ` Parav Pandit
2019-03-18 19:36 ` Jakub Kicinski
2019-03-18 19:44 ` Parav Pandit
2019-03-18 19:59 ` Jakub Kicinski
2019-03-18 20:35 ` Parav Pandit
2019-03-18 21:29 ` Jakub Kicinski
2019-03-18 22:11 ` Parav Pandit
2019-03-20 18:24 ` Parav Pandit
2019-03-20 20:22 ` Jakub Kicinski
2019-03-20 23:39 ` Parav Pandit
2019-03-21 9:08 ` Jiri Pirko
2019-03-21 15:03 ` Parav Pandit
2019-03-21 16:16 ` Jiri Pirko
2019-03-21 16:50 ` Parav Pandit
2019-03-21 17:23 ` Jiri Pirko
2019-03-21 17:42 ` Parav Pandit
2019-03-22 13:32 ` Jiri Pirko
2019-03-23 0:40 ` Parav Pandit
2019-03-25 20:34 ` Parav Pandit
2019-03-18 19:19 ` Jakub Kicinski
2019-03-18 19:38 ` Parav Pandit
2019-03-21 9:09 ` Jiri Pirko
2019-03-15 7:00 ` Jiri Pirko
[not found] ` <7227d58e-ac58-d549-b921-ca0a0dd3f4b0@intel.com>
2019-03-13 7:37 ` Jiri Pirko
2019-03-13 16:03 ` Samudrala, Sridhar
2019-03-13 16:24 ` Jiri Pirko
2019-03-04 11:19 ` Jiri Pirko
2019-03-05 0:40 ` Jakub Kicinski
2019-03-05 11:07 ` Jiri Pirko
2019-03-04 11:08 ` Jiri Pirko
2019-03-05 0:51 ` Jakub Kicinski
2019-03-05 11:09 ` Jiri Pirko
2019-03-01 18:04 ` [PATCH net-next v2 5/7] nfp: switch to devlink_port_get_phys_port_name() Jakub Kicinski
2019-03-01 18:04 ` [PATCH net-next v2 6/7] devlink: introduce port's peer netdevs Jakub Kicinski
2019-03-01 18:04 ` [PATCH net-next v2 7/7] nfp: expose PF " Jakub Kicinski
2019-03-02 10:13 ` [PATCH net-next v2 0/7] devlink: expose PF and VF representors as ports Jiri Pirko
2019-03-02 19:49 ` [oss-drivers] " Jakub Kicinski
2019-03-04 5:12 ` Parav Pandit
2019-03-04 18:22 ` David Miller
2019-03-20 20:25 ` Jakub Kicinski
2019-03-21 9:11 ` 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=20190318121154.GG2270@nanopsycho \
--to=jiri@resnulli.us \
--cc=davem@davemloft.net \
--cc=jakub.kicinski@netronome.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@netronome.com \
--cc=parav@mellanox.com \
--cc=sridhar.samudrala@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.