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 AEDA0A054F; Thu, 9 Jun 2022 04:30:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4B3B440689; Thu, 9 Jun 2022 04:30:58 +0200 (CEST) Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by mails.dpdk.org (Postfix) with ESMTP id 1887B40220 for ; Thu, 9 Jun 2022 04:30:57 +0200 (CEST) Received: by mail-pf1-f178.google.com with SMTP id p8so19893100pfh.8 for ; Wed, 08 Jun 2022 19:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=SbQc6WB8wxowZhHHdFMqc2fR/EaLHkGOuAMcmyg/M7A=; b=0+6FdbiS6+HGK5TelWg45jOW/Mv2eVoKQxqoctPA12+JQ0j0zTzdPnyn4O4tfSLWgv KYQCrG8BWnvcpaOoz2mihmB4yDb/3ki/PyXflbTisrffv058Phy+MbJ4zbPCgFZnnJyX mnEVrMDmpG4T9xMTM7qd9x0MSSqfiu9b3TKwDMnCMUscEOSbC/2cMmLYEIayt4jaVkFw H+9G9mxBHjO6bayC55puEvxb1qgZkdAsrPuGiaOax5J+cJsI36U0HEgslfIi1towqGKm 95eZx4/DOeYIX6V0zRkCn/18eQh6IkV3IFD/oakeM39zz3ECcUWC1Nvhrzd+RiopOOlU beWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=SbQc6WB8wxowZhHHdFMqc2fR/EaLHkGOuAMcmyg/M7A=; b=lc7qi/YqtVa3Dm21p8S4/XL4/S2wPqe1Els8TAXIpuXg/7JkKilFe6f9TCWJ2ceNQB FTmpfNiZz0BDXkNC/8uMTXOQaA2DmxgV2Nab3iu4dQbQtQTBFf3B07b62jeKwZJoxNR9 4ZtnxQDl0L1qsnwsbT+K+5uxTE4F7u7Q+uL+DTEzk/mSIGRpM+EAoRH4V23pzFCPV7IO iXLMus4nkx3vDlUQZRFW1bceD/wXkrZz1okDHfkKUM0McCq5GT6VY91n2vVBopdww8nf z+l8+Qg/4tWRSKrHCkIdKLNPhNBoRKD8qFANs5UH0Pfx6ELSMkiCF7FUa/aQIfQW0Can P//A== X-Gm-Message-State: AOAM530X0bzRbI7NbJvywNtapTXOeFtDgK1QVKlV9fOtoGY1NxJ0JmzG 30P1/R+xE6JCKuTHcK4h3v5rAA== X-Google-Smtp-Source: ABdhPJxBM+Q1VV4hdwFUVfyr/W9ZNMBJ6UtyDLqq1Heus2WX7SExh9iXCc0zCvRyISCDT+5N+/wHgw== X-Received: by 2002:a65:6bcc:0:b0:3f6:1815:f541 with SMTP id e12-20020a656bcc000000b003f61815f541mr31637716pgw.183.1654741856258; Wed, 08 Jun 2022 19:30:56 -0700 (PDT) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id 19-20020a170902e9d300b0015e8d4eb1b6sm15454252plk.0.2022.06.08.19.30.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jun 2022 19:30:55 -0700 (PDT) Date: Wed, 8 Jun 2022 19:30:50 -0700 From: Stephen Hemminger To: fengchengwen Cc: Olivier Matz , , Thomas Monjalon , Ferruh Yigit , "lihuisong@huawei.com" Subject: Re: Minutes of Technical Board Meeting, 2022-06-01 Message-ID: <20220608193050.589a5701@hermes.local> In-Reply-To: <15e07c9f-e1ba-a789-0ef3-c8d8e1d820c0@huawei.com> References: <3be02bac-9f7c-6e8d-e32c-95634ad2a248@huawei.com> <20220608183127.45aa5228@hermes.local> <15e07c9f-e1ba-a789-0ef3-c8d8e1d820c0@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Thu, 9 Jun 2022 10:07:28 +0800 fengchengwen wrote: > 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. What is wrong with TAP or virtio user for your application? KNI already is a security risk, it implicitly trusts userspace. > > > > >> > >> 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 ? The fact that KNI calls user mode holding the RTNL mutex is only one of many places where KNI trusts user space. > > 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 ? Virtio user has been used as a better alternative. Bruce has recently taken on providing more documentation to make the transistion easier. One other option is you are free to take KNI on as a project that is maintained in parallel with DPDK (like TREX and some other packages).