From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Wang Subject: Re: [PATCH v2 10/10] kni: add API to set link status on kernel interface Date: Wed, 12 Sep 2018 12:02:42 +0800 Message-ID: <015abb18-e3c2-c18e-06ea-9efd9b47b57b@redhat.com> 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> <20180911161424.55b4089e@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Igor Ryzhov , Ferruh Yigit , dev@dpdk.org To: Stephen Hemminger , Dan Gora Return-path: Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by dpdk.org (Postfix) with ESMTP id C15841041 for ; Wed, 12 Sep 2018 06:02:48 +0200 (CEST) In-Reply-To: <20180911161424.55b4089e@xeon-e3> Content-Language: en-US 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 2018年09月12日 07:14, Stephen Hemminger wrote: > 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. Why not use vhost_net instead? KNI duplicates its function. Thanks > > 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.