From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9879EA0A02; Thu, 14 Jan 2021 19:20:14 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7FA88140DF0; Thu, 14 Jan 2021 19:20:14 +0100 (CET) Received: from out0-135.mail.aliyun.com (out0-135.mail.aliyun.com [140.205.0.135]) by mails.dpdk.org (Postfix) with ESMTP id 546C6140DEB for ; Thu, 14 Jan 2021 19:20:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1610648411; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type; bh=r4BtYsrD6tYkUmz5rAfIDzP2CT9mkCZ8LfVntmyLFkc=; b=eDUmBWhXiDPvz/kXLnHq8lL9wCXAkMkc0W9N5YflOg3h16OXWZGVnRiUav2NIqUmSPwSMk1Ta7rBsTgFNhedLsQlJp5MzJ6o8eD8dNujjeyLu1IKKCaGJvExbJUEDdlV2e/yacWeBqyuWHt+Ab9gjplTnKRXoupkH+Weht5G6+A= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R121e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=ay29a033018047188; MF=huawei.xhw@alibaba-inc.com; NM=1; PH=DS; RN=8; SR=0; TI=SMTPD_---.JKHriaX_1610648389; Received: from 30.39.146.168(mailfrom:huawei.xhw@alibaba-inc.com fp:SMTPD_---.JKHriaX_1610648389) by smtp.aliyun-inc.com(127.0.0.1); Fri, 15 Jan 2021 02:19:49 +0800 To: Maxime Coquelin , ferruh.yigit@intel.com Cc: dev@dpdk.org, anatoly.burakov@intel.com, david.marchand@redhat.com, zhihong.wang@intel.com, chenbo.xia@intel.com, grive@u256.net References: <68ecd941-9c56-4de7-fae2-2ad15bdfd81a@alibaba-inc.com> <1603381885-88819-1-git-send-email-huawei.xhw@alibaba-inc.com> From: "=?UTF-8?B?6LCi5Y2O5LyfKOatpOaXtuatpOWIu++8iQ==?=" Message-ID: <6b05b2b3-7616-f121-d827-67a2b25c641b@alibaba-inc.com> Date: Fri, 15 Jan 2021 02:19:47 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v5 0/3] support both PIO and MMIO BAR for virtio PMD X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 2021/1/13 1:37, Maxime Coquelin wrote: > > On 10/22/20 5:51 PM, 谢华伟(此时此刻） wrote: >> From: "huawei.xhw" >> >> Legacy virtio-pci only supports PIO BAR resource. As we need to create lots of >> virtio devices and PIO resource on x86 is very limited, we expose MMIO BAR. >> >> Kernel supports both PIO and MMIO BAR for legacy virtio-pci device. We handles >> different type of BAR in the similar way. >> >> In previous implementation, with igb_uio we get PIO address from igb_uio >> sysfs entry; with uio_pci_generic, we get PIO address from >> /proc/ioports. >> For PIO/MMIO RW, there is different path for different drivers and arch. >> For VFIO, PIO/MMIO RW is through syscall, which has big performance >> issue. > Regarding the performance issue, do you have some numbers to share? > AFAICS, it can only have an impact on performance when interrupt mode is > used or queue notification is enabled. I didn't have performance number, but would do it when have time. Yes, it is not needed when virtio backend/device is working in polling mode. But anyway, ioctl isn't needed at all. /huawei > > Does your HW Virtio implementation requires notification? > > Is performance the only issue to have your HW working with Virtio PMD, > or is this series also fixing some functionnal issues? There is two purpose with this patch. One is to support MMIO, and the other is to unify/simplify the way to get IO/MMIO resource and read/write IO/MMIO port for virtio PMD. Current implementation is too complicated. /huawei > > Best regards, > Maxime >> On X86, it assumes only PIO is supported. >> >> All of the above is too much twisted. >> This patch unifies the way to get both PIO and MMIO address for different driver >> and arch, all from standard resource attr under pci sysfs. >> >> 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 >> >> huawei.xhw (3): >> PCI: use PCI standard sysfs entry to get PIO address >> PCI: support MMIO in rte_pci_ioport_map/unap/read/write >> PCI: don't use vfio ioctl call to access PIO resource >> >> drivers/bus/pci/linux/pci.c | 89 +------------------- >> drivers/bus/pci/linux/pci_uio.c | 177 ++++++++++++++++++++++++++++------------ >> 2 files changed, 128 insertions(+), 138 deletions(-) >>