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 35D81C43381 for ; Fri, 15 Mar 2019 01:28:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E1A9C21872 for ; Fri, 15 Mar 2019 01:28:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=Mellanox.com header.i=@Mellanox.com header.b="WcmSlgD8" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727986AbfCOB2m (ORCPT ); Thu, 14 Mar 2019 21:28:42 -0400 Received: from mail-eopbgr80052.outbound.protection.outlook.com ([40.107.8.52]:31470 "EHLO EUR04-VI1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727284AbfCOB2m (ORCPT ); Thu, 14 Mar 2019 21:28:42 -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=2VMIpo5rha2wl1JoehkxIL2En25DQEf6OdoCvsjB8gc=; b=WcmSlgD8HwkrlsSe0I6HU7rIDvPJx6jyzvcL7e7XrbuZzIpbCPZrpWYTHPqNoCr+/ymTueL4eXx7A7r5pavifDvzI3kgNdIbVPAIyevFdH7yD3VtnmodYuzQGLKbYnMxJDU7TVu/0fCU3aZ4jOR/OfINT9PbkRfAhXNwP5gW5Ck= Received: from VI1PR0501MB2271.eurprd05.prod.outlook.com (10.169.135.8) by VI1PR0501MB2477.eurprd05.prod.outlook.com (10.168.136.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.20; Fri, 15 Mar 2019 01:28:39 +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 01:28:39 +0000 From: Parav Pandit To: Jakub Kicinski CC: Jiri Pirko , "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+yAgABd4gCAAQniAIABHgoAgADJ0ICAAEdZgIAECm0AgAEiPwCAAMbcgIAAc58AgACZ0oCAAKqSgIAAAXSAgAAJR4CAAPajAIAA82GAgAAGytCAABI3gIAAHF7A Date: Fri, 15 Mar 2019 01:28:38 +0000 Message-ID: References: <20190308145421.GA2888@nanopsycho.orion> <20190308110943.2ee42bc0@cakuba.hsd1.ca.comcast.net> <20190311085204.GA2194@nanopsycho> <20190311191054.36b801d6@cakuba.hsd1.ca.comcast.net> <20190312140239.GA2455@nanopsycho> <20190312135628.5250135b@cakuba.hsd1.ca.comcast.net> <20190313060701.GB2384@nanopsycho.orion> <20190313091731.76129ece@cakuba.attlocal.net> <20190313162243.GB2270@nanopsycho> <20190313095555.0f4f92ca@cakuba.attlocal.net> <20190314073840.GA3034@nanopsycho> <20190314150945.031d1b08@cakuba.netronome.com> <20190314163915.24fd2481@cakuba.netronome.com> In-Reply-To: <20190314163915.24fd2481@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: [2605:6000:ec80:6500:7070:b1b0:9dd8:5624] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d96cbf95-f099-426d-7b78-08d6a8e58d53 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:VI1PR0501MB2477; x-ms-traffictypediagnostic: VI1PR0501MB2477: x-microsoft-exchange-diagnostics: =?us-ascii?Q?1;VI1PR0501MB2477;23:vhPumLYn4jO+mUbPe5Gr6DhISrMW7ry80xrEe66?= =?us-ascii?Q?Oqe9ZU6S0qOKIR42yNxjZZOL0X63J2foE0o7q9jX3eYAOfbrenrwJlejhCYx?= =?us-ascii?Q?tFlBnRoT/qHoorAAV7Lbnq1j7GBIpzhHZNs2rEqlsfFjR0RpK91US2iZKNJU?= =?us-ascii?Q?f5XmlAaVXhSrpqR1Rxux1X0XXZgR0a87Jh7xyH9OUmkyQEvYdQ+ACoNdzkwV?= =?us-ascii?Q?StWU4j+mI7FpPiVbhNMZOl2a4/bcnDyG1NKTtf9i3cA2wcVDGGZ6w6wowtuS?= =?us-ascii?Q?CsmW97jVt2mBwE23nBuwDqCgfgd1QJKolvM6gAse7KGRD4ZFj8qPs0+IJkV+?= =?us-ascii?Q?+DBUU8Uz4PicmVJreiI+7KPJP0mNfHscDxqvS+GIlX6P/CJ9C0aLBhf4fb3v?= =?us-ascii?Q?SFi/7DBYJJ2ttbbNPBt3/acHhbcAvkKsfYgGtk7oV5gWZC7QnRmmh1zZV1Xa?= =?us-ascii?Q?wMvOnlc9GXwBvPetmx3XwwJOsjUHaNIvr+DERQ7CRVqtfuxL7cKpCHVEtqZP?= =?us-ascii?Q?i5tiznc+y3JRqoc3xreYEiW0mgA1S8hFaS8uiFQWLHzCRuU/aXncKDN+EaE0?= =?us-ascii?Q?VJUnyhOvLfIVJvu5HoTFkZ2D6CYBESOc5DWNNDrm3mNpqKSzcMr4irAyDcwJ?= =?us-ascii?Q?I60k0HrdtPtB2trE/kRe+BBc2TUlOsnbxtS3aC2mC1iV87EIRX1bt6OkRfe5?= =?us-ascii?Q?N1AOXHDNEpgXIGft4s8HgRCujgf6FH3ynhSqQSZLm3YhsAXRkXZYx1X4A0D4?= =?us-ascii?Q?0rvMenyfYomQ4skahZinCzKKPW+mDckS9UdvULa9GwC+d21gP7aEQFaS2LYM?= =?us-ascii?Q?LP6aqQlpoJfUKBXRS1ma0kVsdGaoHtcZiGCjmOlGMzwuhWf5dq9qXRSMYutt?= =?us-ascii?Q?l68xFvMYjuaV6De/+NOSN6JCoE1v+T6+4Krq4MCbiMcaRnw9gRT4zDIET4XR?= =?us-ascii?Q?cvtq7oe+hYM0M+Kyy+tg5f6pOlk7BNZhGVH2bMhYNjwDpVxCQD/OlO3Zxp1W?= =?us-ascii?Q?c4A3UboSkhbLShnegD56aKXIv8lkBxPgW7OlXeVlQBLKdrwQ10JkAb2MJVOH?= =?us-ascii?Q?jE9+ZMsQ+ILKo+DuB0B4yPmVzCnbxMr3BiFj95PiPXywKFSDwXX8aMhOJOMs?= =?us-ascii?Q?urReKc/jGZpElTgkELBpjWtYw6+8qw0uR+MWuwgdNOmnMlHmjBzzndYyHhJ1?= =?us-ascii?Q?PFRu6JKHr7qzYMdsicxZVvIs0o2M0mIHwqGxDrbS8L2n5GYWuWRbZsNUUQHJ?= =?us-ascii?Q?oyZj5B5PqnhcJSI3aoLo=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09778E995A x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(376002)(39860400002)(396003)(366004)(346002)(136003)(13464003)(199004)(189003)(7736002)(316002)(7696005)(86362001)(25786009)(53936002)(8936002)(106356001)(478600001)(74316002)(229853002)(9686003)(2906002)(99286004)(76176011)(186003)(4326008)(46003)(52536014)(6506007)(54906003)(105586002)(6116002)(102836004)(93886005)(68736007)(8676002)(53546011)(97736004)(446003)(6916009)(305945005)(55016002)(71190400001)(5660300002)(14454004)(71200400001)(6246003)(11346002)(486006)(476003)(81156014)(14444005)(81166006)(256004)(33656002)(6436002);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0501MB2477;H:VI1PR0501MB2271.eurprd05.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX: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: YsHUDd4G6YNk4dF3oBTRRBPCW9eCgSdDEyYope8u/VBEBX87Stx+4ThcLK73fxUHLbzm9z8NZo+r6c8PA59og1umXAPFI8FP1M1SpxHkn6OiY8WIk+jocj8DSWhiVJkwELz5BlVkj2YSo8WqAIA0FhsI55ASdnI1FJRwczXgtPJb3KCpgDPB5u0qxjymtEBM20jW9HPkDEoG/miNhRC4fxUInboCral808YzlX9oS/VlR3s4HlbVINDiGhISxbMcGEo1dokcb5d/ERZqWJUfjgpSUz2T6o8FfXhZAFBEfNPQdfn1Nj2UWdJORkJ9URJV2iTv/mtsunvTKY/1ju1+gdrCybrn1ABr38kQNny/IDxyKUXTLIflwzfiq44NDLAtNu/c1y0Wx7Gd5+LRqo8a6ZqKol+Ie3U3nRfyxKnvwdI= 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: d96cbf95-f099-426d-7b78-08d6a8e58d53 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2019 01:28:38.9597 (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: VI1PR0501MB2477 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > -----Original Message----- > From: Jakub Kicinski > Sent: Thursday, March 14, 2019 6:39 PM > To: Parav Pandit > Cc: Jiri Pirko ; 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 Thu, 14 Mar 2019 22:35:36 +0000, Parav Pandit wrote: > > > > Then instances of flavour pci_vf are going to appear in the same > > > > devlink instance. Those are the switch ports: > > > > pci/0000:05:00.0/10002: type eth netdev enp5s0npf0pf0s0 > > > > flavour pci_vf pf 0 vf 0 > > > > switch_id 00154d130d2f peer > > > > pci/0000:05:10.1/0 > > > > pci/0000:05:00.0/10003: type eth netdev enp5s0npf0pf0s0 > > > > flavour pci_vf pf 0 vf 0 subport 1 > > > > switch_id 00154d130d2f peer > > > > pci/0000:05:10.1/1 > > > > > > > > With that, peers are going to appear too, and those are the actual > > > > VF/VF > > > > subport: > > > > pci/0000:05:10.1/0: type eth netdev ??? flavour pci_vf_host > > > > peer pci/0000:05:00.0/10002 > > > > pci/0000:05:10.1/1: type eth netdev ??? flavour pci_vf_host > > > > peer pci/0000:05:00.0/10003 > > > > > > > > Later you can push this VF along with all subports to VM. So in > > > > VM, you are going to see the VF like this: > > > > $ devlink dev > > > > pci/0000:00:08.0 > > > > $ devlink port > > > > pci/0000:00:08.0/0: type eth netdev ??? flavour pci_vf_host > > > > pci/0000:00:08.0/1: type eth netdev ??? flavour pci_vf_host > > > > > > > > And back to your question of how are they connected in eswitch. > > > > That is totally up to the original user John who did the creation. > > > > He is in charge of the eswitch on baremetal, he would configure > > > > the forwarding however he likes. > > > > > > Ack, so I think you're saying VM has to communicate to the cloud > > > environment to have this provisioned using some service API, not a > > > kernel API. That's what I wanted to confirm. > > > > > > I don't see any benefit to having the "host ports" under devlink, as = such I > > > think it's a matter of preference. > > > > We need 'host ports' to configure parameters of this host port which > > is not exposed by the rep-netdev. > > Such as mac address. >=20 > Please look at the quote of what Jiri wrote above - the host port gets pa= ssed > to the VM, you can't use it as a handle to set the MAC. >=20 > The way to set the MAC remains: >=20 > # devlink port set pci/0000:05:00.0/10002 peer mac_addr 00:11:22:33:44:55 >=20 Even though it can be done, I think this is wrong model to program hostport= mac address using eswitch port. All devlink objects are control objects, so what is passed to VM is what is= represented by devlink. VF in the VM will anyway create its devlink object. What is wrong in programming hostport? It gives a very clear view to users of topology and objects. Also eswitch is flat. There is no need of pf/vf flavour for port. It doesn't make sense to define 'mdev' flavour which we are already working= . At eswitch level it is just a port, it happen to be connected to vf or pf o= r other objects, it doesn't matter. Port should be flavoured as 'hostport' or 'switchport'. > (using the port ids from above)