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 5A924A054D; Thu, 9 Jun 2022 04:07:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 430EE40689; Thu, 9 Jun 2022 04:07:36 +0200 (CEST) Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by mails.dpdk.org (Postfix) with ESMTP id B11A540220 for ; Thu, 9 Jun 2022 04:07:34 +0200 (CEST) Received: from dggpeml500024.china.huawei.com (unknown [172.30.72.54]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4LJS9b3pW5z1KB7W; Thu, 9 Jun 2022 10:05:39 +0800 (CST) Received: from [127.0.0.1] (10.67.100.224) by dggpeml500024.china.huawei.com (7.185.36.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 9 Jun 2022 10:07:29 +0800 Subject: Re: Minutes of Technical Board Meeting, 2022-06-01 To: Stephen Hemminger CC: Olivier Matz , , Thomas Monjalon , Ferruh Yigit , "lihuisong@huawei.com" References: <3be02bac-9f7c-6e8d-e32c-95634ad2a248@huawei.com> <20220608183127.45aa5228@hermes.local> From: fengchengwen Message-ID: <15e07c9f-e1ba-a789-0ef3-c8d8e1d820c0@huawei.com> Date: Thu, 9 Jun 2022 10:07:28 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20220608183127.45aa5228@hermes.local> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.100.224] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpeml500024.china.huawei.com (7.185.36.10) X-CFilter-Loop: Reflected 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 On 2022/6/9 9:31, Stephen Hemminger wrote: > On Thu, 9 Jun 2022 08:41:35 +0800 > fengchengwen wrote: > >> [snip] >> >>> >>> 4) Removal of KNI >>> ----------------- >>> >>> There is no more maintainer for KNI. >>> >>> A progressive removal proposal was made: >>> - add a message at runtime and/or compilation to announce deprecation >>> - remove KNI example after 22.11 >>> - remove lib + kmod from main repo for 23.11 >> >> We still use KNI in some business scenarios, and we want to maintain it in this case. > > > Why? The KNI module can be used in following scenarios: when the PF is taken over by the DPDK, some traffic needs to be transmitted through the kernel protocol stack, we did have this application scenario. If do not proactively maintain the KNI, security risks may occur. and this's our starting point. > >> >> I recommend Huisong Li (lihuisong@huawei.com) as the new maintainer of the KNI. >> >> He has been involved in the community for several years and submitted some >> bugfix patches of KNI. > > KNI has several unfixable architectural issues. Could you show detail on this ? > It would never pass a full upstream kernel review. > > I hope you realize the security impacts of this. Is there another option to act like KNI role ? > > . >