DPDK patches and discussions
 help / color / mirror / Atom feed
From: Igor Ryzhov <iryzhov@nfware.com>
To: Dan Gora <dg@adax.com>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>, dev <dev@dpdk.org>,
	 Aaron Conole <aconole@redhat.com>
Subject: Re: [dpdk-dev] [PATCH v3] kni: rework rte_kni_update_link using ioctl
Date: Sun, 27 Oct 2019 23:16:25 +0300	[thread overview]
Message-ID: <CAF+s_FzSb_Tn8TQick3zsG2nngZFprv8W=SVyj0QM3tTJL_hQQ@mail.gmail.com> (raw)
In-Reply-To: <CAGyogRZaSeK+2GrLohvF869=+zNJMzT3y3aTThLSrOb_A1bVpQ@mail.gmail.com>

Hi Ferruh, Dan,

Sure, I remember last year discussion but now I see the problem in current
implementation.

Ferruh, here is an example:

We have a thread in the application that processes KNI commands from the
kernel.
It receives config_network_if command to set interface up, calls
rte_eth_dev_start, and here is the problem.
We cannot call current rte_kni_update_link from here as the interface is
not yet up in the kernel,
as we didn't send a response for config_network_if yet. So we need to send
a response first and only
after that, we can use rte_kni_update_link. Actually, we don't even know
the exact time between we
send a response and the moment when the kernel receives it and the
interface becomes up.
We always have a dependency on the interface state in the kernel. With
ioctl approach, we don't
have such dependency - we can call rte_kni_update_link whenever we want,
even when the interface is
down in the kernel. As I explained, it's common when processing
config_network_if to set interface up.

Igor

On Mon, Oct 14, 2019 at 11:56 PM Dan Gora <dg@adax.com> wrote:

> Here's another link to the thread where this was discussed last year..
> Igor was actually on this thread as well...
>
> https://mails.dpdk.org/archives/dev/2018-August/110383.html
>
> On Mon, Oct 14, 2019 at 4:01 PM Dan Gora <dg@adax.com> wrote:
> >
> > My original patch to add this feature was basically the same thing as
> > this: setting the link status via a KNI ioctl. That method was
> > rejected after _much_ discussion and we eventually settled on the
> > currently implementation.
> >
> > My original patch was here: Message-Id: <
> 20180628225548.21885-1-dg@adax.com>
> >
> > If you search for KNI and dg@adax.com in the DPDK devel list you
> > should be able to suss out the whole discussion that lead to the
> > current implementation.
> >
> > thanks
> > dan
> >
> > On Mon, Oct 14, 2019 at 1:17 PM Ferruh Yigit <ferruh.yigit@intel.com>
> wrote:
> > >
> > > On 10/14/2019 5:10 PM, Ferruh Yigit wrote:
> > > > On 9/25/2019 10:36 AM, Igor Ryzhov wrote:
> > > >> Current implementation doesn't allow us to update KNI carrier if the
> > > >> interface is not yet UP in kernel. It means that we can't use it in
> the
> > > >> same thread which is processing rte_kni_ops.config_network_if,
> which is
> > > >> very convenient, because it allows us to have correct carrier status
> > > >> of the interface right after we enabled it and we don't have to use
> any
> > > >> additional thread to track link status.
> > > >
> > > > Hi Igor,
> > > >
> > > > The existing thread tracks the link status of the physical device
> and reflects
> > > > the changes to the kni netdev, but the "struct rte_kni_ops"
> > > > (rte_kni_ops.config_network_if) works other way around, it captures
> (some)
> > > > requests to kni netdev and reflects them to the underlying physical
> device.
> > > > Even 'rte_kni_update_link()' updated to use ioctl, the thread still
> looks
> > > > required and this patch doesn't really changes that part.
> > > >
> > > > Also I am reluctant to extend the KNI ioctl interface when there is
> a generic
> > > > way to do that work.
> > > >
> > > > What is the use case of updating kni netdev carrier status when the
> interface is
> > > > down?
> > >
> > > btw, if the problem is status of the interface being 'no-carrier' by
> default,
> > > this can be changed by "carrier=on" parameter of the kni kernel module:
> > > "insmod ./build/kmod/rte_kni.ko carrier=on"
>

  reply	other threads:[~2019-10-27 20:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24 19:25 [dpdk-dev] [PATCH] " Igor Ryzhov
2019-09-24 19:33 ` [dpdk-dev] [PATCH v2] " Igor Ryzhov
2019-09-24 20:37   ` Aaron Conole
2019-09-25  9:00     ` Igor Ryzhov
2019-09-25  9:36   ` [dpdk-dev] [PATCH v3] " Igor Ryzhov
2019-10-14 16:10     ` Ferruh Yigit
2019-10-14 16:17       ` Ferruh Yigit
2019-10-14 19:01         ` Dan Gora
2019-10-14 20:55           ` Dan Gora
2019-10-27 20:16             ` Igor Ryzhov [this message]
2021-06-28 12:55               ` Ferruh Yigit
2021-06-28 13:16                 ` Igor Ryzhov
2021-07-04 16:06   ` [dpdk-dev] [PATCH v4 1/2] " Igor Ryzhov
2021-07-04 16:06     ` [dpdk-dev] [PATCH v4 2/2] kni: implement basic get_link_ksettings callback Igor Ryzhov
2021-07-05 11:58     ` [dpdk-dev] [PATCH v4 1/2] kni: rework rte_kni_update_link using ioctl Ferruh Yigit
2021-07-06  9:14       ` Igor Ryzhov
2021-08-26 15:19     ` [dpdk-dev] [PATCH v5 1/3] " Igor Ryzhov
2021-08-26 15:19       ` [dpdk-dev] [PATCH v5 2/3] kni: implement basic get_link_ksettings callback Igor Ryzhov
2021-08-26 15:19       ` [dpdk-dev] [PATCH v5 3/3] app/test: fix return value of test_kni_link_change Igor Ryzhov
2021-08-26 17:15       ` [dpdk-dev] [PATCH v5 1/3] kni: rework rte_kni_update_link using ioctl Stephen Hemminger
2021-08-26 17:46         ` Igor Ryzhov
2021-08-26 18:06           ` Stephen Hemminger
2021-08-30 18:05             ` Igor Ryzhov
2021-08-30 14:27       ` [dpdk-dev] [PATCH v6 " Igor Ryzhov
2021-08-30 14:27         ` [dpdk-dev] [PATCH v6 2/3] kni: implement basic get_link_ksettings callback Igor Ryzhov
2021-08-30 14:27         ` [dpdk-dev] [PATCH v6 3/3] app/test: fix return value of test_kni_link_change Igor Ryzhov
2023-06-29 17:05         ` [dpdk-dev] [PATCH v6 1/3] kni: rework rte_kni_update_link using ioctl Stephen Hemminger

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_FzSb_Tn8TQick3zsG2nngZFprv8W=SVyj0QM3tTJL_hQQ@mail.gmail.com' \
    --to=iryzhov@nfware.com \
    --cc=aconole@redhat.com \
    --cc=dev@dpdk.org \
    --cc=dg@adax.com \
    --cc=ferruh.yigit@intel.com \
    /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).