From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id DF8C65A44 for ; Thu, 30 Aug 2018 23:41:55 +0200 (CEST) Received: by mail-wr1-f68.google.com with SMTP id g33-v6so9380996wrd.1 for ; Thu, 30 Aug 2018 14:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=zr2Njpx8globkEco8DiyNGt7t8G9A+MYsKaIafh/b2k=; b=HTa/jTi4opGj3yX6zb0KhKrZc8QkA9TY04CnSggw+NAaNVI2Q4wS+Tde4017HdBx5S KJbqUomsttox+JIZVMaVWJ5j1Crd8sbP5455UcvaTvNshSrPSSWHfBXyDHgkSGB2HGd0 8S0Vc4Wrppv2EIz8BtaZCN3EV1r1ARj8NtInb82mCCwH3J30p/JT1uFVzetdWjXo84B8 SypB1S1glPJpnntkQlEX/LmAfgVO1OxST/fiMym68nKzXXvwF71O2bUhn7GK1YW/0hLB PU88NGBLkEcoDR83KDphXdbLkTxn5vdR6ZJp3zeejDyADcFzJ3oePquLbqR0R2GzrPfA rGaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=zr2Njpx8globkEco8DiyNGt7t8G9A+MYsKaIafh/b2k=; b=UUs7XGIpjIIUbHdavgJuZMxgJJUmqGA/wKh4SY2kNNJp+KQbTivZzy7SseRKGKtmT8 zSkR03JdN3XhXdJRS1TS9xPCmHyBt9UKjfWnOAgfOlTCvJAnawfgjSD1U1qxjdZafPEk /rkd+1wBblvFyF1nc8SxJFR5tGBaYfn53V0dVczap0k6eAKxY/rgLPOYpcXcZsEvxBh5 IJLc2X/q0NGQ/QULiAzIx/jyuPZ1LsunacXTMVBSOSKvwJ5c0osR0pbs2ntaFLLkL+7k fVBxRsZdfjGlohXCsLk8fHz0WwVdBy1lehJM8CnU/q9ZN1XYTeHQckkFg96nn+P1k7wE sa5g== X-Gm-Message-State: APzg51DpFXj0WarDQDYqArrHDcb87pgQPn3yHigU3efE2KsrmdZIbmNK wWb2rpSIhtIzBA6AHJ69UbogV7nJaEo4Bw7wWe4= X-Google-Smtp-Source: ANB0VdZwRFfmHueAza9Q+DEI5S41YiMjO/WgrA6LplB9C5wjGejmMawsVaZMpZo0jFvXsB0YftXH59ZNbSqtgteprHk= X-Received: by 2002:adf:bd10:: with SMTP id j16-v6mr8745841wrh.267.1535665315321; Thu, 30 Aug 2018 14:41:55 -0700 (PDT) MIME-Version: 1.0 Sender: dan.gora@gmail.com Received: by 2002:adf:fbc1:0:0:0:0:0 with HTTP; Thu, 30 Aug 2018 14:41:14 -0700 (PDT) In-Reply-To: References: <20180628224513.18391-1-dg@adax.com> <20180629015508.26599-1-dg@adax.com> <20180629015508.26599-11-dg@adax.com> <20180829085410.4411c07e@xeon-e3> <20180829150014.0ae59128@xeon-e3> <20180829161043.11bb2434@xeon-e3> From: Dan Gora Date: Thu, 30 Aug 2018 18:41:14 -0300 X-Google-Sender-Auth: tq_p3AslnkQ_rK9Dey2zgy-yk3g Message-ID: To: Igor Ryzhov Cc: Stephen Hemminger , Ferruh Yigit , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v2 10/10] 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, 30 Aug 2018 21:41:56 -0000 Hi All, So I'm a little unclear as to what to do here moving forward.. Do we all agree at least that there should be some function in DPDK in order to set the link state for KNI interfaces? I'm a strong yes on this point. I don't think that every KNI user should have to implement something like this themselves if we can provide a simple interface to do it. It seems like a natural extension of the KNI functionality IMHO. If so, should we use a new ioctl as in my patch, or just use the "write to /sys.../carrier" method as shown below? I'm kind of ambivalent about this point. The ioctl method has two minor advantages to my mind: 1) It's already done :) 2) You can set the link speed and duplex as well and get a pretty message in the syslog when the link status changes: [ 2100.016079] rte_kni: adax0 NIC Link is Up 10000 Mbps Full Duplex. [ 2100.016094] IPv6: ADDRCONF(NETDEV_CHANGE): adax0: link becomes ready [ 2262.532126] IPv6: ADDRCONF(NETDEV_UP): adax1: link is not ready [ 2263.432148] rte_kni: adax1 NIC Link is Up 10000 Mbps Full Duplex. [ 2263.432170] IPv6: ADDRCONF(NETDEV_CHANGE): adax1: link becomes ready On the other hand, the "write to /sys" method is a bit more simple and confines the changes to the user space library. If we're confident that the /sys ABI is stable and not going to be changed going forward it seems like a valid alternative. I'm willing to do it either way. I'll defer to the judgement of the community... thanks dan On Thu, Aug 30, 2018 at 6:49 AM, Igor Ryzhov wrote: > Hi Dan, > > We use KNI device exactly the same way you described =E2=80=93 with IP ad= dresses, > routing, etc. > And we also faced the same problem of having the actual link status in Li= nux > kernel. > > There is a special callback for link state management in net_device_ops f= or > soft-devices like KNI called ndo_change_carrier. > Current KNI driver implements it already, you just need to write to > /sys/class/net//carrier to change link status. > > Right now we implement it on application side, but I think it'll be good = to > have this in rte_kni API. > > Here is our implementation: > > static int > linux_set_carrier(const char *name, int status) > { > char path[64]; > const char *carrier =3D status ? "1" : "0"; > int fd, ret; > > sprintf(path, "/sys/devices/virtual/net/%s/carrier", name); > fd =3D open(path, O_WRONLY); > if (fd =3D=3D -1) { > return -errno; > } > > ret =3D write(fd, carrier, 2); > if (ret =3D=3D -1) { > close(fd); > return -errno; > } > > close(fd); > > return 0; > } > > Best regards, > Igor