DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, ferruh.yigit@intel.com
Subject: Re: [dpdk-dev] [PATCH v3 1/2] eal/pci: introduce a PCI driver flag
Date: Tue, 13 Jun 2017 10:13:35 +0530	[thread overview]
Message-ID: <20170613044333.GA5794@jerin> (raw)
In-Reply-To: <11032075.7h2FW7WDNx@xps>

-----Original Message-----
> Date: Mon, 12 Jun 2017 18:21:33 +0200
> From: Thomas Monjalon <thomas@monjalon.net>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Cc: dev@dpdk.org, ferruh.yigit@intel.com
> Subject: Re: [dpdk-dev]  [PATCH v3 1/2] eal/pci: introduce a PCI driver flag
> 
> 09/06/2017 12:27, Jerin Jacob:
> > Some ethdev devices like nicvf thunderx PMD need special treatment for
> > Secondary queue set(SQS) PCIe VF devices, where, it expects to not unmap
> > or free the memory without registering the ethdev subsystem.
> > 
> > Introducing a new RTE_PCI_DRV_KEEP_MAPPED_RES
> > PCI driver flag to request PCI subsystem to not unmap the mapped PCI
> > resources(PCI BAR address) if unsupported device detected.
> > 
> > Suggested-by: Ferruh Yigit <ferruh.yigit@intel.com>
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> [...]
> > --- a/lib/librte_eal/common/eal_common_pci.c
> > +++ b/lib/librte_eal/common/eal_common_pci.c
> > @@ -221,7 +221,12 @@ rte_pci_probe_one_driver(struct rte_pci_driver *dr,
> >  	ret = dr->probe(dr, dev);
> >  	if (ret) {
> >  		dev->driver = NULL;
> > -		if (dr->drv_flags & RTE_PCI_DRV_NEED_MAPPING)
> > +		if ((dr->drv_flags & RTE_PCI_DRV_NEED_MAPPING) &&
> > +			/* Don't unmap if device is unsupported and
> > +			 * driver needs mapped resources.
> > +			 */
> > +			!(ret > 0 &&
> > +				(dr->drv_flags & RTE_PCI_DRV_KEEP_MAPPED_RES)))
> >  			rte_pci_unmap_device(dev);
> >  	}
> >  
> > --- a/lib/librte_eal/common/include/rte_pci.h
> > +++ b/lib/librte_eal/common/include/rte_pci.h
> > +/** Device driver needs to keep mapped resources if unsupported dev detected */
> > +#define RTE_PCI_DRV_KEEP_MAPPED_RES 0x0020
> 
> If I understand well, you want to map resources but not probe it?

Yes.

> Shouldn't it be less hacky to probe it as a (new) null class?

The Vendor and Class ID is same for those device too so we need to map
the PCI bar and have access to know the class of device. If you are concerned about
if it an common code change, My first version was without common code change.
http://dpdk.org/dev/patchwork/patch/24983/

Ferruh would like to have flag scheme, I think it make sense for
PMD maintenance perspective.

  reply	other threads:[~2017-06-13  4:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-01 13:05 [dpdk-dev] [PATCH] net/thunderx: manage PCI device mapping for SQS VFs Jerin Jacob
2017-06-06 13:36 ` Ferruh Yigit
2017-06-06 14:05   ` Jerin Jacob
2017-06-06 14:54     ` Ferruh Yigit
2017-06-08 11:44 ` [dpdk-dev] [PATCH v2 1/2] eal/pci: introduce a PCI driver flag Jerin Jacob
2017-06-08 11:44   ` [dpdk-dev] [PATCH v2 2/2] net/thunderx: manage PCI device mapping for SQS VFs Jerin Jacob
2017-06-08 14:40   ` [dpdk-dev] [PATCH v2 1/2] eal/pci: introduce a PCI driver flag Ferruh Yigit
2017-06-08 17:15     ` Jerin Jacob
2017-06-08 19:44       ` Ferruh Yigit
2017-06-09  4:35         ` Jerin Jacob
2017-06-09  9:13           ` Ferruh Yigit
2017-06-09  9:27             ` Jerin Jacob
2017-06-09 10:27   ` [dpdk-dev] [PATCH v3 " Jerin Jacob
2017-06-09 10:27     ` [dpdk-dev] [PATCH v3 2/2] net/thunderx: manage PCI device mapping for SQS VFs Jerin Jacob
2017-06-09 10:46     ` [dpdk-dev] [PATCH v3 1/2] eal/pci: introduce a PCI driver flag Ferruh Yigit
2017-06-12 16:02       ` Ferruh Yigit
2017-06-12 16:21     ` Thomas Monjalon
2017-06-13  4:43       ` Jerin Jacob [this message]
2017-06-13  7:03         ` Thomas Monjalon
2017-06-13  7:24           ` Jerin Jacob
2017-06-13  8:18             ` Thomas Monjalon

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=20170613044333.GA5794@jerin \
    --to=jerin.jacob@caviumnetworks.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.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).