From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by dpdk.org (Postfix) with ESMTP id 6D9071B4D5 for ; Thu, 27 Sep 2018 17:40:59 +0200 (CEST) Received: by mail-wm1-f67.google.com with SMTP id o2-v6so6410361wmh.5 for ; Thu, 27 Sep 2018 08:40:59 -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=6EUvsr9jKvxts/xP5bZPCONhx05lcSOXhjVTFWIWGUw=; b=ttcMBK2sKkC3H6OlAy1V07MmpJJX/asPG8qcKHOZwdpM2EjW6jdWgx5GGqbRQFECkK /XG5yOE5gBDRsYfAOnKRL0q/F/iJ2C1u56oMdr8yxr4RO3hamxXLzBBdMbjxRnh3Z/Sz noHE5C1h9wUayfmzF4cqoVHaDkiCs7sTFnvOFw03vePs7NSo7AZ2WwGTLP1E7QXl56T3 qimyko9l5KAPQCB8ygZdhnW2XLVHQJgNbKu+qlenkdu16KXuObJfsJ3a3PZ4kqnnXKjy RRrXd7aJ8kAMHTwnIPUF4KdXE8FAen2XX3G07+0j4gxGf9XZPygVdarJFv7NCZ0lv0yS S2NQ== X-Gm-Message-State: ABuFfogUa2IGRTjhB9VImNAFn/iSP2efn8sfaQdTMLqhCbObetLL0qYp n9slMCEG3jKxv1HBFTkeR7EK1Z+3JLl5gTj4ny0= X-Google-Smtp-Source: ACcGV62SJ8RxCtzc5XOCcinW7YG8H95Yyq8VyhNPWEewuJCnNW1oBL55f4ly7n6Iz0vSWxs63VrGwoc5/GXmd/0fUjU= X-Received: by 2002:a1c:3581:: with SMTP id c123-v6mr2647731wma.50.1538062858619; Thu, 27 Sep 2018 08:40:58 -0700 (PDT) MIME-Version: 1.0 References: <20180911232906.18352-1-dg@adax.com> <20180919195549.5585-1-dg@adax.com> <20180919195549.5585-2-dg@adax.com> <671135e5-a666-4254-c5c6-672c3863146b@intel.com> <61731242-db6c-0c5d-bcab-e82b45e324d7@intel.com> In-Reply-To: <61731242-db6c-0c5d-bcab-e82b45e324d7@intel.com> From: Dan Gora Date: Thu, 27 Sep 2018 12:40:19 -0300 Message-ID: To: Ferruh Yigit Cc: dev@dpdk.org, Igor Ryzhov , Stephen Hemminger Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v2 1/5] kni: add API to set link status on kernel interface 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: , X-List-Received-Date: Thu, 27 Sep 2018 15:40:59 -0000 On Thu, Sep 27, 2018 at 8:35 AM Ferruh Yigit wrote: > > On 9/26/2018 7:56 PM, Dan Gora wrote: > > On Wed, Sep 26, 2018 at 1:42 PM, Ferruh Yigit wrote: > >>> There is nothing to "reflect" to the kernel interface, nor to apply to > >>> the kernel interface. This is exactly how every other kernel driver > >>> works on link status changes. There is no "netif_set_speed()' > >>> function. When a link status change occurs the kernel driver calls > >>> netif_carrier_on/off() and prints a message like this one. > >> > >> I am not suggesting reflecting these into interface, I am just saying why do you > >> print them? > > > > Because the information is useful and because every other Ethernet > > driver does the same thing when the link status changes. > > It would be useful if it writes the values of virtual interface, but this API > prints user input. > I'm sorry, Ferruh, I really don't understand what you are referring to here. What virtual interface are you talking about? > The virtual interface may have different value, this API doesn't change anything > related other than link status, so why print user provided value. Again, because all this information is useful if the KNI interface is reflecting the state of a real physical ethenet interface. If the KNI interface is not reflecting a real peice of hardware, the user can continue not using this new API function or do something like set the speed to 0. This is what we get from ENA PMD drivers on amazon for instance. It's perfectly reasonable. > > Won't you think it will be confusing if the virtual interface values are > different than what printed. If what values are different from what? I'm really confused as to what use case you are referring to here. Can you give a concrete example? > Or won't user will think API changed those values to printed one in interface? again, what values? Changed how?