Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI ports

[Jiri Pirko <jiri@resnulli.us>]

Thu, Mar 21, 2019 at 06:34:22PM CET, parav@mellanox.com wrote:
>
>
>> -----Original Message-----
>> From: Jiri Pirko <jiri@resnulli.us>
>> Sent: Thursday, March 21, 2019 12:21 PM
>> To: Parav Pandit <parav@mellanox.com>
>> Cc: Jakub Kicinski <jakub.kicinski@netronome.com>; Samudrala, Sridhar
>> <sridhar.samudrala@intel.com>; davem@davemloft.net;
>> netdev@vger.kernel.org; oss-drivers@netronome.com
>> Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI
>> ports
>> 
>> Thu, Mar 21, 2019 at 05:52:09PM CET, parav@mellanox.com wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: Jiri Pirko <jiri@resnulli.us>
>> >> Sent: Thursday, March 21, 2019 11:14 AM
>> >> To: Parav Pandit <parav@mellanox.com>
>> >> Cc: Jakub Kicinski <jakub.kicinski@netronome.com>; Samudrala, Sridhar
>> >> <sridhar.samudrala@intel.com>; davem@davemloft.net;
>> >> netdev@vger.kernel.org; oss-drivers@netronome.com
>> >> Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on
>> >> devlink PCI ports
>> >>
>> >> Thu, Mar 21, 2019 at 04:14:53PM CET, parav@mellanox.com wrote:
>> >> >
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Jiri Pirko <jiri@resnulli.us>
>> >> >> Sent: Thursday, March 21, 2019 3:45 AM
>> >> >> To: Jakub Kicinski <jakub.kicinski@netronome.com>
>> >> >> Cc: Parav Pandit <parav@mellanox.com>; Samudrala, Sridhar
>> >> >> <sridhar.samudrala@intel.com>; davem@davemloft.net;
>> >> >> netdev@vger.kernel.org; oss-drivers@netronome.com
>> >> >> Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on
>> >> >> devlink PCI ports
>> >> >>
>> >> >> Mon, Mar 18, 2019 at 08:16:42PM CET, jakub.kicinski@netronome.com
>> >> >> wrote:
>> >> >> >On Mon, 18 Mar 2019 13:11:54 +0100, Jiri Pirko wrote:
>> >> >> >> >> >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.
>> >> >> >
>> >> >> >They are certainly a part and belong to the ASIC, the question in
>> >> >> >my mind is more along the lines of do we want "one pipe/one port"
>> >> >> >or is it okay to have multiple software objects of the same kind
>> >> >> >for those objects.
>> >> >> >
>> >> >> >To put it differently - do want a port object for each port of
>> >> >> >the ASIC or do we want a port object for each netdev..
>> >> >>
>> >> >> Perhaps "port" name of the object is misleading. From the
>> >> >> beginning, I ment to have it for both switch ports and host ports.
>> >> >> I admit that "host port" is a bit misleading, as it is not really
>> >> >> a port of eswitch, but the counter part. But if we introduce
>> >> >> another object for that purpose in devlink (like "partititon"), it
>> >> >> would be a lot of duplication
>> >> I think.
>> >> >>
>> >> >> Question is, do we need the "host port"? Can't we just put a
>> >> >> relation to host netdev in the eswitch port.
>> >> >>
>> >> >Can you please explain how does it work for rdma for non sriov use
>> case?
>> >> >Do we have to create a fake eswitch object?
>> >>
>> >> Could you please provide details on "rdma for non sriov use case"?
>> >>
>> >There are multiple mdevs on PFs that happen to have link layer as IB and
>> those devlink instances have port that deserved to be configured same way
>> as that of Eth.
>> 
>> Could you please describe it a bit more. There is still an eswitch through
>> which the traffic is going, isn't it?
>Yes, there is an eswitch but it doesn't have switch side of vports.

Why? They should have.


>It is equivalent to legacy mode.
>I hope you are not thinking to create fake eswitch vports. :-)