From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0079.outbound.protection.outlook.com [104.47.2.79]) by dpdk.org (Postfix) with ESMTP id 79F7ADE3 for ; Sun, 25 Jun 2017 08:03:59 +0200 (CEST) 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; bh=N+S7oZa3COxgsTkqcLrGEFAT4i2NKY5wNfJyThbQkeU=; b=Hn73ATWDocVrONtyea+op9NFK2atq77osmqOZd4viZBPyrekEB1DwXrlk0XqcLX6IIFrgERKWA4YEzJMm2nUNDL7AGKOYNk3cvD4cuACEj7GXcupMsvrX7CXttB0iOUaQkoj2T3sPe7o7XpkJcfStXk1gYLTggOUlmHgqYWrcDo= Received: from VI1PR05MB3149.eurprd05.prod.outlook.com (10.170.237.142) by VI1PR05MB3150.eurprd05.prod.outlook.com (10.170.237.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.15; Sun, 25 Jun 2017 06:03:56 +0000 Received: from VI1PR05MB3149.eurprd05.prod.outlook.com ([fe80::fd44:5fc9:6e67:a313]) by VI1PR05MB3149.eurprd05.prod.outlook.com ([fe80::fd44:5fc9:6e67:a313%13]) with mapi id 15.01.1199.017; Sun, 25 Jun 2017 06:03:56 +0000 From: Shahaf Shuler To: Hemant Agrawal , Stephen Hemminger , Pascal Mazon CC: "dev@dpdk.org" Thread-Topic: DPDK drivers should not use kernel version Thread-Index: AQHS6qt5zrQ7os9fO02T6j3ATy+QgqIyEMyAgAMICVA= Date: Sun, 25 Jun 2017 06:03:56 +0000 Message-ID: References: <20170621092843.72606c72@xeon-e3> <4376741f-cece-8086-eddb-c35ee9ef06a4@nxp.com> In-Reply-To: <4376741f-cece-8086-eddb-c35ee9ef06a4@nxp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=none action=none header.from=mellanox.com; x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR05MB3150; 7:NqtZ/LisZtWYOUQ9boFEBptFs0q+xIAtWhRN2IdLw+xnjQznRsjhOi0QzUmGOlRtQhHnKVsCidEszEG1ZxEN+cY60lcYcBtPgD/XMLtgoU4RJ+L8gC9EOgS3se7n2OcuzpyEeEyI/lCdi80Rk1ougDrzCvSvVC1IAWc33ZPbo7vKJ5bjHhiIULspuxsERB9wogecwbNnuPk0yOxVSfx2C5in7mPsafgTyYOqJHyAVcWoZFTaTIflQLCtob0Byy5MebhB/KzUxv6/1qA4UGwD0jKM3ycPn0UiZTI3uma/n+xMmVeXLbUAiHScbNo+/r/u404Bkyiyzbm4uCj/nOHWf1ac0bSQjXbmn4B+nvGxwziuJVn8Hkd+0ri3HWArTnesmrfHhMMl85n8lnCR54yDYpLp4ctkRSXYEyFfyFByiBedMZc6h5hHEJJkQfPuntjV4c9RSkJIr+RRtXT4MI02M5ac/Rl586U3vs3AiwafJsBogioCnDGrbXxvQrPvkYZRD8n3zZtq9WTmjJYviOiAsVz7/D98X08IjOCxeM52RWul4tPUS66llE1neCBu7vpjB+ZAYXNpB43gZyD+ls1BDOoTJy+KE/kN1DqasU+CJYICcx2QMFg5X4PVGcO12WDXOH9pcAlN+iO0Q4ogx4GHsqFg9l47YZy0d4u3Qbp4x5Dtun5jH72PJNUKYHIUZb+6I1G8FiBCxUTO9reToOUg4jylNRJin/UZIDN0gWayXsaU17A0OCwoHNiwLHwnNRWkdQRzIm9QDlbubnKJmEBLBypmlQCdKxTpKxH5zcFKzbs= x-ms-office365-filtering-correlation-id: 0c4deb2c-0bc1-4369-1fed-08d4bb8ff736 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(48565401081)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506067)(300135500095); SRVR:VI1PR05MB3150; x-ms-traffictypediagnostic: VI1PR05MB3150: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR05MB3150; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR05MB3150; x-forefront-prvs: 034902F5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39860400002)(39410400002)(39400400002)(39850400002)(24454002)(377424004)(377454003)(3660700001)(8676002)(7736002)(189998001)(76176999)(66066001)(54356999)(3846002)(102836003)(6116002)(4326008)(50986999)(6506006)(14454004)(25786009)(2906002)(2900100001)(74316002)(81166006)(2950100002)(3280700002)(6246003)(55016002)(5250100002)(53546010)(33656002)(99286003)(53936002)(478600001)(38730400002)(9686003)(86362001)(8656002)(8936002)(305945005)(5660300001)(7696004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB3150; H:VI1PR05MB3149.eurprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2017 06:03:56.6217 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB3150 Subject: Re: [dpdk-dev] DPDK drivers should not use kernel version 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, 25 Jun 2017 06:03:59 -0000 Friday, June 23, 2017 10:34 AM, Hemant Agrawal: > On 6/21/2017 9:58 PM, Stephen Hemminger wrote: > > Looking at some other issues, I noticed that both the TAP and MLX5 > > device drivers are looking at kernel version through uname. Although > > this may seem like a good way to deal with kernel API changes, it is no= t > reliable. > > > > Enterprise kernel distro vendors never change kernel version but do > > backport features from later kernels. Therefore the behavior expected > > may change even though kernel version doesn't change. Also kernel > > version does not dictate that the expected feature (like flower) is in = the > kernel configuration. > > > > I recommend this be looked for in all future submissions. Maybe even > > flagged as error in DPDK version of checkpatch. >=20 > what is the alternative than? >=20 > There are many legitimate cases, where userspace code need to make > decision on the basis underlying kernel version. >=20 > In some cases, user space code can add error handling and fallback, but i= t is > not possible in all cases. +1 on Hemant question. Taking for example mlx5 code - Mlx5 uses the kernel for the control path, while the data path is in user s= pace.=20 In order to query the link status, it uses an ioctl. There are two differen= t APIs for that : GLINKSETTING and GSET. GSET was deprecated since kernel 4.5, and all the bugs in GLINKSETTING were= fixed only after 4.9. One could try to use the GSET API, and if fails use the GLINKSETTINGS. Howe= ver, for kernels in range of [4.5,4.9) the behavior will not be correct. On this specific example - backported kernel should maintain both APIs.=20 >=20 > > > > $ git blame drivers/net/mlx5/mlx5_ethdev.c | grep uname > > 3a49ffe38a950 (Shahaf Shuler 2017-02-09 14:29:54 +0200 = 895) > if (uname(&utsname) =3D=3D -1 || > > $ git blame drivers/net/tap/rte_eth_tap.c | grep uname > > de96fe68ae959 (Pascal Mazon 2017-03-23 09:33:57 +0100 1169) if > (uname(&utsname) =3D=3D -1 || > > > > >=20