From: Dan Gora <dg@adax.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: 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: Wed, 29 Aug 2018 19:12:00 -0300 [thread overview]
Message-ID: <CAGyogRbhNrqR9xQ=0iuizbrZNtLNB4FW-CpnBDvGWCKHrSWAPg@mail.gmail.com> (raw)
In-Reply-To: <20180829150014.0ae59128@xeon-e3>
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.
Ok, I didn't know this...
Still it seems better to me to be able to call
rte_kni_update_link(kni, link); than 'open ("/sys/whatever/where ever
it may be this kernel version/link/"); write(fd, "1"); close(fd); or
whatever...
But I guess if it is actually a stable API, we can hide all of that in
'rte_kni_update_link() and just do away with the ioctl!
I'm actually kind of shocked that I'm the only one who has run into
this.. I would have thought that having an accurate link status would
have been important for whoever used KNI.
>
>> it's only
>> available for Linux (yes, I know KNI is linux-only currently, but
>> there's not really any technical reason why it can't work on BSD) and
>> there are already callbacks to change the MTU and MAC addresses which
>> could also be done via netlink. IMHO having the kernel have an
>> accurate view of the link state is more important than the ability to
>> change the MAC address of the interface...
>
> The device model on BSD is significantly different than Linux.
> Doing KNI on BSD is going to be a full rewrite of the driver anyway;
> I won't worry about sysfs, dependency.
>
> The important part is that if KNI is ever going to be supportable
> it needs to be upstream in Linux, not a bolt on out of tree driver.
> Most Enterprise distributions will not support out of tree drivers
> for good reasons.
Agreed there.. I was really torn between using KNI or the TAP
interface. KNI seems cleaner, and at least at the time that I started
working on this, seemed like the way to interface to the kernel moving
forward. The TAP interface stuff didn't seem like it was necessarily
going to be supported moving forward and the KNI was supposed to be
the "high performance" method to interface to the kernel. But having
to build and install the rte_kni module on every system that we
install our software on is a major pain.
d
next prev parent reply other threads:[~2018-08-29 22:12 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 [this message]
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
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='CAGyogRbhNrqR9xQ=0iuizbrZNtLNB4FW-CpnBDvGWCKHrSWAPg@mail.gmail.com' \
--to=dg@adax.com \
--cc=dev@dpdk.org \
--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).