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 663D0A0093; Fri, 22 Apr 2022 12:07:45 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 458934067B; Fri, 22 Apr 2022 12:07:45 +0200 (CEST) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) by mails.dpdk.org (Postfix) with ESMTP id 2F7B240042 for ; Fri, 22 Apr 2022 12:07:44 +0200 (CEST) Received: by mail-io1-f54.google.com with SMTP id n134so8077850iod.5 for ; Fri, 22 Apr 2022 03:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O8nkFGTLIwlJfmRWNu3h0X5G8zw39TgqRMk8b6Egxuo=; b=ExooUqPBz++2W5tU8D1tZ/MimUg61jOkfPzRF4QXjEZGLOX+e4KMwzggf/pLwy5N+m lcax2iq8jMi0FjPDhiiTBz0Lkd99CncVXSPpXAAWgAoNp+rnox2LDh6K9ZE+XaM9eW9O B2gwfhYRX9BodvJ8XOp3Ywmvkbq0k9n/stkK29+rzEmmaddY494NTQPzQrgaNCKUCFz+ kC/xm5NG1lauxu/Ex3TUK5K1OX3ZJxq9O8gdLPoLiNGxowe/wWdCDUvopfGjLMcED3oh XSLbn+qUwMPdSPjrC1/aFK2RRjWIjyKxESUvoMUx6uJlCA4OLs6/HajT80O8Cdx6u5sE 0i+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O8nkFGTLIwlJfmRWNu3h0X5G8zw39TgqRMk8b6Egxuo=; b=xz8ewAYjdSGouuhu7LzkgO31+mo92CLYfKeUzlnkrDTdwK1BKHtKanKg4TxwojQ8qK 7cWDytVdpBiJXbMN4BBrWEo7pSJ6qFmLP39mfjZ4eaP6jamH40OHn4acNOzFGvJh6ilR MRs4IdQT6xLIYS/bjwMC+KDwk7POSb/zNi93Eqp1Uoqk9U+YhuQL+ccBoy5RjNGlH0wA xPOkwoiDxhin2nX2Bb8e/FfXLwcpZqJz/yhK8gvPKKNmgW0ysWLSS+o7H6nEoV+8APa6 dYmIEg4mEWDOk8qRrQzxo1AHX5ht5LiYwh1z2vRsyOjLAKQxtchx899gNiwVCQ1W1N3F Sr7w== X-Gm-Message-State: AOAM532ueliSPwyzfo2DOeUS2NWPllAG9fmDqpm0CX0Or1xnAql54ky/ 60GFtj+Tv/mFdazUMjUI5y5XPk1uxRfvHesk2CQ= X-Google-Smtp-Source: ABdhPJyBzeq4nO8IvVyLfUEsR1ypvtBuLoHitIv36nRveNO4Va41Us5shiJa3R2dv0Ybagp+nwQtPepGARQ8YwDk6yw= X-Received: by 2002:a6b:c9d4:0:b0:652:e5e8:4365 with SMTP id z203-20020a6bc9d4000000b00652e5e84365mr1613432iof.215.1650622063612; Fri, 22 Apr 2022 03:07:43 -0700 (PDT) MIME-Version: 1.0 References: <20220421075444.6f872836@hermes.local> <87czhao373.fsf@mdr78.vserver.site> <20220421085058.60119998@hermes.local> <87a6cdo68t.fsf@mdr78.vserver.site> In-Reply-To: <87a6cdo68t.fsf@mdr78.vserver.site> From: Stephen Coleman Date: Fri, 22 Apr 2022 18:07:32 +0800 Message-ID: Subject: Re: kni: check abi version between kmod and lib To: Ray Kinsella Cc: Stephen Hemminger , dev@dpdk.org, Ferruh Yigit Content-Type: text/plain; charset="UTF-8" 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 thanks for your replies I'm aware that kernel guidelines propose ascending ioctl numbers to max out compatibility, but this will not work with dpdk, especially our case here. If you look into kni_net.c you'll see the module is actually internally depending on the memory layout of mbuf and a few other structs, you will need to change ioctl numbers if those change, and that's very implicit and requires extra effort. Plus the compatibility is almost impossible to maintain across dpdk releases, as the module won't know which version of mbuf layout it is working with. In short, rte_kni.ko is part of dpdk rather than part of kernel, and different parts of different dpdk releases do not work together -- so we reject them early in the first before it make a disaster. p.s. working on v3 to fix code format issues p.p.s. forgot to 'reply all' last time, sorry for the duplication > > > 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