DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
To: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
Cc: Shahaf Shuler <shahafs@mellanox.com>,
	"jerin.jacob@caviumnetworks.com" <jerin.jacob@caviumnetworks.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] eal/devargs: add option to supply PCI dev args
Date: Wed, 27 Jun 2018 11:57:36 +0200	[thread overview]
Message-ID: <20180627095736.jty7lbqesxufwiby@bidouze.vm.6wind.com> (raw)
In-Reply-To: <20180627085529.GA14236@ltp-pvn>

On Wed, Jun 27, 2018 at 02:25:30PM +0530, Pavan Nikhilesh wrote:
> Hi Gaëtan,
> 
> On Wed, Jun 27, 2018 at 10:39:59AM +0200, Gaëtan Rivet wrote:
> > Hi Ferruh, Pavan,
> >
> > sorry for the delay,
> >
> > On Tue, Jun 26, 2018 at 04:40:21PM +0100, Ferruh Yigit wrote:
> > > On 6/26/2018 1:48 PM, Shahaf Shuler wrote:
> > > > Hi Pavan,
> > > >
> > > > Friday, June 15, 2018 7:44 AM, Pavan Nikhilesh:
> > > >> Subject: [dpdk-dev] [PATCH v2] eal/devargs: add option to supply PCI dev
> > > >> args
> > > >>
> > > >> Currently, the only way of supplying device argument to a pci device is to
> > > >> whitelist it i.e. -w 000X:00:0X.0,self_test=1. This is not a very feasible method
> > > >> as whitelisting a device has its own side effects i.e only the whitelisted pci
> > > >> devices are probed.
> > > >>
> > > >> Add a new eal command line option --pci-args to pass device args without the
> > > >> need to whitelist the devices.
> > > >>            --pci-args 000X:00:0X.0,self_test=1
> > > >>
> > > >> Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
> > > >
> > > > Tested-by: Shahaf Shuler <shahafs@mellanox.com>
> > > >
> > > > It seems to work.
> > > > Please see small comments below
> > >
> > > Isn't this conflict with Gaetan's devarg work which has wider scope?
> > >
> >
> > Indeed it does.
> >
> > Pavan, I have submitted a new version of a series adding generic kvargs
> > to several layers (bus, class, driver).
> >
> > It does cover this exact use-case.
> >
> > However, while writing it, I wasn't able to find PCI bus specific
> > parameters, that could showcase the functionality.
> 
> The idea of the patch is to avoid whitelising a device when we want to
> supply kvargs to it, I tried mapping it to devargs rework patchset but couldn't
> do it at a glance. For example, the following patch[1] reads kvargs through
> whitelisting which should be avoided.
> 
> [1]http://patches.dpdk.org/patch/41223/
> 

I see.

Actually, your use-case won't be covered by the devargs rework.

I am still dumbfounded by how this blacklist/whitelist mode stuff is
kept against all odds. But that's not the time to deal with it.

The issue is that the two features "declaring a device" and
"configuring a bus" are currently awkwardly merged. You are piling stuff
on the "declaring a device" part to enhance the "configuring a bus"
feature.

Instead of going this way, I would advise to separate the two features.

If buses could be configured with a generic EAL option
"--blacklist=pci,vdev" for example, then you could provide devargs as
much as you want, the buses themselves would stay properly configured.

This means removing devargs policy, device types and rewriting bus logic
about it.

Regards,
-- 
Gaëtan Rivet
6WIND

  reply	other threads:[~2018-06-27  9:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15  4:43 Pavan Nikhilesh
2018-06-26 12:48 ` Shahaf Shuler
2018-06-26 15:40   ` Ferruh Yigit
2018-06-27  8:39     ` Gaëtan Rivet
2018-06-27  8:55       ` Pavan Nikhilesh
2018-06-27  9:57         ` Gaëtan Rivet [this message]
2018-07-10 10:19           ` Pavan Nikhilesh
2018-07-15 22:25             ` Thomas Monjalon
2018-07-16 11:05               ` Pavan Nikhilesh
2018-07-16 12:14                 ` Thomas Monjalon
2018-07-10 10:07   ` Pavan Nikhilesh

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=20180627095736.jty7lbqesxufwiby@bidouze.vm.6wind.com \
    --to=gaetan.rivet@6wind.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=pbhagavatula@caviumnetworks.com \
    --cc=shahafs@mellanox.com \
    --cc=thomas@monjalon.net \
    /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).