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 536AFA09E4; Thu, 21 Jan 2021 14:52:00 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C5C31140DE9; Thu, 21 Jan 2021 14:51:59 +0100 (CET) Received: from out0-153.mail.aliyun.com (out0-153.mail.aliyun.com [140.205.0.153]) by mails.dpdk.org (Postfix) with ESMTP id 45699140DE8 for ; Thu, 21 Jan 2021 14:51:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1611237116; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type; bh=2AUn4qXYMZ6QgMrulidfYDFuEDFvceT976E4uwUNJKs=; b=v3ubkTr6g8LrSP9wlOLw3CnhqC2ZfjJ7xmwoozHVIDSBT5CdIN0Mj1LrDeocUL73ttc4zlYCUqnx+ziA9H+nOTqCHaUJ5uo8Eodp1f9sDj7ss1SiJKABWfaMRe5FzBaeeT1jfVJTiSKt3P5F0kzQpq0OBRW3aTwMmqzBuBQIKk4= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R681e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=ay29a033018047211; MF=huawei.xhw@alibaba-inc.com; NM=1; PH=DS; RN=8; SR=0; TI=SMTPD_---.JNrorGJ_1611237113; Received: from 30.43.72.173(mailfrom:huawei.xhw@alibaba-inc.com fp:SMTPD_---.JNrorGJ_1611237113) by smtp.aliyun-inc.com(127.0.0.1); Thu, 21 Jan 2021 21:51:53 +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> <4a2bfa2c-5911-1281-3684-0250665e4901@alibaba-inc.com> <5791302d-4e43-9b26-860f-83d066060a02@redhat.com> From: "=?UTF-8?B?6LCi5Y2O5LyfKOatpOaXtuatpOWIu++8iQ==?=" Message-ID: Date: Thu, 21 Jan 2021 21:51:49 +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: <5791302d-4e43-9b26-860f-83d066060a02@redhat.com> 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/21 16:47, Maxime Coquelin wrote: > > On 1/21/21 5:12 AM, 谢华伟(此时此刻） wrote: >> 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. >>> >>> Does your HW Virtio implementation requires notification? >> Yes, hardware needs notification to tell which queue has more buffer. >> >> vhost backend also needs notification when it is not running in polling >> mode. >> >> It is easy for software backend to sync with frontend whether it needs >> notification through memory but a big burden for hardware. > Yes, I understand, thanks for the clarification. > >> Anyway, using vfio ioctl isn't needed at all. virtio PMD is only the >> consumer of pci_vfio_ioport_read. > My understanding is that using VFIO read/write ops is required for IOMMU > enabled case without cap_sys_rawio. And anyway, using inb/outb is just > bypassing VFIO. As I suggest in my other reply, it is better to document > that in the case of devices having PIO BARs, the user should consider > using UIO driver if performance is a concern. Get it. so user could read/write PIO using VFIO without iopl permission, with some performance penalty. >> we could consider if we still need pci_vfio_ioport_read related API in >> future. > I disagree. I think the pci_vfio_ioport_* API is required at least for > the IOMMU enabled case. > > Documentation is the way to go in my opinion, we can also add a warning > that performance may be degraded compared to UIO in > pci_vfio_ioport_map() when IOMMU is disabled if you think it may help > the users. > > Thanks, > Maxime > >> /huawei >>> Is performance the only issue to have your HW working with Virtio PMD, >>> or is this series also fixing some functionnal issues? >>> >>> Best regards, >>> Maxime >>>