Message ID | 1614614483-75891-1-git-send-email-huawei.xhw@alibaba-inc.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 62944A054F; Mon, 1 Mar 2021 17:01:46 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A899A22A2DE; Mon, 1 Mar 2021 17:01:40 +0100 (CET) Received: from out0-140.mail.aliyun.com (out0-140.mail.aliyun.com [140.205.0.140]) by mails.dpdk.org (Postfix) with ESMTP id 1DA6922A2D5 for <dev@dpdk.org>; Mon, 1 Mar 2021 17:01:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1614614493; h=From:To:Subject:Date:Message-Id; bh=HNGis41VjwBh4IkX5aDpHihZIZArPnuC09aguTuAh/Q=; b=wCj5Bjf6C3d0CBP3PmMJn96BDTkub8m7offEgF0A7HmxRDMc7lXR2TQv48B/KLsCskcIXSwp80umeXaDc52cwIj7PxLOOlDqEG4MwBtIa9n6LQoDPoMKeVYQyaYTDfuX70arNBbvFfndw8f4rl5oMbz0Lkr4m7E0Sa7S5MN8RrI= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R201e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=ay29a033018047194; MF=huawei.xhw@alibaba-inc.com; NM=1; PH=DS; RN=9; SR=0; TI=SMTPD_---.JetXHrk_1614614484; Received: from rs3a10040.et2sqa.z1.et2sqa.tbsite.net(mailfrom:huawei.xhw@alibaba-inc.com fp:SMTPD_---.JetXHrk_1614614484) by smtp.aliyun-inc.com(127.0.0.1); Tue, 02 Mar 2021 00:01:29 +0800 From: " =?utf-8?b?6LCi5Y2O5LyfKOatpOaXtuatpOWIu++8iQ==?= " <huawei.xhw@alibaba-inc.com> To: ferruh.yigit@intel.com, maxime.coquelin@redhat.com, david.marchand@redhat.com Cc: <dev@dpdk.org>, <anatoly.burakov@intel.com>, <xuemingl@nvidia.com>, <grive@u256.net>, <chenbo.xia@intel.com>, " =?utf-8?b?6LCi5Y2O5LyfKOatpA==?= =?utf-8?b?5pe25q2k5Yi777yJ?= " <huawei.xhw@alibaba-inc.com> Date: Tue, 02 Mar 2021 00:01:21 +0800 Message-Id: <1614614483-75891-1-git-send-email-huawei.xhw@alibaba-inc.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1614014118-91150-1-git-send-email-huawei.xhw@alibaba-inc.com> References: <1614014118-91150-1-git-send-email-huawei.xhw@alibaba-inc.com> Subject: [dpdk-dev] [PATCH v8 0/2] support both PIO and MMIO BAR for legacy device in virtio PMD X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
support both PIO and MMIO BAR for legacy device in virtio PMD
|
|
Message
谢华伟(此时此刻)
March 1, 2021, 4:01 p.m. UTC
From: "huawei.xhw" <huawei.xhw@alibaba-inc.com>
virtio PMD assumes legacy device only supports PIO BAR resource. This is wrong.
As we need to create lots of devices, as PIO resource on x86 is very limited,
we expose MMIO(memory IO) BAR.
Kernel supports both PIO and MMIO BAR for legacy virtio-pci device, and for all
other pci devices. This patchset handles different type of BAR in the similar way.
In previous implementation, under igb_uio driver we get PIO address from igb_uio
sysfs entry; with uio_pci_generic, we get PIO address from /proc/ioports for x86,
and for other ARCHs, we get PIO address from standard PCI sysfs entry.
For PIO/MMIO RW, there is different path for different drivers and arch.
All of the above is too much twisted.
This patchset unifies the way to get both PIO and MMIO address for different driver
and ARCHs, all from standard resource attr under pci sysfs. This is most generic.
We distinguish PIO and MMIO by their address like how kernel does. It is ugly but works.
v2 changes:
- add more explanation in the commit message
v3 changes:
- fix patch format issues
v4 changes:
- fixes for RTE_KDRV_UIO_GENERIC -> RTE_PCI_KDRV_UIO_GENERIC
v5 changes:
- split into three seperate patches
v6 changes:
- change to DEBUG level for IO bar detection in pci_uio_ioport_map
- rework the code in iobar branch
- fixes commit message format issue
- temporarily remove the 3rd patch for vfio path, leave it for future discusssion
- rework against virtio_pmd_rework_v2
v7 changes:
- fix compilation issues of in/out instruction on non X86 archs
v8 changes:
- change the word fix to refactor in patch 1's commit message
huawei.xhw (2):
bus/pci: use PCI standard sysfs entry to get PIO address
bus/pci: support MMIO in PCI ioport accessors
drivers/bus/pci/linux/pci.c | 81 ----------------
drivers/bus/pci/linux/pci_uio.c | 202 +++++++++++++++++++++++++++++-----------
2 files changed, 150 insertions(+), 133 deletions(-)
Comments
Hi David and ferru: Any other issue integrating this patch? On 2021/3/2 0:01, 谢华伟(此时此刻) wrote: > From: "huawei.xhw"<huawei.xhw@alibaba-inc.com> > > virtio PMD assumes legacy device only supports PIO BAR resource. This is wrong. > As we need to create lots of devices, as PIO resource on x86 is very limited, > we expose MMIO(memory IO) BAR. > > Kernel supports both PIO and MMIO BAR for legacy virtio-pci device, and for all > other pci devices. This patchset handles different type of BAR in the similar way. > > In previous implementation, under igb_uio driver we get PIO address from igb_uio > sysfs entry; with uio_pci_generic, we get PIO address from /proc/ioports for x86, > and for other ARCHs, we get PIO address from standard PCI sysfs entry. > For PIO/MMIO RW, there is different path for different drivers and arch.
On 3/2/2021 12:48 PM, 谢华伟(此时此刻) wrote: Please don't top post, message moved down. > On 2021/3/2 0:01, 谢华伟(此时此刻) wrote: >> From: "huawei.xhw"<huawei.xhw@alibaba-inc.com> >> >> virtio PMD assumes legacy device only supports PIO BAR resource. This is wrong. >> As we need to create lots of devices, as PIO resource on x86 is very limited, >> we expose MMIO(memory IO) BAR. >> >> Kernel supports both PIO and MMIO BAR for legacy virtio-pci device, and for all >> other pci devices. This patchset handles different type of BAR in the similar >> way. >> >> In previous implementation, under igb_uio driver we get PIO address from igb_uio >> sysfs entry; with uio_pci_generic, we get PIO address from /proc/ioports for x86, >> and for other ARCHs, we get PIO address from standard PCI sysfs entry. >> For PIO/MMIO RW, there is different path for different drivers and arch. > > Hi David and ferru: > > Any other issue integrating this patch? > As far as I can see the 'outw_p' to 'outw' conversion is not clarified. Before this patch, 'outw_p' was used, now 'outw' is used, right? And this seem to optimize the performance, so the suggestion was to separate this change into another patch, what do you think about this?
On Tue, Mar 2, 2021 at 1:48 PM 谢华伟(此时此刻) <huawei.xhw@alibaba-inc.com> wrote: > > Hi David and ferru: > > Any other issue integrating this patch? I just replied on patch 2. Besides, checkpatch complains about trivial issues. http://mails.dpdk.org/archives/test-report/2021-March/180454.html http://mails.dpdk.org/archives/test-report/2021-March/180455.html Please fix this in v9. Thanks.