From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id D2837A00B8; Sun, 27 Oct 2019 21:16:37 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9A55E1BF09; Sun, 27 Oct 2019 21:16:37 +0100 (CET) Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by dpdk.org (Postfix) with ESMTP id D10701BF01 for ; Sun, 27 Oct 2019 21:16:36 +0100 (CET) Received: by mail-wr1-f67.google.com with SMTP id w18so7752465wrt.3 for ; Sun, 27 Oct 2019 13:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nfware-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/epglAJkmZJeRkXv6q4caamkK8lCYIB3NIhIVYRg2kY=; b=wXHAS17Ww4789ZfaFyJ/ZEXtap7pNoa56F6NTC9PM1Jtr66T7yu27EVIqLFvp/AHPv FnhqsB/UhQL+bQTajvydi76esKr3vgCNPdXuzT60POnL3l/rEyuQKJgcr7BqjHBP2IoE +n0u+nYkOQ2c2W0eMqOk5wAodufe0hSdh1p5Isyjuw3J73BMIhCwHNChWV/JvvbwbNCQ X70lDxX7SzRijIJY6/fppnbNR53VWCI2dW0OQ8U3ndt5wZhbZbEwDYQ84zZjvan70iLY TpDTP04U7883eBrc9EmGtALA6PUuTwSn3GKFLeZPoFFylkp4RBP9ELSxeW0gPTbnn7J2 8VJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/epglAJkmZJeRkXv6q4caamkK8lCYIB3NIhIVYRg2kY=; b=YKvWhV98SOR5YWWWVLUIIRZQ9vmapHXDVHxkLpv/CwnhHQg3SBt/TuVwEDaV6O+8AK KqfkEKRWo7HVCflsrjCgFJ5GRfMV5XEX3fPM5adUm2j9YUYGA8LtozisGwWiznnMqTpS dLqOEbL0sZbhJgZ+oFdhaxdA6H7BWnB330Mqwv8bgakD+jz5WB0PzEoZ2OHq2Q/j/dJI R7SpO1xhxI7x4tkGs1nsSxRydf9vsuPKJTnjl2nUywW2Uau4KHIy63SysUKt75mCWQpk iXkJ6RQvcUWas2cbn1NUxGBeHb58uOg6Lmuqzvn+lukQYFZdEukj2Ra3z8h3JTSCplhA HYaQ== X-Gm-Message-State: APjAAAV+X2co6EDUTN0a5aqao6t2dmUI/t9lxJpwr0faLKHMN+f8fm42 Cv9t1yscE9dUPCbcrbFnx4fa5SP7KqxXuIhCQTotsg== X-Google-Smtp-Source: APXvYqzyvdu4/0tQURmEFlLrm1uXzTJw8sJzigY029rNNex/9n3iaHESQv1oSkIKJBNR0+V72imjJGrXKcFkrQ4G7wA= X-Received: by 2002:a5d:628e:: with SMTP id k14mr12107689wru.60.1572207396539; Sun, 27 Oct 2019 13:16:36 -0700 (PDT) MIME-Version: 1.0 References: <20190924193312.17381-1-iryzhov@nfware.com> <20190925093623.18419-1-iryzhov@nfware.com> <05b55e82-f992-c9d3-593d-3c608b7bb543@intel.com> <347b8a5c-f7c8-45d4-063f-2a4b5bdf90cc@intel.com> In-Reply-To: From: Igor Ryzhov Date: Sun, 27 Oct 2019 23:16:25 +0300 Message-ID: To: Dan Gora Cc: Ferruh Yigit , dev , Aaron Conole Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v3] kni: rework rte_kni_update_link using ioctl X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Ferruh, Dan, Sure, I remember last year discussion but now I see the problem in current implementation. Ferruh, here is an example: We have a thread in the application that processes KNI commands from the kernel. It receives config_network_if command to set interface up, calls rte_eth_dev_start, and here is the problem. We cannot call current rte_kni_update_link from here as the interface is not yet up in the kernel, as we didn't send a response for config_network_if yet. So we need to send a response first and only after that, we can use rte_kni_update_link. Actually, we don't even know the exact time between we send a response and the moment when the kernel receives it and the interface becomes up. We always have a dependency on the interface state in the kernel. With ioctl approach, we don't have such dependency - we can call rte_kni_update_link whenever we want, even when the interface is down in the kernel. As I explained, it's common when processing config_network_if to set interface up. Igor On Mon, Oct 14, 2019 at 11:56 PM Dan Gora wrote: > Here's another link to the thread where this was discussed last year.. > Igor was actually on this thread as well... > > https://mails.dpdk.org/archives/dev/2018-August/110383.html > > On Mon, Oct 14, 2019 at 4:01 PM Dan Gora wrote: > > > > My original patch to add this feature was basically the same thing as > > this: setting the link status via a KNI ioctl. That method was > > rejected after _much_ discussion and we eventually settled on the > > currently implementation. > > > > My original patch was here: Message-Id: < > 20180628225548.21885-1-dg@adax.com> > > > > If you search for KNI and dg@adax.com in the DPDK devel list you > > should be able to suss out the whole discussion that lead to the > > current implementation. > > > > thanks > > dan > > > > On Mon, Oct 14, 2019 at 1:17 PM Ferruh Yigit > wrote: > > > > > > On 10/14/2019 5:10 PM, Ferruh Yigit wrote: > > > > On 9/25/2019 10:36 AM, Igor Ryzhov 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. > > > > > > > > Hi Igor, > > > > > > > > The existing thread tracks the link status of the physical device > and reflects > > > > the changes to the kni netdev, but the "struct rte_kni_ops" > > > > (rte_kni_ops.config_network_if) works other way around, it captures > (some) > > > > requests to kni netdev and reflects them to the underlying physical > device. > > > > Even 'rte_kni_update_link()' updated to use ioctl, the thread still > looks > > > > required and this patch doesn't really changes that part. > > > > > > > > Also I am reluctant to extend the KNI ioctl interface when there is > a generic > > > > way to do that work. > > > > > > > > What is the use case of updating kni netdev carrier status when the > interface is > > > > down? > > > > > > btw, if the problem is status of the interface being 'no-carrier' by > default, > > > this can be changed by "carrier=on" parameter of the kni kernel module: > > > "insmod ./build/kmod/rte_kni.ko carrier=on" >