DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
	Andrew Rybchenko <arybchenko@solarflare.com>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] ethdev: fix device info getting
Date: Wed, 01 Aug 2018 17:36:30 +0200	[thread overview]
Message-ID: <1716659.kXphz3AMnz@xps> (raw)
In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093B804D6C@shsmsx102.ccr.corp.intel.com>

16/07/2018 03:58, Lu, Wenzhuo:
> Hi Andrew,
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Lu, Wenzhuo
> > Sent: Monday, July 16, 2018 9:08 AM
> > To: Andrew Rybchenko <arybchenko@solarflare.com>; dev@dpdk.org
> > Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon
> > <thomas@monjalon.net>
> > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: fix device info getting
> > 
> > Hi Andrew,
> > 
> > > -----Original Message-----
> > > From: Andrew Rybchenko [mailto:arybchenko@solarflare.com]
> > > Sent: Friday, July 13, 2018 4:03 PM
> > > To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; dev@dpdk.org
> > > Cc: Yigit, Ferruh <ferruh.yigit@intel.com>; Thomas Monjalon
> > > <thomas@monjalon.net>
> > > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: fix device info getting
> > >
> > > Hi, Wenzhuo,
> > >
> > > I'm sorry, but I have more even harder questions than the previous one.
> > > This questions are rather generic and mainly to ethdev maintainers.
> > >
> > > On 13.07.2018 05:42, Wenzhuo Lu wrote:
> > > > The device information cannot be gotten correctly before the
> > > > configuration is set. Because on some NICs the information has
> > > > dependence on the configuration.
> > >
> > > Thinking about it I have the following question. Is it valid behaviour
> > > of the dev_info if it changes after configuration?
> > > I always thought that the primary goal of the dev_info is to provide
> > > information to app about device capabilities to allow app configure
> > > device and queues correctly. Now we see the case when dev_info changes
> > > on configure. May be it is acceptable, but it is really suspicious. If
> > > we accept it, it should be documented.
> > > May be dev_info should be split into parts: part which is persistent
> > > and part which may depend on device configuration.
> > As I remember, the similar discussion has happened :) I've raised the similar
> > suggestion like this. But we don’t make it happen.
> > The reason is, you see, this is the rte layer's behavior. So the user doesn't
> > have to know it. From APP's PoV, it inputs the configuration, it calls this API
> > "rte_eth_dev_configure". It doesn't know  the configuration is copied before
> > getting the info or not.
> > So, to my opinion, we can still keep the behavior. We only need to split it
> > into parts when we do see the case that cannot make it.
> Maybe I talked too much about the patch. Think about it again. Your comments is about how to use the APIs,
> rte_eth_dev_info_get, rte_eth_dev_configure. To my opinion, rte_eth_dev_info_get is just to get the info. It can be called anywhere, before configuration or after. It's reasonable the info changes with the configuration changing.
> But we do have something missing, like, rte_eth_dev_capability_get which should be stable. APP can use this API to get the necessary info before configuration.
> 
> A question, maybe a little divergent thinking, that APP should have some intelligence to handle the capability automatically. So getting the capability is not so good and effective, looks like we still need the human involvement. Maybe that the reason currently we suppose APP know the capability from the paper copies, examples...

I am not sure to understand all the sentences.
But I agree that we should take a decision about the stability
of these infos.
Either infos cannot change after probing,
or we must document that the app must request infos regularly (when?).

  reply	other threads:[~2018-08-01 15:36 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-12  5:27 [dpdk-dev] [PATCH] " Wenzhuo Lu
2018-07-12  8:06 ` Andrew Rybchenko
2018-07-13  1:56   ` Lu, Wenzhuo
2018-07-13  2:42 ` [dpdk-dev] [PATCH v2] " Wenzhuo Lu
2018-07-13  8:02   ` Andrew Rybchenko
2018-07-16  1:08     ` Lu, Wenzhuo
2018-07-16  1:58       ` Lu, Wenzhuo
2018-08-01 15:36         ` Thomas Monjalon [this message]
2018-08-13  2:50           ` Lu, Wenzhuo
2018-08-13  8:38             ` Andrew Rybchenko
2018-08-14  0:57               ` Lu, Wenzhuo
2018-08-22 16:55                 ` Ferruh Yigit
2018-08-23  8:58                   ` Andrew Rybchenko
2018-10-22 12:01                     ` Ferruh Yigit
2018-10-22 12:13                       ` Thomas Monjalon
2018-10-23  1:25                         ` Lu, Wenzhuo
2018-10-23  7:28                           ` Thomas Monjalon
2018-11-06  0:56                             ` Lu, Wenzhuo
2018-11-06  7:40                         ` Andrew Rybchenko
2018-11-08  2:09 ` [dpdk-dev] [PATCH v3 1/2] " Wenzhuo Lu
2018-11-08  2:09   ` [dpdk-dev] [PATCH v3 2/2] ethdev: device configuration enhancement Wenzhuo Lu
2018-11-08  6:25     ` Andrew Rybchenko
2018-11-09 21:10       ` Ferruh Yigit
2018-11-13  0:46         ` Lu, Wenzhuo
2018-11-13  9:40           ` Ferruh Yigit
2018-11-14  1:28             ` Lu, Wenzhuo
2018-11-13 11:12   ` [dpdk-dev] [PATCH v4 1/3] ethdev: fix invalid device configuration after failure Ferruh Yigit
2018-11-13 11:12     ` [dpdk-dev] [PATCH v4 2/3] ethdev: fix device info getting Ferruh Yigit
2018-11-13 11:19       ` Andrew Rybchenko
2018-11-13 11:12     ` [dpdk-dev] [PATCH v4 3/3] ethdev: eliminate interim variable Ferruh Yigit
2018-11-13 11:22       ` Andrew Rybchenko
2018-11-13 11:51         ` Ferruh Yigit
2018-11-13 11:56           ` Andrew Rybchenko
2018-11-13 11:19     ` [dpdk-dev] [PATCH v4 1/3] ethdev: fix invalid device configuration after failure Andrew Rybchenko
2018-11-13 17:49       ` 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=1716659.kXphz3AMnz@xps \
    --to=thomas@monjalon.net \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=wenzhuo.lu@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).