From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by dpdk.org (Postfix) with ESMTP id A310F2BF7 for ; Thu, 30 Aug 2018 11:49:49 +0200 (CEST) Received: by mail-pf1-f193.google.com with SMTP id d4-v6so3665410pfn.0 for ; Thu, 30 Aug 2018 02:49:49 -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=IitnLvkOyx5XyVqUlEY/X+YP7UqqdzMszI6Fu9BiMjg=; b=DQuDdJMgAqSOX+tph86ARS0V7E2oveCNRewUPZyEim0/Puxm41kZHxBPUKC3wmDTxV 6mJzBcA/nFwNuKQe7VvUuvZEPav+KCCk7557Lc9dWrvxsQ72OsF6DAaMrABWLMM/Wh7Q nvPD42WPHFRyvMU+lxnmTc2rXZRUPVSfsiGK0DB7QV0Y0IBQaAn2Rcx9L1QHngH1Vajk fKbGN+8weGxfyVFDaPSNCumLh7RfOJrS5/WM+M4X/rdfu0835cfgRpZBXOnKht8Skfm5 kr0pXWLV/yH5e9M2FUQcarrrICjrcd5gJJpjZHt4oxepRxaD/iV2PDEvmWUSc1+6w5fC Q4WA== 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=IitnLvkOyx5XyVqUlEY/X+YP7UqqdzMszI6Fu9BiMjg=; b=bcr0CWGuDbj5zU/2To4iSCJEn2cbDaC4GVAq0xNkV+mKE1omX3NrJ9yXAquvMXKNxF 4YbW2jP69Q8J8XoPx4zsS9CRb6OFQkvL3hvmRZWS2xwnO7tzGsfxFjB14vO39PVmIuuV CsuUQUuQpb+muSbvN3K5Kv+LgHu2V8jP8ePX45bnQMkLlCshd1s7NFpsvAjHFC43Npq3 2z9FO+vtD4D3DGRPTuAhPT0/9BgBw4VlUFa6JhKb7bfDXc9C4ByaMUGEn+c6Krufg3yM 2KUdUYkYqr0RiJ1nerrwYFh0rWHS/M0hfvAWVu60G8fmNNHLMtBVlBm+BGZ+6xHk+4D/ 7Ssw== X-Gm-Message-State: APzg51Ae7R5PMNxXZGltQH1joIRqe9Kg+1ZJEoxHA70qMU8SosGzWGoo Gc3mimOPkJbqucTRVrDV8CAjTL9jmBUw7Cl5B/t3QQ== X-Google-Smtp-Source: ANB0VdYNET4Xposszwv2V0NynUr2V2L9w0Z1nLpYFyVRNg3Y7qHdhdg57cRzj4lltYHJTfz8voKUkm6n7OK2eoT0nQM= X-Received: by 2002:a63:7d48:: with SMTP id m8-v6mr9207251pgn.0.1535622588817; Thu, 30 Aug 2018 02:49:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:c483:0:0:0:0 with HTTP; Thu, 30 Aug 2018 02:49:47 -0700 (PDT) In-Reply-To: <20180829161043.11bb2434@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> From: Igor Ryzhov Date: Thu, 30 Aug 2018 12:49:47 +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 09:49:50 -0000 Hi Dan, We use KNI device exactly the same way you described =E2=80=93 with IP addr= esses, 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 DP= DK > > >>> >> 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 detail= s > > and depends on internal kernel structures and layout. It is agreed upon > > by the kernel developers that the Linux kernel does not provide a stabl= e > > 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 goin= g > to change without major breakage in many many tools. >