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 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 C9AE7C43381 for ; Mon, 18 Mar 2019 22:12:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 88FF22171F for ; Mon, 18 Mar 2019 22:12:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=Mellanox.com header.i=@Mellanox.com header.b="ERUnvyqR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727545AbfCRWMf (ORCPT ); Mon, 18 Mar 2019 18:12:35 -0400 Received: from mail-eopbgr60048.outbound.protection.outlook.com ([40.107.6.48]:37959 "EHLO EUR04-DB3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726911AbfCRWMe (ORCPT ); Mon, 18 Mar 2019 18:12:34 -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=jf3mgrdyfm37xjPz0E9CkL2olhQJpjIFPzzfcbq9f3Y=; b=ERUnvyqRPxlDS4mpG7J6KkTOeCAV5AOgBiZZXhrcPxDv9Q1A358FwX2Nk+HWianefX/BAq+Ub593Uf3FYqspSgyjFESvtbTjIXD/j51NyfR0fL7IXWF3/u/74xzl0knJPcfG85ySZjfOnFP6SfZc9vTdCXjE5XUsfLkRmoJuPCE= Received: from VI1PR0501MB2271.eurprd05.prod.outlook.com (10.169.135.8) by VI1PR0501MB2480.eurprd05.prod.outlook.com (10.168.136.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13; Mon, 18 Mar 2019 22:11:50 +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.015; Mon, 18 Mar 2019 22:11:50 +0000 From: Parav Pandit To: Jakub Kicinski CC: Jiri Pirko , "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/CAABKjgIAACNIg Date: Mon, 18 Mar 2019 22:11:49 +0000 Message-ID: References: <20190314150945.031d1b08@cakuba.netronome.com> <4436da3d-4b99-f792-8e77-695d5958794d@intel.com> <20190315200814.GD2305@nanopsycho> <20190318122105.GH2270@nanopsycho> <20190318123634.6e90c043@cakuba.netronome.com> <20190318125935.580c8fbe@cakuba.netronome.com> <20190318142949.36f18af4@cakuba.netronome.com> In-Reply-To: <20190318142949.36f18af4@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: 00ed2a99-ed62-4b40-5b2f-08d6abeeb848 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:VI1PR0501MB2480; x-ms-traffictypediagnostic: VI1PR0501MB2480: x-microsoft-antispam-prvs: x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(136003)(376002)(39860400002)(346002)(396003)(366004)(13464003)(189003)(199004)(105586002)(7696005)(66066001)(6506007)(186003)(26005)(76176011)(97736004)(52536014)(4326008)(2906002)(99286004)(106356001)(53546011)(8936002)(102836004)(71190400001)(256004)(33656002)(71200400001)(6246003)(25786009)(53936002)(6436002)(478600001)(55016002)(68736007)(229853002)(93886005)(5660300002)(9686003)(74316002)(316002)(6916009)(8676002)(6116002)(7736002)(14454004)(86362001)(81156014)(81166006)(305945005)(486006)(3846002)(11346002)(446003)(476003)(54906003);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0501MB2480;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: U+LOtzOyMSKXiKO31ZM8LgxjYjnA28snonoL2iUBbcGJW7RuqwS2nKi+tIrd5Uhe3pnuXTRHSeu153b0gtEwp8QMCAfzYsTjC0P3DFVW5V/+tFDKBXbnXgPRlmsOeN6UJh8u3O1xAcaDRRPp5CqfHLNmOxbWEFXnqYDsHai+TDv//1jC/bJIiiyvZ8liFwtD5orYi3lO+chfOFUWjTvGmZX1OdYCAZLNtAO1fQwf7VHJ9GhMaPCMYSdx43Gs8jXaQDRHwbBImQEgtUP39GL39Iezoqrkr6EJ8vT9RD63T3HL6PkRhKoqUDGoDeX7jaUiNurq92fdawyT6YNx75dojPrTFasQZPqqA8n4WfwJxJPs1N3CWLNb24WnBqIv9zixNeOLEW+rFAdaB0R4AJZ+9dNrddMo5L1WBE8OPDww3bI= 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: 00ed2a99-ed62-4b40-5b2f-08d6abeeb848 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2019 22:11:49.9858 (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: VI1PR0501MB2480 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > -----Original Message----- > From: Jakub Kicinski > Sent: Monday, March 18, 2019 4:30 PM > To: Parav Pandit > Cc: Jiri Pirko ; 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 Mon, 18 Mar 2019 20:35:02 +0000, Parav Pandit wrote: > > > > > > physical and pf has some overlapping definitions. > > > > > > > > > > What "overlapping definitions" do physical and PF have? > > > > PF has physically user facing port. > > > > > > PF doesn't "have a user facing port" in switchdev mode. > > > > Physical port described in include/uapi/linux/devlink.h as > > DEVLINK_PORT_FLAVOUR_PHYSICAL is not related to switchdev or legacy > > mode. >=20 > I said "PF doesn't ...", you're now talking about physical? >=20 > > As the comment block describe it is 'any kind of port physical facing > > user'. >=20 > Are you saying PCI function is physical? Just because PF stands for Phys= ical > Function? >=20 > Physical port in devlink means a port in the front panel where networking > cable goes. >=20 > > Current mlx5 driver doesn't expose ports as physical regardless of > > switchdev/legacy mode. >=20 > Today mlx5 doesn't expose devlink ports at all. >=20 > > > It's a limitation of Mellanox HW that you have some strong > > > association there. > > Not sure why you keep saying that. Any code reference that I should > > look at? Or maybe you can explain what is that limitation, because I > > am not aware of any. >=20 > NIC designs originating from traditional NICs were build as pipelines fro= m PCI > to wire or from wire to PCI. Reportedly it makes it hard to completely > divorce the PCI PF from the wire port (physical port). >=20 > Which is why you may think that "PF has physically user facing port". >=20 > > > > And physical port in include/uapi/linux/devlink.h also describe > > > > that. > > > > > > By "that" you must mean that the physical is a user facing port. > > > > 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. >=20 > Perhaps start with the cover letter which includes an ASCII drawing? >=20 > 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 sam= e > thing as a VF port/"representor". >=20 Yes. We are aligned here. :-) I see your point, where in multi-host scenario, a physical port may be 1, b= ut 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 p= ort). When there is no multihost and one to one mapping between a PF and physical= links,=20 there is some overlap between PF port and physical port attributes. I believe, such overlap is fine as long as we have unique indices for the p= orts. So I am ok to have flavours as physical/cpu/dsa/pf/vf/mdev/switchport. (last 4 as new port flavours). > Physical port is the hole on the panel of the adapter where cable goes.