patches for DPDK stable branches
 help / color / mirror / Atom feed
From: "Gupta, Nipun" <nipun.gupta@amd.com>
To: David Marchand <david.marchand@redhat.com>,
	"Ma, WenwuX" <wenwux.ma@intel.com>,
	"chenbo.xia@outlook.com" <chenbo.xia@outlook.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>,
	"Li, Miao" <miao.li@intel.com>,
	"Ling, WeiX" <weix.ling@intel.com>,
	"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [PATCH v4] bus/pci: fix legacy device IO port map in secondary process
Date: Wed, 18 Oct 2023 18:08:18 +0530	[thread overview]
Message-ID: <2ba09d01-8241-43a9-be90-5fbbfc75b2e4@amd.com> (raw)
In-Reply-To: <CAJFAV8zvD22kbBPZqfPyi_aK8wETUWF7LUmo5s6+gDPB_Og7jw@mail.gmail.com>



On 10/18/2023 3:35 PM, David Marchand wrote:
> On Mon, Oct 9, 2023 at 5:06 AM Ma, WenwuX <wenwux.ma@intel.com> wrote:
>>>  From a pci bus API pov, nothing prevents a driver from mixing memory
>>> mapped with vfio and ioport resources (iow, calls to
>>> rte_pci_map_resource() and rte_pci_ioport_map()).
>>> IOW, it may not be the case with the net/virtio driver but, in theory,
>>> rte_pci_ioport_map()/pci_vfio_ioport_map() may be called after a
>>> rte_pci_map_resource() call.
>>>
>>> In a similar manner, from the API pov,
>>> rte_pci_ioport_map()/pci_vfio_ioport_map() may be called for multiple bars.
>>>
>>> In summary, nothing in this patch checks that vfio has been configured already
>>> and I think we need a refcount to handle those situations.
>>>
>> We call rte_vfio_setup_device just to get device info, we can call rte_vfio_release_device as soon as pci_vfio_fill_regions is done.
>> This avoids reference counting operations, do you think it works?
> 
> Afaics, rte_vfio_setup_device should not be called if a call to
> rte_pci_map_device for this device was successful (rte_pci_map_device
> itself calls rte_vfio_setup_device).
> And as a consequence, calling rte_vfio_release_device cannot be done
> unconditionnally neither.

Hi David,

AFAIU, rte_vfio_setup_device() is written as re-entrant and does not 
create the DMA mapping again if it is already done for the iommu group.

When this API is called again either for a device within the same group 
or from the device for which it is already called, it mainly only does 
the work for device info get. Though not the best thing to use like 
this, but if this is called multiple times it should not have any 
negative impact.

As Wenmu mention that they need only device info from VFIO, a separate 
API to get device info can be added in eal_vfio.c/h. The device info 
portion of rte_vfio_setup_device() can be moved out to a new API, and 
rte_vfio_setup_device() can call this new API too?

Thanks,
Nipun

  reply	other threads:[~2023-10-18 12:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-07  1:58 [PATCH] " Wenwu Ma
2023-08-13  6:15 ` Gupta, Nipun
2023-08-16  1:11   ` Ma, WenwuX
2023-08-21  1:27 ` [PATCH v2] " Wenwu Ma
2023-08-21  2:53   ` Stephen Hemminger
2023-08-22  2:13     ` Ma, WenwuX
2023-08-22  2:18 ` [PATCH v3] " Wenwu Ma
2023-08-28  6:06   ` Gupta, Nipun
2023-08-29  8:00     ` Ma, WenwuX
2023-08-30  5:07 ` [PATCH v4] " Wenwu Ma
2023-09-04 15:06   ` Gupta, Nipun
2023-09-05  3:10   ` Ling, WeiX
2023-10-03 10:21   ` David Marchand
2023-10-09  3:06     ` Ma, WenwuX
2023-10-18 10:05       ` David Marchand
2023-10-18 12:38         ` Gupta, Nipun [this message]
2023-10-18 13:44           ` David Marchand
2023-10-24  2:00 ` [PATCH v5] " Wenwu Ma
2023-10-27 12:50   ` Gupta, Nipun
2023-11-14 10:24   ` [PATCH v6] bus/pci: fix legacy device IO port map Mingjin Ye
2023-11-15 11:26     ` Gupta, Nipun
2023-08-29  8:07 [PATCH v4] bus/pci: fix legacy device IO port map in secondary process xinfeng zhao
2023-08-29  8:09 xinfeng zhao
2023-08-30  1:36 Wenwu Ma

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=2ba09d01-8241-43a9-be90-5fbbfc75b2e4@amd.com \
    --to=nipun.gupta@amd.com \
    --cc=chenbo.xia@outlook.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=maxime.coquelin@redhat.com \
    --cc=miao.li@intel.com \
    --cc=stable@dpdk.org \
    --cc=weix.ling@intel.com \
    --cc=wenwux.ma@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).