From: Igor Ryzhov <iryzhov@nfware.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Dan Gora <dg@adax.com>, Ferruh Yigit <ferruh.yigit@intel.com>,
dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2 10/10] kni: add API to set link status on kernel interface
Date: Thu, 30 Aug 2018 13:32:58 +0300 [thread overview]
Message-ID: <CAF+s_FwbZsUmnmxHbhPgJrT9rQVt0rN5CKkaVhRcd=+1R33cog@mail.gmail.com> (raw)
In-Reply-To: <CAF+s_Fx=x8wO5Ygxr4sxUj2G1hh+dRyFr7XiwYHL4SUPRNhX4g@mail.gmail.com>
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 <iryzhov@nfware.com> wrote:
> Hi Dan,
>
> We use KNI device exactly the same way you described – with IP addresses,
> 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/<iface>/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 = status ? "1" : "0";
> int fd, ret;
>
> sprintf(path, "/sys/devices/virtual/net/%s/carrier", name);
> fd = open(path, O_WRONLY);
> if (fd == -1) {
> return -errno;
> }
>
> ret = write(fd, carrier, 2);
> if (ret == -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 <dg@adax.com> wrote:
>>
>> > On Wed, Aug 29, 2018 at 7:12 PM, Dan Gora <dg@adax.com> wrote:
>> > > On Wed, Aug 29, 2018 at 7:00 PM, Stephen Hemminger
>> > > <stephen@networkplumber.org> 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 <dg@adax.com>
>> > >>> >
>> > >>> > 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
>> > ===========================================
>> >
>> > The kernel-exported sysfs exports internal kernel implementation details
>> > and depends on internal kernel structures and layout. It is agreed upon
>> > by the kernel developers that the Linux kernel does not provide a stable
>> > internal API. Therefore, there are aspects of the sysfs interface that
>> > may not be stable across kernel releases.
>> >
>> > <snip>
>> >
>> > - 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``)
>> > <snip>
>> >
>> > - kernel name (``sda``, ``tty``, ``0000:00:1f.2``, ...)
>> > <snip>
>> >
>> > - subsystem (``block``, ``tty``, ``pci``, ...)
>> > <snip>
>> >
>> > - driver (``tg3``, ``ata_piix``, ``uhci_hcd``)
>> > <snip>
>> >
>> > - attributes
>> > <snip>
>> >
>> > 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.
>>
>
>
next prev parent reply other threads:[~2018-08-30 10:33 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-28 22:45 [dpdk-dev] [PATCH 00/10] kni: Interface detach and link status fixes Dan Gora
2018-06-29 1:54 ` Dan Gora
2018-06-29 1:54 ` [dpdk-dev] [PATCH v2 01/10] kni: remove unused variables from struct kni_dev Dan Gora
2018-08-29 10:29 ` Ferruh Yigit
2018-06-29 1:55 ` [dpdk-dev] [PATCH v2 02/10] kni: separate releasing netdev from freeing KNI interface Dan Gora
2018-08-29 10:59 ` Ferruh Yigit
2018-09-04 0:20 ` Dan Gora
2018-09-04 0:36 ` Dan Gora
2018-10-10 17:24 ` Ferruh Yigit
2018-10-10 18:18 ` Dan Gora
2018-10-10 22:51 ` Ferruh Yigit
2018-10-10 23:38 ` Dan Gora
2018-06-29 1:55 ` [dpdk-dev] [PATCH v2 03/10] kni: don't touch struct kni_dev after freeing Dan Gora
2018-06-29 1:55 ` [dpdk-dev] [PATCH v2 04/10] kni: add rte_kni_free to KNI library Dan Gora
2018-06-29 1:55 ` [dpdk-dev] [PATCH v2 05/10] kni: don't run rte_kni_handle_request after interface release Dan Gora
2018-06-29 1:55 ` [dpdk-dev] [PATCH v2 06/10] kni: increase length of timeout for KNI responses Dan Gora
2018-06-29 1:55 ` [dpdk-dev] [PATCH v2 07/10] kni: update kni test for rte_kni_free Dan Gora
2018-06-29 1:55 ` [dpdk-dev] [PATCH v2 08/10] kni: add rte_kni_free to KNI example app Dan Gora
2018-06-29 1:55 ` [dpdk-dev] [PATCH v2 09/10] kni: add rte_kni_free to KNI vdev driver Dan Gora
2018-06-29 1:55 ` [dpdk-dev] [PATCH v2 10/10] kni: add API to set link status on kernel interface Dan Gora
2018-08-29 11:48 ` Ferruh Yigit
2018-08-29 21:10 ` Dan Gora
2018-08-29 22:01 ` Stephen Hemminger
2018-08-29 15:54 ` Stephen Hemminger
2018-08-29 21:02 ` Dan Gora
2018-08-29 22:00 ` Stephen Hemminger
2018-08-29 22:12 ` Dan Gora
2018-08-29 22:41 ` Dan Gora
2018-08-29 23:10 ` Stephen Hemminger
2018-08-30 9:49 ` Igor Ryzhov
2018-08-30 10:32 ` Igor Ryzhov [this message]
2018-08-30 21:41 ` Dan Gora
2018-08-30 22:09 ` Stephen Hemminger
2018-08-30 22:11 ` Dan Gora
2018-09-04 0:47 ` Dan Gora
2018-09-05 12:57 ` Stephen Hemminger
2018-09-11 21:45 ` Dan Gora
2018-09-11 21:52 ` Stephen Hemminger
2018-09-11 22:07 ` Dan Gora
2018-09-11 23:14 ` Stephen Hemminger
2018-09-12 4:02 ` Jason Wang
2018-09-11 23:14 ` [dpdk-dev] [PATCH 0/2] " Dan Gora
2018-09-11 23:14 ` [dpdk-dev] [PATCH 1/2] " Dan Gora
2018-09-11 23:18 ` Dan Gora
2018-07-20 11:36 ` [dpdk-dev] [PATCH 00/10] kni: Interface detach and link status fixes Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAF+s_FwbZsUmnmxHbhPgJrT9rQVt0rN5CKkaVhRcd=+1R33cog@mail.gmail.com' \
--to=iryzhov@nfware.com \
--cc=dev@dpdk.org \
--cc=dg@adax.com \
--cc=ferruh.yigit@intel.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).