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 8D6FEC43381 for ; Fri, 15 Mar 2019 01:32:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 461FA21872 for ; Fri, 15 Mar 2019 01:32:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=Mellanox.com header.i=@Mellanox.com header.b="M2k/m+0P" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727642AbfCOBb6 (ORCPT ); Thu, 14 Mar 2019 21:31:58 -0400 Received: from mail-eopbgr70043.outbound.protection.outlook.com ([40.107.7.43]:38695 "EHLO EUR04-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727284AbfCOBb6 (ORCPT ); Thu, 14 Mar 2019 21:31:58 -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=s3lxxibZ6W0V+yeK4LGn98xy+hshHQQVFCevAoOWvT8=; b=M2k/m+0PO2tl+X8naMe7gPoMQrGeqSZp5hRjKcU7haSeoSdv7ed0OK3il2W4z4yQmDzKIaTBID6aq4pZJYuXwUadAk7P1Mze3RCbM15qHCgbg6Byz7B5p5VobGneRNmdcnvNcwE3g3HNf1svR1B0HRnbKQHg59fjgR7gA+7iJBc= Received: from VI1PR0501MB2271.eurprd05.prod.outlook.com (10.169.135.8) by VI1PR0501MB2543.eurprd05.prod.outlook.com (10.168.136.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13; Fri, 15 Mar 2019 01:31:52 +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:31:52 +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+yAgABd4gCAAQniAIABHgoAgADJ0ICAAEdZgIAECm0AgAEiPwCAAMbcgIAAc58AgACZ0oCAAKqSgIAAAXSAgAAJR4CAAPajAIAA82GAgAAGytCAABI3gIAAHF7AgAAClfA= Date: Fri, 15 Mar 2019 01:31:52 +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: 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: 865ad589-d7b0-4640-eaaf-08d6a8e600c3 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:VI1PR0501MB2543; x-ms-traffictypediagnostic: VI1PR0501MB2543: x-microsoft-antispam-prvs: x-forefront-prvs: 09778E995A x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(366004)(376002)(136003)(39840400004)(346002)(396003)(13464003)(199004)(189003)(6436002)(81166006)(93156006)(53936002)(256004)(93886005)(6116002)(14444005)(25786009)(4326008)(14454004)(2906002)(8936002)(229853002)(476003)(6246003)(7736002)(305945005)(74316002)(86362001)(486006)(76176011)(6916009)(68736007)(11346002)(99286004)(55016002)(9686003)(33656002)(446003)(2940100002)(54906003)(7696005)(105586002)(106356001)(8676002)(5660300002)(97736004)(71190400001)(81156014)(71200400001)(53546011)(102836004)(6506007)(316002)(46003)(478600001)(186003)(52536014);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0501MB2543;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: VqyyXAKjj21EyFGpluRw05V0Ry4wQ3mrDFUh0G3EE/NxKL5xuObOt78J1F0GTs8OJgTqJgfLLoodIynl4pqOylYxu9vXx8iZcf5k0GV6o5U42+7+jycn5JBcAJDUdV0SUB9wiknEKKDRuyGGtXSHHbmQIdz72JTwG63M78hjfVaWlrqcCOgwyBdzSYzVFnKuOxpqxvWdYES3t9a/CVqtEyT2kmgSENFLlV7dEt0JjpXgdkvHEc/ySOZHMcD3t8BQjqX2DJYejh5PEqp3meXmvC9eyPZXmIda3RXNZzn9dJ3DUZCCZyvhz2XBb/4tJrWUckMC+0G/9OoccvU3iLQSVAKLH8pjoNJPEn/OorH+QoE61ea/P7l2UObVwA5dumQi9oIWJVhO0B+I9YpbOxRUiQ+sjgRfIptNkDOs4mEQwh4= 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: 865ad589-d7b0-4640-eaaf-08d6a8e600c3 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2019 01:31:52.6646 (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: VI1PR0501MB2543 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > -----Original Message----- > From: Parav Pandit > Sent: Thursday, March 14, 2019 8:29 PM > 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 P= CI > ports >=20 >=20 >=20 > > -----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 PCI ports > > > > 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. > > > > Please look at the quote of what Jiri wrote above - the host port gets > > passed to the VM, you can't use it as a handle to set the MAC. > > > > The way to set the MAC remains: > > > > # devlink port set pci/0000:05:00.0/10002 peer mac_addr > > 00:11:22:33:44:55 > > > Even though it can be done, I think this is wrong model to program hostpo= rt > 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. >=20 This also make sense for rdma where there are only hostports, and it doesn'= t have any peer switch ports. User needs to configure node guid and port_guid. Programming port_guid for 'hostport' also aligns for this requirement. We better not program hostport params using this convoluted indirect way. > 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 worki= ng. > At eswitch level it is just a port, it happen to be connected to vf or pf= or > other objects, it doesn't matter. > Port should be flavoured as 'hostport' or 'switchport'. >=20 >=20 > > (using the port ids from above)