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 8AAD9A0A0A; Thu, 21 Jan 2021 05:12:34 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 09DC3140E37; Thu, 21 Jan 2021 05:12:34 +0100 (CET) Received: from out0-145.mail.aliyun.com (out0-145.mail.aliyun.com [140.205.0.145]) by mails.dpdk.org (Postfix) with ESMTP id A4325140E2E for ; Thu, 21 Jan 2021 05:12:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1611202350; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type; bh=KFlVIVH4wzJThwrrLP8TqXjnu6z/7OwdY/+rjOp+ci8=; b=YjVLbZ6Vat7ML0ni7GbwAi3+KT1i+ODHCfjqOMfP6HH2oMKyvAeBBi88rLQLubMomSmfvM/pvbaMmr39AKWR4yAoLYCd1zKmHwty1gQqnhjs4U9N+Chofl9XeHBl+EZVLVA48GquhYWKty5hxPCtlk/hUwb+5kpuw5QnRARcP4A= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R431e4; 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=8; SR=0; TI=SMTPD_---.JNbkgL0_1611202348; Received: from 30.43.72.173(mailfrom:huawei.xhw@alibaba-inc.com fp:SMTPD_---.JNbkgL0_1611202348) by smtp.aliyun-inc.com(127.0.0.1); Thu, 21 Jan 2021 12:12:29 +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: <4a2bfa2c-5911-1281-3684-0250665e4901@alibaba-inc.com> Date: Thu, 21 Jan 2021 12:12:25 +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. > > 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. Anyway, using vfio ioctl isn't needed at all. virtio PMD is only the consumer of pci_vfio_ioport_read. we could consider if we still need pci_vfio_ioport_read related API in future. /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 >