From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10042.outbound.protection.outlook.com [40.107.1.42]) by dpdk.org (Postfix) with ESMTP id EE61E201 for ; Sun, 10 Mar 2019 09:59:40 +0100 (CET) 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=23GEejO5lIwppDT7fRtMQkaFGogIS6/RVA8id0+jShU=; b=eH7rxAL5sYCCGbSRlW6PCp3jgul0ECfRukfNr4qwaMsZ8PM10+45To08tA/wpV64ka7P4gTXTGFnU0dSfmdnRWEuKqS65oDfTLcG8ZRMq4S4WVmvFuJHyR8bY+erROzgA83KtEFVufPxW5NpeooSip3V+1c6p3sZmSuJq+Dkdpk= Received: from AM0PR0502MB3795.eurprd05.prod.outlook.com (52.133.45.150) by AM0PR0502MB3761.eurprd05.prod.outlook.com (52.133.50.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.17; Sun, 10 Mar 2019 08:59:38 +0000 Received: from AM0PR0502MB3795.eurprd05.prod.outlook.com ([fe80::84f3:7e92:7a51:1003]) by AM0PR0502MB3795.eurprd05.prod.outlook.com ([fe80::84f3:7e92:7a51:1003%2]) with mapi id 15.20.1686.021; Sun, 10 Mar 2019 08:59:38 +0000 From: Shahaf Shuler To: Slava Ovsiienko CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v2 1/1] net/mlx5: add representor recognition on kernels 5.x Thread-Index: AQHUzPl+k9g2FcwRnkKzE1JGgDSo66X/3CaggAA3IACABIpxwA== Date: Sun, 10 Mar 2019 08:59:38 +0000 Message-ID: References: <1550738519-4251-1-git-send-email-viacheslavo@mellanox.com> <1551092489-12247-1-git-send-email-viacheslavo@mellanox.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=shahafs@mellanox.com; x-originating-ip: [31.154.10.105] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c2b511c-2e32-468c-afd9-08d6a536ba24 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM0PR0502MB3761; x-ms-traffictypediagnostic: AM0PR0502MB3761: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; AM0PR0502MB3761; 23:33eqtdVGRCZif8P1/8HYaYOLyanlWS+Q34W89ka?= =?us-ascii?Q?WM8NSUWjsKrmgOmfJQrKK4Q/om5YzClFzwhqmCDUxSxZU/OYLb04IWnrX1XB?= =?us-ascii?Q?oCou7m5Im9v78gIscUQ5deZ2xM5l4MdGjNYJMc//9inU4Taa/ZooW3Oof8gC?= =?us-ascii?Q?8vokq0TBN052hdoRwu0/fufXz//SypcjOPS+nEnVZ297c1KV0yoluL7ZyWN2?= =?us-ascii?Q?Qet135nU0KtzPddYsY9g736FDOz+TQg7UBBpG7e+zQvd/y4GfKF/wgGwRq+s?= =?us-ascii?Q?WG9+40k1ZKvUEVRtI9PgZIwpJu/wJ6ju1HWm2O6mJ+45tNtuSNT9ix5BlNOY?= =?us-ascii?Q?zBRhc9hPdN4mEv/W2G29RH8xKhEf+JyUJMKUFSyPHGhdTut+4yH/JPJWQMi0?= =?us-ascii?Q?276iBMXvLb4iWs//YdhF4qANrj/6OLO9mx/FgLi19lSMby4ruya5OUsQAkMz?= =?us-ascii?Q?X7LgWPJ4/l85lgQosK4vLa/AB781vWbG6KIbghLXpAjGjgblal92+1fJdnyj?= =?us-ascii?Q?KMABtN4Ui7gu7V6aJSbQHu9AEbp6ETbukfGygvhdKi3m7mX4ah3UvUrHBrlr?= =?us-ascii?Q?okblCBm8ln9a1ggl3FlpwyBsXCnXgXO8PoA9rpcJKlEb2ax5ACmyPeVW7+3s?= =?us-ascii?Q?trgrN+m/GKaGHOeIHopS/tIUKzmcjNGKLekQTrmZHdfllw0GMWw7SBej1Oj/?= =?us-ascii?Q?3IMNvD3EW2RYGutjcYlUs9CQYdnKEIPgSmsMm50lXlYdvXVJZNaJWNbhFjfc?= =?us-ascii?Q?TVbI61BZeSax5PB1Z9hysKJCuBPMRYMkkOqrSytwlnBVlAod7p+62x2ZoskT?= =?us-ascii?Q?UPFwy2xwT1JY1E99SanwIeXx72IsUaB5jpbeuaJ0UIUGpDb9N7XKCftdP53J?= =?us-ascii?Q?w0R8WFMiuAXOxkEv567lfdyj4ULV2POLhY6p6AqKJ5OQRYhwTQkDdXP46B24?= =?us-ascii?Q?cCeouZPjulbLa0NBIXKOOFGHScQoeRtdDDI7pz2iYiM5DXcvx5QOyam70Y9C?= =?us-ascii?Q?oKYE7AUme5BFR2bHdK4Mr7elF18jIxvgQx2rSmBtF2W2GAYoprxSI7qlVkIk?= =?us-ascii?Q?Zr/pw3RqFwO7e2qp8V0kme6FBdsnlDypbpyu+g1YBHjU3RGw9iGqnbE+nvKG?= =?us-ascii?Q?fzan6V9o4tGzAB6Veo0sk978Uw1/EouAwy3tSMKDH/iYtBt8Bqbx3z3q6RoH?= =?us-ascii?Q?YHFXR/dhiUJhbv+ez6KKU/VgzPTCNET7TqJspBCaTCxnj3g1nGHUB1jaACBy?= =?us-ascii?Q?1PH9byqd3qVNbRzqmZNlH47FrtvPy4arM0xxDRy7c?= x-microsoft-antispam-prvs: x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(366004)(136003)(396003)(346002)(376002)(199004)(189003)(486006)(446003)(11346002)(478600001)(476003)(26005)(71190400001)(71200400001)(186003)(97736004)(7696005)(6636002)(316002)(33656002)(52536013)(93886005)(3846002)(6862004)(6246003)(102836004)(6116002)(4326008)(25786009)(66066001)(5660300002)(966005)(2906002)(68736007)(14444005)(86362001)(53936002)(105586002)(55016002)(6306002)(14454004)(106356001)(256004)(6436002)(9686003)(74316002)(305945005)(7736002)(6506007)(99286004)(76176011)(8936002)(81156014)(81166006)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR0502MB3761; H:AM0PR0502MB3795.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: dA2UYyk/7rJp/b5+plNlW/V4NXyUySNgfJS9T1f1vLBKHRnNkrRShYZtKFUTlN1il6NnRwvSpSHapC72sFRmb+kXbW6BsZ1ko0pwVMTpiAfmb3M0K3gdHvcdqvucTZl5NGMZepq2cdcpLGb2fSHsJN4EClGvXb4EZF/xaPJZG8PsNw488zTeyHyJhE7ewshVZ0su1ELC6nWmtuSiPlrBUDnjN7hO+/nH6dllOPp+FuPCNDa7e9JVYK5t7db1rWFb7iyfFHa7vclujmTKSpf93loJxetwJDykEGRwQ6Gm/MdWcmoncKiRLYjRMGAx5GA8gB+LcihlHQNHTcemRGf6ar+zTh0kOXYm83z7GFDcuQbh3nwzb3gwtpaA3iy1EODDad1NmMJxmpyd5v/bR2uUN/Jw4xW2Dc3JENpavisGs/I= 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: 5c2b511c-2e32-468c-afd9-08d6a536ba24 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2019 08:59:38.7215 (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: AM0PR0502MB3761 Subject: Re: [dpdk-dev] [PATCH v2 1/1] net/mlx5: add representor recognition on kernels 5.x X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 08:59:41 -0000 Thursday, March 7, 2019 1:12 PM, Slava Ovsiienko: > Subject: RE: [dpdk-dev] [PATCH v2 1/1] net/mlx5: add representor > recognition on kernels 5.x > > Monday, February 25, 2019 1:01 PM, Viacheslav Ovsiienko: > > > Subject: [dpdk-dev] [PATCH v2 1/1] net/mlx5: add representor > > > recognition on kernels 5.x > > > > > > The master device and VF representors were distinguished by presence > > > of port name, master device did not have one. The new Linux kernels > > > starting from 5.0 provide the port name for master device and the > > > implemented representor recognizing method does not work. > > > The new recognizing method is based on quiering the VF number, > > > created on the base of the device. > > > > > > The IFLA_NUM_VF attribute is returned by kernel if IFLA_EXT_MASK > > > attribute is specified in the Netlink request message. > > > > > > Also the presence of device symlink in device sysfs folder is added > > > to distinguish representors with sysfs based method. > > > > w/ kernel 5.x, there is also a new naming scheme for representor, right= ? > > Wouldn't it be simpler to use it in order to decide uplink/regular > > representor? >=20 > There should not be any assumption regarding port index, we can't say for > sure on which port index we have uplink representor. It is possible to > compare the port name against -1, but it is quite possible situation (old > kernels with new drivers, I had been working with such setup for a while)= in > that have the multiport Infiniband device and old naming and we are unabl= e > recognize the Uplink rep by port name. OK understood. Out of curiosity which kernel was that? =20 I think the safest way to detect the uplink representor is by matching on i= ts port index. This is well defined on the PRM: "Because each PF has just o= ne Uplink, it should access it only by vport_num =3D 0xffff." For this purpose matching according to the representor phys_port_name is th= e most straight forward. We should have a fallback for special cases (like you mentioned), and it wi= ll use the IFLA_NUM_VFS indication.=20 Meaning your patch needs to be on top of https://patches.dpdk.org/patch/507= 71/ and provide a fallback detection approach in case the detection by name= is not supported.=20 >=20 > So, it seems to me, the querying numVF/sysfs method is more reliable and > works for all settings I've tested. >=20 > > > > There is already patch for it from Dekel: > > https://patches.dpdk.org/patch/50771/ >=20 > Yes, It's included in RFC because patchset is not functional w/o Dekel's = patch. > The patchset will be rebased and Dekel's commit will be excluded in the n= ext > versions. >=20