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 D5969C43381 for ; Thu, 21 Mar 2019 15:04:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8FE5021874 for ; Thu, 21 Mar 2019 15:04:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=Mellanox.com header.i=@Mellanox.com header.b="orRzvf5J" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728145AbfCUPEF (ORCPT ); Thu, 21 Mar 2019 11:04:05 -0400 Received: from mail-eopbgr00071.outbound.protection.outlook.com ([40.107.0.71]:39813 "EHLO EUR02-AM5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726551AbfCUPEF (ORCPT ); Thu, 21 Mar 2019 11:04:05 -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=KGAfXxXLPHVmuS2dpE+p9JiU0wTbz9tDywoH3rjSudI=; b=orRzvf5JUbx+n0QPZZ87I9pEtN2t9J+S+fhh4X+RCT8cA+6plWEBuset+lntojU7HU7NIbW95LdsH/3ipt12mq7Hznp5gTeRfQj2wv73FGnveDb4057dYcFjF9fGmy715UR2wT8/YItWKjFRP347i3lIpqF7xx5o1ppVgCA49ts= Received: from VI1PR0501MB2271.eurprd05.prod.outlook.com (10.169.135.8) by VI1PR0501MB2237.eurprd05.prod.outlook.com (10.169.134.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Thu, 21 Mar 2019 15:03:59 +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.017; Thu, 21 Mar 2019 15:03:59 +0000 From: Parav Pandit To: Jiri Pirko , Jakub Kicinski 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/AIAAG6zwgAQYzoCAADlP0IAACGDQgAA3/QCAAADJ4IAABaWAgAAGk/CAABKjgIAACNIggALgFpCAACkTgIAA1dqAgABiQ4A= Date: Thu, 21 Mar 2019 15:03:58 +0000 Message-ID: References: <20190318123634.6e90c043@cakuba.netronome.com> <20190318125935.580c8fbe@cakuba.netronome.com> <20190318142949.36f18af4@cakuba.netronome.com> <20190320132257.372369d7@cakuba.netronome.com> <20190321090821.GB2087@nanopsycho> In-Reply-To: <20190321090821.GB2087@nanopsycho> 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: ffa34e7c-91ce-4f8e-e95c-08d6ae0e7271 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:VI1PR0501MB2237; x-ms-traffictypediagnostic: VI1PR0501MB2237: x-microsoft-antispam-prvs: x-forefront-prvs: 0983EAD6B2 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(366004)(396003)(346002)(376002)(136003)(39860400002)(189003)(199004)(13464003)(305945005)(81156014)(9686003)(478600001)(86362001)(25786009)(93886005)(55016002)(7696005)(4326008)(105586002)(106356001)(99286004)(68736007)(14454004)(81166006)(53936002)(229853002)(7736002)(74316002)(66066001)(8676002)(8936002)(6436002)(97736004)(316002)(26005)(6246003)(3846002)(52536014)(446003)(102836004)(476003)(6506007)(53546011)(6116002)(11346002)(33656002)(71200400001)(5660300002)(110136005)(71190400001)(54906003)(76176011)(2906002)(186003)(5024004)(256004)(486006);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0501MB2237;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: q3b6twyxKZT/vcXLFFIfEmVvji3Vgcngy3TTo9qwoq5lvG1wDNF59XaLzdm8GvjfMdrFn/zGh7k4IAELsvunmlZPxZBvLLydCGb1sW6L7JRipmv/WJLHiP9tWOOh+dPF38KyPW0iaBb2AJTRXCWOva09LR7jfS2HaRbnItMimL5JEroArKBjhqeAj0pqzvaxDTNWSLu74i1Toh6AdtIcqeaNuoH4Mm3fe2Sbx/Gst81N9YLIQW1qs32U+WxtDkQtwRLQSOO/qpry3U4MWlQTYfZYAmcA5dNspaS6I7hVXNkaMhv/oMHMkIfjZgIE24d21xgxO1i/Qn47u1UCifgZr25hqGQKcuSEtOBdXqmhIo4FAxNL4UVoTtcLWKJAucIiLHsSPZsYYxYh6C/Zq9GcL1WHzdBnuutFs5+H8eNBIJM= 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: ffa34e7c-91ce-4f8e-e95c-08d6ae0e7271 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2019 15:03:59.0515 (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: VI1PR0501MB2237 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi Jiri, > -----Original Message----- > From: Jiri Pirko > Sent: Thursday, March 21, 2019 4:08 AM > To: Jakub Kicinski > 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 > Wed, Mar 20, 2019 at 09:22:57PM CET, jakub.kicinski@netronome.com > wrote: > >On Wed, 20 Mar 2019 18:24:15 +0000, Parav Pandit wrote: > >> Hi Jiri, Jakub, Samudrala Sridhar, > >> > > > > > And physical port in include/uapi/linux/devlink.h also > >> > > > > > describe that. > >> > > > > > >> > > > > By "that" you must mean that the physical is a user facing por= t. > >> > > > > >> > > > Can you please describe the difference between 'PF port' and > >> > > > 'physical port of include/uapi/linux/devlink.h'? I must have > >> > > > missed this crisp definition in discussion between you and > >> > > > Jiri. I am in meantime checking the thread. > >> > > > >> > > Perhaps start with the cover letter which includes an ASCII drawin= g? > >> > > > >> > > Using Mellanox nomenclature - PF port is a "representor" for the > >> > > PF which may be on another Host (SmartNIC or multihost). It's > >> > > pretty much the same thing as a VF port/"representor". > >> > > > >> > Yes. We are aligned here. :-) > >> > I see your point, where in multi-host scenario, a physical port may > >> > be 1, but PF ports are 4, because of 4 PFs for 4 hosts. > >> > (just an example of 4 hosts with their own mac address sharing 1 > >> > physical port). > >> > > >> > When there is no multihost and one to one mapping between a PF and > >> > physical links, there is some overlap between PF port and physical > >> > port attributes. > >> > I believe, such overlap is fine as long as we have unique indices fo= r the > ports. > >> > > >> > So I am ok to have flavours as physical/cpu/dsa/pf/vf/mdev/switchpor= t. > >> > (last 4 as new port flavours). > >> > > >> > > Physical port is the hole on the panel of the adapter where cable > goes. > >> > >> So my take away from above discussion are: > >> 1. Following new port flavours should be added > pci_pf/pci_vf/mdev/switchport. > >> a. Switchport indicates port on the eswitch. Normally this port has re= p- > netdev attached to it. > > > >I don't understand the "switchport". Surely physical ports are also > >attached to the eswitch? And one of the main purpose of adding the > >pci_pf/pci_vf flavours was to generate phys_port_name for the port > >netdevs. > > > >Please don't use the term representor if possible. Representor for > >most developers describes the way the netdev is implemented in the > >driver, so for Mellanox and Netronome different ports will be > >representors and non-representors. That's why I prefer port netdev > >(attached to eswitch, has switch_id) and host netdev (PF/VF netdev, > >vNIC, VSI, etc). > > > >> b. host side port flavours are pci_pf/pci_vf/mdev which may be > >> connected to switchport > > > >See above, pci_pf/pci_vf are needed for phys_port_name generation. >=20 > Yep, that makes sense. >=20 >=20 > > > >> 2. host side port flavours are not limited to Ethernet, as it is for d= evlink's > port instance. > >> > >> 3. Each port is continue to be accessed using unique port index. > >> > >> 4. host side ports and switchport are control objects. > >> a. switch side ports reside where current eswitch object of devlink > >> instance reside b. for a given VF/PF/mdev such host side ports may be > >> in hypervisor or VM or both depending on the privilege > >> > >> 5. eth.mac_address, rdma.port_guid can be programmed at host port > >> flavours by extending as $ devlink port param set... > >> (similar to devlink dev param set) > > > >You can keep restating that's your position, but I have *not* conceded > >to that. >=20 > I'm also not convinced that host dummy ports are good idea to hold these. >=20 >=20 I didn't understand what do you mean my dummy port. Can you explain what is wrong in programming host port params using host_po= rt object? Few questions are unanswered in my past 2 or 3 emails. Can you please go through them? Can you point to some example switch API where you program host params at s= witch? > > > >> 6. more host port params can be added in future when user need arise > >> > >> 7. rep-netdev continue to be eswitch (switchport) representor at the > switch side. > >> a. Hence rep-netdev cannot be used for programming host port's > parameters. > >> > >> 8. eswitch devlink instance knows when VF/PF/mdev's switchport are > created/removed. > >> Hence, those will be created/deleted by eswitch. > >> Similarly for host port flavours too. > >> > >> Does it look fine? Did I miss something? > >> We would like to progress on incremental patches for item-4 and any > >> prep work needed to reach to item-4.