From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC021C43381 for ; Fri, 15 Mar 2019 22:12:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ACF49218A1 for ; Fri, 15 Mar 2019 22:12:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=Mellanox.com header.i=@Mellanox.com header.b="JNfShTaU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727170AbfCOWMS (ORCPT ); Fri, 15 Mar 2019 18:12:18 -0400 Received: from mail-eopbgr20045.outbound.protection.outlook.com ([40.107.2.45]:31042 "EHLO EUR02-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727118AbfCOWMS (ORCPT ); Fri, 15 Mar 2019 18:12:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I3GDBp0fAAwsOl8aKVExeyGT4K5h2Hz8O1UyDgDgsBg=; b=JNfShTaUFtQXC8+tPyYEevqXxHNTnf5npZ2UuROWvA/WS0a8jPfRtU7PfuACrFxp/0bu/nSFr2KeF8kjRiNs7F/a63TBpp7Ix0RmnjoGTkNZs9GO7PNgCpCiLaXHhOQnSm36g3dENhk759PAbLJPhH9heX1YNmSKL/N5/VXUmeY= Received: from VI1PR0501MB2271.eurprd05.prod.outlook.com (10.169.135.8) by VI1PR0501MB2559.eurprd05.prod.outlook.com (10.168.137.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Fri, 15 Mar 2019 22:12:14 +0000 Received: from VI1PR0501MB2271.eurprd05.prod.outlook.com ([fe80::a0b8:7ed8:d657:2f59]) by VI1PR0501MB2271.eurprd05.prod.outlook.com ([fe80::a0b8:7ed8:d657:2f59%6]) with mapi id 15.20.1709.011; Fri, 15 Mar 2019 22:12:13 +0000 From: Parav Pandit To: Jakub Kicinski , Jiri Pirko CC: "Samudrala, Sridhar" , "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 Thread-Topic: [PATCH net-next v2 4/7] devlink: allow subports on devlink PCI ports Thread-Index: AQHU0FlVGn07mv/5S0qtfXL/6zV0naX4F3YAgACpvYCAAl2OgIABFocAgACw24CAAGdAAIABP+yAgABd4gCAAQniAIABHgoAgADJ0ICAAEdZgIAECm0AgAEiPwCAAMbcgIAAc58AgACZ0oCAAKqSgIAAAXSAgAAJR4CAAPajAIAA82GAgAAGytCAABI3gIAAHF7AgAAPYgCAAAD0MIAAPSgAgACeBbCAAE9/AIAACj8AgAAU6MA= Date: Fri, 15 Mar 2019 22:12:13 +0000 Message-ID: References: <20190313095555.0f4f92ca@cakuba.attlocal.net> <20190314073840.GA3034@nanopsycho> <20190314150945.031d1b08@cakuba.netronome.com> <20190314163915.24fd2481@cakuba.netronome.com> <4436da3d-4b99-f792-8e77-695d5958794d@intel.com> <20190315200814.GD2305@nanopsycho> <20190315134454.581f47ca@cakuba.netronome.com> In-Reply-To: <20190315134454.581f47ca@cakuba.netronome.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=parav@mellanox.com; x-originating-ip: [208.176.44.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f9fbc984-aa54-4a28-4b0b-08d6a993473c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020);SRVR:VI1PR0501MB2559; x-ms-traffictypediagnostic: VI1PR0501MB2559: x-microsoft-antispam-prvs: x-forefront-prvs: 09778E995A x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(366004)(346002)(136003)(39860400002)(376002)(396003)(13464003)(52054003)(189003)(199004)(5660300002)(9686003)(74316002)(33656002)(561944003)(478600001)(14454004)(25786009)(8936002)(68736007)(8676002)(76176011)(476003)(256004)(102836004)(7696005)(446003)(11346002)(6506007)(81166006)(486006)(66066001)(52536014)(105586002)(106356001)(93886005)(81156014)(97736004)(53546011)(316002)(6246003)(186003)(53936002)(229853002)(26005)(6436002)(110136005)(305945005)(55016002)(3846002)(54906003)(6116002)(86362001)(99286004)(4326008)(2906002)(71200400001)(7736002)(71190400001);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0501MB2559;H:VI1PR0501MB2271.eurprd05.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;MX:1;A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2bcLm5iW4GJgDPVAI9CfMlRnBGVu54ZJnhP1nDFDPxrf7d2pEwfG9uKQlz78ZvlgoINv2qIc8T2Vam5IW8g/ZQwQvXtzTGznRWXJXVquAHHUES99m/HCH4BisPKFj8kw2Q88GSi1O6keEK6v9A5rsW8i/i8ROB6mGUnPCE00tnRoDMiMYedee+WmU3HBj6RlG3I/y9GZWcdt9nxSzwIVarxmCbxRoTKBvMAP0u/rx+rXvRQ+ZAvycV2m7OAJHSlBQoeFGm9U/VyjZxk8nns5EqMiE88qvkvd9GDel1/WocbiVQoUowavaxdGABtEieHiV8GcITfu1nHNDpFAxV2WMm7MJ4IVUIjp7bDlYjpVGZW0pXfcmADu1Z7vWdtFYDH6T1rH44H/DA0llgHMwvZdY14YikbKqklPMCkadukfBkw= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: f9fbc984-aa54-4a28-4b0b-08d6a993473c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2019 22:12:13.7932 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0501MB2559 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > -----Original Message----- > From: Jakub Kicinski > Sent: Friday, March 15, 2019 3:45 PM > To: Jiri Pirko > Cc: Parav Pandit ; Samudrala, Sridhar > ; davem@davemloft.net; > netdev@vger.kernel.org; oss-drivers@netronome.com > Subject: Re: [PATCH net-next v2 4/7] devlink: allow subports on devlink P= CI > ports >=20 > 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. >=20 > To be clear I'm not in favour of the dual-object proposal. >=20 > > >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. >=20 > 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 confus= ed by > it and suggests host port can exist without switch port :( > I am almost sure that I am not confused. I am clear that hostports should be configured by devlink instance which has the capability to program it. When hostport is in VF, that VF usually won't have privilege to program it and won't have visibility to eswitch either. Why would you like to start with restrictive model of peer view only? Hostports exist for infiniband HCA without switchport. We should be able to manage hostport objects without creating fake eswitch = sw object. Jakub, Can you please point to some example other than veth-pair where you configu= re host param (such as mac address) through a switch? An existing example will help me to map it to devlink eswitch proposal. If we go peer programming route, what are your thoughts on how should we program infiniband hostports which doesn't have peer ports? > > >> 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 V= M. > > >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.