From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH v2 10/10] kni: add API to set link status on kernel interface Date: Tue, 11 Sep 2018 16:14:24 -0700 Message-ID: <20180911161424.55b4089e@xeon-e3> 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> <20180830150911.6b0e7901@xeon-e3> <20180905135751.74f6c14b@shemminger-XPS-13-9360> <20180911145248.7512abd1@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Igor Ryzhov , Ferruh Yigit , dev@dpdk.org To: Dan Gora Return-path: Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by dpdk.org (Postfix) with ESMTP id EDCEE4C94 for ; Wed, 12 Sep 2018 01:14:27 +0200 (CEST) Received: by mail-pf1-f196.google.com with SMTP id k21-v6so12949079pff.11 for ; Tue, 11 Sep 2018 16:14:27 -0700 (PDT) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, 11 Sep 2018 19:07:47 -0300 Dan Gora wrote: > On Tue, Sep 11, 2018 at 6:52 PM, Stephen Hemminger > wrote: > > The carrier state has no meaning when device is down, at least for physical > > devices. Because often the PHY is powered off when the device is marked down. > > The thing that caught my attention is that when you mark a kernel > ethernet device 'down', you get a message that the link is down in the > syslog. > > snappy:root:bash 2645 => ip link set down dev eth0 > Sep 11 18:32:48 snappy kernel: e1000e: eth0 NIC Link is Down > > With this method, that's not possible because you cannot change the > link state from the callback from kni_net_release. > > The carrier state doesn't have any meaning from a data transfer point > of view, but it's often useful for being able to diagnose connectivity > issues (is my cable plugged in or not). > > I'm still not really clear what the objection really is to the ioctl > method. Is it just the number of changes? That the kernel driver has > to change as well? Just that there is another way to do it? > > thanks > dan I want to see KNI as part of the standard Linux kernel at some future date. Having KNI as an out of tree driver means it is doomed to chasing tail lights for the Linux kernel ABI instability and also problems with Linux distributions. One of the barriers to entry for Linux drivers is introducing new ioctl's. Ioctl's have issues with being device specific and also 32/64 compatiablity. If KNI has ioctl's it makes it harder to get merged some day. I freely admit that this is forcing KNI to respond to something that is not there yet, so if it is too hard, then doing it with ioctl is going to be necessary.