From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by dpdk.org (Postfix) with ESMTP id 3260E231E for ; Thu, 30 Aug 2018 12:33:00 +0200 (CEST) Received: by mail-pf1-f195.google.com with SMTP id u24-v6so3674552pfn.13 for ; Thu, 30 Aug 2018 03:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nfware-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q/Helb/xTLDG4xiC46oHQz+cWW9Q3YZW/Y1QlQDfkpY=; b=Qmkd/+07/RJkx2Wugr6ylD8g0R+HDbzA+OTk9Eq9JR0nnWPQfD91S2A2HUuZLgDymr 1M5WB7Mra+AeuGvFp3i36Xy5h19t6Wy+Qk1zlSI0bS7WCCpTq5rj9RwQJARWIlPBgjM7 /oyrEOyi2NKtl0KB4c67imk/tYrOGOtC5dt1WOzErcgZinUmI0a9C8wQWa5fX5C3AHyL nj2ap6Jbmj8SrPC3M83zAuzVu9v0bV8aar6K+ZYlTBN8lweAkUX4GPhxAv/WUmLEH0Q3 pgaE02m1IMVvB5NRP1Efa9rIavnrU/4LpfpfNqmIBS+HV2JJqnRy/GPz2ByI1Au+JVE9 k5dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q/Helb/xTLDG4xiC46oHQz+cWW9Q3YZW/Y1QlQDfkpY=; b=L8ANzfHkwU9VUPaXiBlLcdnjglAl+7qxUVURobtOukGgCJUiOtiIpkDkDUCFP9/Nbr DeCtfgtqRJxkNDAOG2BQsc0DWtqkZDsZpSNWMtS5PPlAL7aAbeImzCgy4u1P1qk9rcty JaKW8y2a9yGB8s8QXs7L0ym0bXY2mE5eWQwtX1cisUgh0bSB/aYZzsAkPBID+es3Etdd JzI7vyIKeTMli2aTKMBYZDq2yBXSrttmBh8gxmW0/qyteIfaTyQL3p46pxBZDMLwv29m 9kII70KX1f8Y5jckYsHXlmmY9MLOwcU66x82ngClMRZUD13bpteWUbojVDHYJOlTPcvp AehQ== X-Gm-Message-State: APzg51Dy5TtcElPl6sr9xYTiiXjUNrCArkHxKsHyczjVpHcMU+H2JXDa BOL6kUrCoOtx0X+42FGu5Rox7sLFkpGz6D49Dm1Aaw== X-Google-Smtp-Source: ANB0VdbUIizhBM3hFh9y4VQpkybunhCMC0npR1eUZGD+qZZuomN8JjTZQDsiDamtxi7KHw349foeV1FZj9YDK+r5BfM= X-Received: by 2002:a63:4306:: with SMTP id q6-v6mr7806597pga.181.1535625179234; Thu, 30 Aug 2018 03:32:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:309:0:0:0:0 with HTTP; Thu, 30 Aug 2018 03:32:58 -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: Igor Ryzhov Date: Thu, 30 Aug 2018 13:32:58 +0300 Message-ID: To: Stephen Hemminger Cc: Dan Gora , Ferruh Yigit , dev@dpdk.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 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 10:33:00 -0000 Hi again, Forgot to mention netif_carrier_off changes. Your changes are necessary for correct link status management, but netif_carrier_off call should also be added to kni_ioctl_create before the register_netdev call. That's needed for correct link status even before first call to ndo_open. Best regards, Igor On Thu, Aug 30, 2018 at 12:49 PM, 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 > Linux kernel. > > There is a special callback for link state management in net_device_ops > for 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 > > On Thu, Aug 30, 2018 at 2:10 AM, Stephen Hemminger < > stephen@networkplumber.org> wrote: > >> On Wed, 29 Aug 2018 19:41:23 -0300 >> Dan Gora wrote: >> >> > On Wed, Aug 29, 2018 at 7:12 PM, Dan Gora wrote: >> > > On Wed, Aug 29, 2018 at 7:00 PM, Stephen Hemminger >> > > wrote: >> > >>> >> Add a new API function to KNI, rte_kni_update_link() to allow >> DPDK >> > >>> >> applications to update the link state for the KNI network >> interfaces >> > >>> >> in the linux kernel. >> > >>> >> >> > >>> >> Note that the default carrier state is set to off when the >> interface >> > >>> >> is opened. >> > >>> >> >> > >>> >> Signed-off-by: Dan Gora >> > >>> > >> > >>> > Do you really need a special ioctl for this? >> > >>> > There is already ability to set link state via sysfs or netlink. >> > >>> >> > >>> I think yes.. AFAIK sysfs does not constitute a stable API; >> > >> >> > >> It is a stable API on Linux. >> > > >> > >> > Actually this does not seem to be completely true... >> > >> > From Documentation/admin-guide/sysfs-rules.rst: >> > >> > Rules on how to access information in sysfs >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> > The kernel-exported sysfs exports internal kernel implementation detai= ls >> > and depends on internal kernel structures and layout. It is agreed upo= n >> > by the kernel developers that the Linux kernel does not provide a stab= le >> > internal API. Therefore, there are aspects of the sysfs interface that >> > may not be stable across kernel releases. >> > >> > >> > >> > - devices are only "devices" >> > There is no such thing like class-, bus-, physical devices, >> > interfaces, and such that you can rely on in userspace. Everything >> is >> > just simply a "device". Class-, bus-, physical, ... types are just >> > kernel implementation details which should not be expected by >> > applications that look for devices in sysfs. >> > >> > The properties of a device are: >> > >> > - devpath (``/devices/pci0000:00/0000:00:1d.1/usb2/2-2/2-2:1.0``) >> > >> > >> > - kernel name (``sda``, ``tty``, ``0000:00:1f.2``, ...) >> > >> > >> > - subsystem (``block``, ``tty``, ``pci``, ...) >> > >> > >> > - driver (``tg3``, ``ata_piix``, ``uhci_hcd``) >> > >> > >> > - attributes >> > >> > >> > Everything else is just a kernel driver-core implementation detail >> > that should not be assumed to be stable across kernel releases. >> >> Network device sysfs is stable. No one ever got around to putting it in >> documentation >> I wouldn't worry, once anything in /sys/class/net is added it is not >> going to change without major breakage in many many tools. >> > >