From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <iryzhov@nfware.com> Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) by dpdk.org (Postfix) with ESMTP id 7E54B1B154 for <dev@dpdk.org>; Fri, 28 Sep 2018 10:02:54 +0200 (CEST) Received: by mail-pf1-f194.google.com with SMTP id k21-v6so3748909pff.11 for <dev@dpdk.org>; Fri, 28 Sep 2018 01:02:54 -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=y4V9toZTwQCS7IAUALpOhm5+TaLNGgef+P4Ml1BKSbg=; b=zj/Haz7Q6ajtX3EUpfXA0xErjWXS6I4rvC5JCLLoY4A1l/Lp0lB7If0SgrNa2QlHKZ zY0DDrTYrMW7grbEGQYECg2T6rlylqDox5f2dwbsBHwbWos2jfn0hRRGj5CesfZ1eezT RyJlkr/9p3X5p1VCCoDUhWkRkL2oARlcui2+xEykwnBN8kppmVAOoAAlZ7UmEOM+ekUF /vkWV+s/BPupGVoNY69tHDsStwS+p2xM5qhO8YyZLXoMPPXmbRd4DqQ1/N+E8P7SqbQh s4sFJmrAfbLyZZWLlPbTtIlyMO60U0Q8UMwK85FCecaqcl8219UyKGyV7OexbV/fV31q 8Dpg== 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=y4V9toZTwQCS7IAUALpOhm5+TaLNGgef+P4Ml1BKSbg=; b=Iw/91nL7Wvy4592I0n9iYsTsMARRIuYEdPKsqlI9BoEWndyxL3NWvgUp1khB01YbFz 3oWjQr5eT1YYLtozweC5lqxVKkEnlZbYSseS+ISfbJk/hcn72SUm3mwTJcsmpfqCrJ4I gKcTeeIME/L2pm+7YZpAw1+nCUTYNGgc3ds/kDkdB3/ZRm7xHTWi7dX1qu0/K0ke6C+2 vTM8ftQXWgSLXnVfHHyi0GkO5iH31rvkWNipCJYTszaM5sYlsnlYDoydLShv8K+hQ3/F 7Hs31y5L+u/BM8Smw2i3Dil7o8xnAUPOkYhzDFuw7x9thTwXrY1jhJzd4XddaeXeajgF DkhA== X-Gm-Message-State: ABuFfoiOeFug17lR9tzNNVw+Wm074TMkCU7dna+KN6u5SGmJcyrvta1Y 6OgxY/35Bk3RBi+FmVDBxCOq8Zz+ic3cZlhWBBz+IA== X-Google-Smtp-Source: ACcGV60tit92IoAAS5IryxAp5VqiDM+MAF5PR5m7s2AxOOgBQhDJL6ellC7UolQk2CBhAJ/dPZik17RKwKrl7Uhzn78= X-Received: by 2002:a62:a116:: with SMTP id b22-v6mr14095918pff.99.1538121773539; Fri, 28 Sep 2018 01:02:53 -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> <CAGyogRZx6THZuRreTLEBiYjZ8V_sbZk3HZywSprUU0PM5Wy7QA@mail.gmail.com> <e8ba3242-2aea-87bf-3dd2-c1522285620e@intel.com> <CAGyogRa5rF5B_0=U68Dj1A1cyQevO+Qeww-9zAh86ekce+n64A@mail.gmail.com> <61731242-db6c-0c5d-bcab-e82b45e324d7@intel.com> <CAGyogRZcZPBwj8JcE+--RHqx2SY-sZc0W1M26bSQkBVjyxZ_Mg@mail.gmail.com> <d76bffde-506c-49b6-8db6-cfa79ad983d3@intel.com> <CAGyogRaO95E=KN-J=oFroXVcPeZrAqOY4T+yDPWcGiHCZMpM0Q@mail.gmail.com> <846eed94-2ed7-7b89-5a3e-696ec3674a26@intel.com> <CAGyogRaNVQqgZLVsAHjH0Hwma6_Y+16CdjLpAkBg+Me3bL7xqw@mail.gmail.com> In-Reply-To: <CAGyogRaNVQqgZLVsAHjH0Hwma6_Y+16CdjLpAkBg+Me3bL7xqw@mail.gmail.com> From: Igor Ryzhov <iryzhov@nfware.com> Date: Fri, 28 Sep 2018 11:02:42 +0300 Message-ID: <CAF+s_FztUxxoq75ZgrdYk_atqYBqCC-NJ45ZdDpvTn_+Zkegsw@mail.gmail.com> To: Dan Gora <dg@adax.com> Cc: Ferruh Yigit <ferruh.yigit@intel.com>, dev@dpdk.org, Stephen Hemminger <stephen@networkplumber.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 <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> X-List-Received-Date: Fri, 28 Sep 2018 08:02:55 -0000 Hi Dan, Ferruh, Why do we need "struct rte_eth_link" as a parameter at all? Only link status is used in the function =E2=80=93 let's use it only: rte_kni_update_link(struct rte_kni *kni, int link_status) /* 0 =E2=80=93 do= wn, 1 =E2=80=93 up */ It will also solve your differences as we won't have any "redundant" information to print :) Best regards, Igor On Fri, Sep 28, 2018 at 2:52 AM Dan Gora <dg@adax.com> wrote: > On Thu, Sep 27, 2018 at 8:44 PM, Ferruh Yigit <ferruh.yigit@intel.com> > wrote: > >> Well, yes the link_status (link up, link down) _is_ applied to the KNI > >> interface. When that occurs, most people want to know what the link > >> speed is that the link came up at. > > > > +1 to this, people would like to know link speed of the interface. > > Are you printing link speed of interface? You are printing whatever use= r > pass to > > API. > > There is no such thing as "link speed of the interface". The link > speed is the speed of the underlying Ethernet link that the interface > corresponds to. This is true for all other ethernet interfaces in the > kernel. > > > I guess you trust to user to provide correct values there, but since > only link > > up & down matters, what prevents user to leave other fields, like speed= , > just > > random values? > > Nothing. What prevents anyone from providing random values for > anything? The point of the API was to make it super simple, just: > > rte_eth_link_get_nowait(portid, &link); > rte_kni_update_link(p[portid]->kni[i], &link); > > No messing around with the link info retrieved from > rte_eth_link_get(_nowait), just dump in the struct that was returned. >