DPDK patches and discussions
 help / color / mirror / Atom feed
From: Dan Gora <dg@adax.com>
To: Igor Ryzhov <iryzhov@nfware.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	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 18:41:14 -0300	[thread overview]
Message-ID: <CAGyogRattGkEds7dkwLmwyyfj3t0M_ygRxSJarrgLM=k3EWoiA@mail.gmail.com> (raw)
In-Reply-To: <CAF+s_Fx=x8wO5Ygxr4sxUj2G1hh+dRyFr7XiwYHL4SUPRNhX4g@mail.gmail.com>

Hi All,

So I'm a little unclear as to what to do here moving forward..

Do we all agree at least that there should be some function in DPDK in
order to set the link state for KNI interfaces?

I'm a strong yes on this point.  I don't think that every KNI user
should have to implement something like this themselves if we can
provide a simple interface to do it.  It seems like a natural
extension of the KNI functionality IMHO.

If so, should we use a new ioctl as in my patch, or just use the
"write to /sys.../carrier" method as shown below?

I'm kind of ambivalent about this point.  The ioctl method has two
minor advantages to my mind:

1) It's already done :)

2) You can set the link speed and duplex as well and get a pretty
message in the syslog when the link status changes:

[ 2100.016079] rte_kni: adax0 NIC Link is Up 10000 Mbps Full Duplex.
[ 2100.016094] IPv6: ADDRCONF(NETDEV_CHANGE): adax0: link becomes ready
[ 2262.532126] IPv6: ADDRCONF(NETDEV_UP): adax1: link is not ready
[ 2263.432148] rte_kni: adax1 NIC Link is Up 10000 Mbps Full Duplex.
[ 2263.432170] IPv6: ADDRCONF(NETDEV_CHANGE): adax1: link becomes ready

On the other hand, the "write to /sys" method is a bit more simple and
confines the changes to the user space library.  If we're confident
that the /sys ABI is stable and not going to be changed going forward
it seems like a valid alternative.

I'm willing to do it either way.  I'll defer to the judgement of the
community...

thanks
dan


On Thu, Aug 30, 2018 at 6:49 AM, 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

  parent reply	other threads:[~2018-08-30 21:41 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
2018-08-30 21:41                   ` Dan Gora [this message]
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='CAGyogRattGkEds7dkwLmwyyfj3t0M_ygRxSJarrgLM=k3EWoiA@mail.gmail.com' \
    --to=dg@adax.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=iryzhov@nfware.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).