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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <VI1PR0501MB2271E5935F2DFF94260A7594D1420@VI1PR0501MB2271.eurprd05.prod.outlook.com>
Date:   Thu, 21 Mar 2019 16:52:09 +0000
From:   Parav Pandit <parav@...lanox.com>
To:     Jiri Pirko <jiri@...nulli.us>
CC:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        "Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>
Subject: RE: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI
 ports



> -----Original Message-----
> From: Jiri Pirko <jiri@...nulli.us>
> Sent: Thursday, March 21, 2019 11:14 AM
> To: Parav Pandit <parav@...lanox.com>
> Cc: Jakub Kicinski <jakub.kicinski@...ronome.com>; Samudrala, Sridhar
> <sridhar.samudrala@...el.com>; davem@...emloft.net;
> netdev@...r.kernel.org; oss-drivers@...ronome.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@...lanox.com wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jiri Pirko <jiri@...nulli.us>
> >> Sent: Thursday, March 21, 2019 3:45 AM
> >> To: Jakub Kicinski <jakub.kicinski@...ronome.com>
> >> Cc: Parav Pandit <parav@...lanox.com>; Samudrala, Sridhar
> >> <sridhar.samudrala@...el.com>; davem@...emloft.net;
> >> netdev@...r.kernel.org; oss-drivers@...ronome.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@...ronome.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.