From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 17117A2EFC for <public@inbox.dpdk.org>; Mon, 14 Oct 2019 22:56:25 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0C783CF3; Mon, 14 Oct 2019 22:56:24 +0200 (CEST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by dpdk.org (Postfix) with ESMTP id 94ACF1C2AC for <dev@dpdk.org>; Mon, 14 Oct 2019 22:56:22 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id b136so40943167iof.3 for <dev@dpdk.org>; Mon, 14 Oct 2019 13:56:22 -0700 (PDT) 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=xe93vf9f7n+8rOjfcSDqBRKIGhkeM1kxSu+wHiyh4zg=; b=hVp+w5HufIazsj+o4hf00mO+nVwc1kW44M0EIg3JdYyc1wKU2oS1LmakFwbn1kAV3+ FG5LqQaCeLf7vtN4udw7VUgHLPZIuaB0aqEKOW2OREvvJSCIxgGq7Yk3j+LQBSS0gtsu ygE3nJfO5eXyCNrHXyjXIgKZxp5FLHKcoM/HlVAG+C1beMs2JJiGuLXa8hqbDM3f0RbR GvgIYHTDBTbHF3Zhl5D5BWDEFOEFal+Wfowqee30gixcYZEaQ3hRKZbShw9MqkPNT3ul NhlgprJbw3BVp75nkL/HhptolCbCLLpxRn/pT2CpHFtWOKHxo6cDnCaqF5+b9AKaroHx VBqQ== X-Gm-Message-State: APjAAAVTbWD2S8CXGXkapoQa2tVnHeUCZQLnsETi59yCZWICeNBU/0kn PaWtqabr9tKL64RHfVCa8VbVuzxp7c3G8VXVnGM= X-Google-Smtp-Source: APXvYqxLifrKXyKAfE3MKlvRmuI7/20CqbwkJe5xz9wxUbtaGBVUOoOFNMV4sma2MwXRYgLF//8Od+QUI+xYTL0ywmE= X-Received: by 2002:a92:40c4:: with SMTP id d65mr2601613ill.50.1571086581576; Mon, 14 Oct 2019 13:56:21 -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> <CAGyogRZdsJiM893kmExQ=mV7KdYGk6mDTL-rfvdvAeuDqQaR9g@mail.gmail.com> In-Reply-To: <CAGyogRZdsJiM893kmExQ=mV7KdYGk6mDTL-rfvdvAeuDqQaR9g@mail.gmail.com> From: Dan Gora <dg@adax.com> Date: Mon, 14 Oct 2019 17:55:45 -0300 Message-ID: <CAGyogRZaSeK+2GrLohvF869=+zNJMzT3y3aTThLSrOb_A1bVpQ@mail.gmail.com> To: Ferruh Yigit <ferruh.yigit@intel.com> Cc: Igor Ryzhov <iryzhov@nfware.com>, dev@dpdk.org, aconole@redhat.com Content-Type: text/plain; charset="UTF-8" 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 <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 Sender: "dev" <dev-bounces@dpdk.org> 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 <dg@adax.com> 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 <ferruh.yigit@intel.com> 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"