From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B1D6AA0032; Fri, 22 Apr 2022 10:46:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A66F14067B; Fri, 22 Apr 2022 10:46:36 +0200 (CEST) Received: from mail-108-mta96.mxroute.com (mail-108-mta96.mxroute.com [136.175.108.96]) by mails.dpdk.org (Postfix) with ESMTP id 4D7FD40042 for ; Fri, 22 Apr 2022 10:46:35 +0200 (CEST) Received: from filter006.mxroute.com ([140.82.40.27] 140.82.40.27.vultrusercontent.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta96.mxroute.com (ZoneMTA) with ESMTPSA id 1805073864c000fe85.001 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 22 Apr 2022 08:46:29 +0000 X-Zone-Loop: 23daf006f8a098c34b013941cd13aceac29069e376d3 X-Originating-IP: [140.82.40.27] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ashroe.eu; s=x; h=Content-Type:MIME-Version:Message-ID:Date:In-reply-to:Subject:Cc:To: From:References:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=nSYTupb3dcAZHtCLcOeIAb6toL/A9pRAU4kIwZzLXjs=; b=H26xA08gmowPmz3UdIVBnSeV2s 1L4+Cx5/bGPYJkofAcNgBzZyRPGAEctJZAg1jpy7aqSxWZUAZ0qxwlo0pObiBFjjao2cjFD3IQPcZ azmlXARuuoknkJPt316YB8orFtQtSjcn9d596a2R5oLRrHrkttoclGtFdo5speBioS1AQoG99Dwlq NXwJ5OVzxgECWFWzs0gBPzUbFcnNE8hRMXg8z8RZse+YPJqQLq5tO4A4QYO7VAouTZBvvq8JGySEI gJnCH/ituFgJY357LPsHV7IOZ4h9Y2zknLUGWPivx8XDTp2HvIq9WqFpL5TClhqimkLu2V3UA8n8a 4PHlCwTQ==; References: <20220421075444.6f872836@hermes.local> <87czhao373.fsf@mdr78.vserver.site> <20220421085058.60119998@hermes.local> User-agent: mu4e 1.4.15; emacs 27.1 From: Ray Kinsella To: Stephen Hemminger Cc: Stephen Coleman , dev@dpdk.org, Ferruh Yigit Subject: Re: kni: check abi version between kmod and lib In-reply-to: <20220421085058.60119998@hermes.local> Date: Fri, 22 Apr 2022 04:46:26 -0400 Message-ID: <87a6cdo68t.fsf@mdr78.vserver.site> MIME-Version: 1.0 Content-Type: text/plain X-AuthUser: mdr@ashroe.eu X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Stephen Hemminger writes: > On Thu, 21 Apr 2022 11:40:00 -0400 > Ray Kinsella wrote: > >> Stephen Hemminger writes: >> >> > On Thu, 21 Apr 2022 12:38:26 +0800 >> > Stephen Coleman wrote: >> > >> >> KNI ioctl functions copy data from userspace lib, and this interface >> >> of kmod is not compatible indeed. If the user use incompatible rte_kni.ko >> >> bad things happen: sometimes various fields contain garbage value, >> >> sometimes it cause a kmod soft lockup. >> >> >> >> Some common distros ship their own rte_kni.ko, so this is likely to >> >> happen. >> >> >> >> This patch add abi version checking between userland lib and kmod so >> >> that: >> >> >> >> * if kmod ioctl got a wrong abi magic, it refuse to go on >> >> * if userland lib, probed a wrong abi version via newly added ioctl, it >> >> also refuse to go on >> >> >> >> Bugzilla ID: 998 >> > >> > >> > Kernel API's are supposed to be 99% stable. >> > If this driver was playing by the upstream kernel rules this would not >> > have happened. >> >> Well look, it is out-of-tree and never likely to be in-tree, so those >> rules don't apply. Making sure the ABI doesn't change during the ABI >> stablity period, should be good enough? >> > > I think if KNI changes, it should just add more ioctl numbers and > be compatible, it is not that hard. True, fair point, I am unsure what that buys us though. My thinking was that we should be doing the minimal amount of work on KNI, and directing people to use upstream alternatives where possible. For me minimizing means DPDK ABI alignment. However I see your point, let KNI maintain it own ABI versioning independent of DPDK, with stricter kernel-like guarantees is probably not much more work. -- Regards, Ray K