From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B83E742D8E; Thu, 29 Jun 2023 19:05:37 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8B70D40EDB; Thu, 29 Jun 2023 19:05:37 +0200 (CEST) Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by mails.dpdk.org (Postfix) with ESMTP id C1F9A406B7 for <dev@dpdk.org>; Thu, 29 Jun 2023 19:05:35 +0200 (CEST) Received: by mail-pf1-f171.google.com with SMTP id d2e1a72fcca58-66767d628e2so838276b3a.2 for <dev@dpdk.org>; Thu, 29 Jun 2023 10:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1688058335; x=1690650335; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=Lp6GAr3UfRsJDRjRv30EkIgSvI4Jcd1BXNQ93zBB8S8=; b=GkLzcTi7yU6N3mgDn594TL2JEqouuhyk1zDiASd1GVXCBqXzbt+b19R8Khd/4xIAYi FWA7u9HiWocgcUwBi3Z0XqLXwXhDmVsf2ppQFYoYF8NJf4KQVjgPfe2voU9q0/Xg+iMu V9v4G7T0dCBTROo0tTuDnM07XPbcrHEXekjXwEWS0klxwgbNe2Te0MY8p7sLo3ElcmW2 DGUCXo1Vi5EyQcOCKDPBgOdUq/J0acFeal8ZYkw6DwFXBaLwkgwsjEOzA2S1uY0h33No FQfnr7uzLhrwLV9T32APAnfuXYrE0cR8PZe9MdA3FSoNeK4MmLwCko7S6FJSMs0X6F7M pnwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688058335; x=1690650335; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Lp6GAr3UfRsJDRjRv30EkIgSvI4Jcd1BXNQ93zBB8S8=; b=ElGCV3iIR15ibHEE9Fpg3ugCOhAuNqZe+3cm0qAstRqcdP87oRi4YR2tGRgiUbSavy EzIONYNxiiMLHzBOwX8AsprTAoSVUaJ97fYDi7NEYG8TURm+YnnWPC2LXAXlayRpTdwC G2TAhv8DJUwr1ov8IsfQDib4nyj/Z7fntONXnBvv/HfPHW6ONR6VqH2WGV18j2c9Y+8T IylL5omBm1b8BQcLaD6bY0Edlx9vSRkmNHMJZMjmtuI20O2HgvAUPNKGKDvy2P8jv3vE JfDquhJFIqi7sUo4f/jSc632kpwd3BGmPy2lha+QKgZkItqMcJ7MffiU2EqF8eVYQ8rd PIiA== X-Gm-Message-State: ABy/qLZjrqL8KA6I29As8A2LEhKTZL/p4LKLid6OXa7tZ6XqcW1fuaDl pDwa5zYY/npTrjHlkRvv1f0c9w== X-Google-Smtp-Source: APBJJlHgUPZ+Myc96rcjjmkWfg+JEJAgMrUcQxu4qRQgOQfOLWws0e3OqMq1CnKYUAmfrE3fNaokVw== X-Received: by 2002:a05:6a00:2389:b0:66c:2d4e:4772 with SMTP id f9-20020a056a00238900b0066c2d4e4772mr619255pfc.13.1688058334924; Thu, 29 Jun 2023 10:05:34 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id q17-20020a62e111000000b006736bce8581sm7540171pfh.16.2023.06.29.10.05.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Jun 2023 10:05:34 -0700 (PDT) Date: Thu, 29 Jun 2023 10:05:33 -0700 From: Stephen Hemminger <stephen@networkplumber.org> To: Igor Ryzhov <iryzhov@nfware.com> Cc: dev@dpdk.org, ferruh.yigit@intel.com, Dan Gora <dg@adax.com> Subject: Re: [dpdk-dev] [PATCH v6 1/3] kni: rework rte_kni_update_link using ioctl Message-ID: <20230629100533.5f574a6a@hermes.local> In-Reply-To: <20210830142731.32524-1-iryzhov@nfware.com> References: <20210826151911.15699-1-iryzhov@nfware.com> <20210830142731.32524-1-iryzhov@nfware.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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org On Mon, 30 Aug 2021 17:27:29 +0300 Igor Ryzhov <iryzhov@nfware.com> wrote: > Current implementation doesn't allow us to update KNI carrier if the > interface is not yet UP in kernel. It means that we can't use it in the > same thread which is processing rte_kni_ops.config_network_if, which is > very convenient, because it allows us to have correct carrier status > of the interface right after we enabled it and we don't have to use any > additional thread to track link status. > > Propagating speed/duplex/autoneg to the kernel module also allows us to > implement ethtool_ops.get_link_ksettings callback. > > Suggested-by: Dan Gora <dg@adax.com> > Signed-off-by: Igor Ryzhov <iryzhov@nfware.com> Marking this patch as rejected because KNI is marked as deprecated and this goes into the "won't fix" category. The link handling in KNI was always a botch. It violated the kernel locking (see calling usermode helper with RTNL held); and was fundamentally flawed. That was one of the reasons KNI never made it upstream and was marked deprecated.