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 40694A09E4; Thu, 28 Jan 2021 14:44:07 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B2E1D4067A; Thu, 28 Jan 2021 14:44:06 +0100 (CET) Received: from out0-133.mail.aliyun.com (out0-133.mail.aliyun.com [140.205.0.133]) by mails.dpdk.org (Postfix) with ESMTP id 1B30F40395 for ; Thu, 28 Jan 2021 14:44:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1611841442; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type; bh=IHGdDjDiIVq01TmxpGXWiTZ8MpqMrnpB/yJfroQDAWo=; b=Ygz4rsLixNiERJQonHyVVfWOzAbT9c+Lq4PYoHcXHAVEGShfxXUBBHuy4pXjh1Kq91Lm77KsGbP0QXOkKcCJT0Ah8ou3SY7qFWpg/EF0CUw1mopx9L50xnvxdNxBReu3fhCkBuxea58bxZUlK8Fcz40cSkYVCEJ1JeK8+LdP/do= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R351e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=ay29a033018047202; MF=huawei.xhw@alibaba-inc.com; NM=1; PH=DS; RN=8; SR=0; TI=SMTPD_---.JRe2xqz_1611841441; Received: from 30.43.73.172(mailfrom:huawei.xhw@alibaba-inc.com fp:SMTPD_---.JRe2xqz_1611841441) by smtp.aliyun-inc.com(127.0.0.1); Thu, 28 Jan 2021 21:44:01 +0800 To: Ferruh Yigit , Maxime Coquelin Cc: dev@dpdk.org, anatoly.burakov@intel.com, david.marchand@redhat.com, chenbo.xia@intel.com, grive@u256.net, "Xueming(Steven) Li" References: <68ecd941-9c56-4de7-fae2-2ad15bdfd81a@alibaba-inc.com> <1603381885-88819-1-git-send-email-huawei.xhw@alibaba-inc.com> <1603381885-88819-4-git-send-email-huawei.xhw@alibaba-inc.com> <18871462-4d25-302a-2716-99ebec65c3ac@alibaba-inc.com> <40e0702d-7847-9dc3-1904-03a7b8e92c2e@alibaba-inc.com> <3c83a06d-c757-e470-441b-a8b7f496a953@redhat.com> <9b614cce-8e41-9ed6-a648-fbbe3fc14807@alibaba-inc.com> <71352868-a699-d876-25c3-b36df4f8649f@redhat.com> <22010641-89a9-15f5-6079-591cfef7dabb@intel.com> <915236c7-c8e1-b23c-d644-947fa22b3f26@alibaba-inc.com> <21913480-a3d8-81d5-b493-c8d9657fc68f@intel.com> From: "=?UTF-8?B?6LCi5Y2O5LyfKOatpOaXtuatpOWIu++8iQ==?=" Message-ID: <9866192f-f678-ec59-9ca4-2d0a5bed6470@alibaba-inc.com> Date: Thu, 28 Jan 2021 21:43:57 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <21913480-a3d8-81d5-b493-c8d9657fc68f@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v5 3/3] PCI: don't use vfio ioctl call to access PIO resource 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/28 0:45, Ferruh Yigit wrote: > On 1/27/2021 2:43 PM, 谢华伟(此时此刻） wrote: >> >> On 2021/1/27 18:32, Ferruh Yigit wrote: >>> I was waiting for clarification if this can be solved in virtio, >>> which seems clarified and decided to go with this patch, I am OK to >>> proceed with patch 1 & 2. >>> >>> But first patch changes how PIO address get, it changes the Linux >>> interface used to get the PIO. >>> And as far as I can see second patch requires this new interface to >>> be able to access the MEM resources. >>> >>> I have a concern that this interface change may cause issues with >>> various distros, kernel versions etc.. And prefer it goes through a >>> full -rc1 validation cycle. >>> >>> Huawei, I am aware the patch is around for a while but to play safe, >>> I suggest considering it for early next release, so it can be tested >>> enough, instead of getting if for -rc2/3 in this release. >>> >>> Thanks, >>> ferruh >>> >> Hi Ferruh and Maxime: >> >> igb_uio kernel driver gets resource through pci_resource_start, i.e, >> (dev)->resource[(bar)].start >> >> uio_pci_generic and the generic way in my patch 1 gets resource >> through the same interface: >> >>          pci dev driver exports to userspace the bar resource >> attributes through pci_dev->resource (check resource_show in kernel's >> drivers/pci/pci-sysfs.c) >> >> Other arch than x86 uses the same interface in their pci_uio_ioport_map. >> >> So patch 1 is the most generic way and shouldn't break things. >> /proc/ioports should be fully dropped. >> >> Using /proc/ioport is partly my fault at the very beginning. It >> causes so much mess. >> >> Could you please confirm this? >> > > Hi Huawei, > > I confirm that interface is already in use, > 'pci_parse_sysfs_resource()' does similar parsing. > > Most probably it is safe as you and Maxime said, and I am not trying > to be difficult but extra conscious here. > > Will it cause too much trouble to consider the patch early next > release? This gives more time and testing after the patch merged. > > Thanks, > ferruh Hi Ferruh: If early next release, what is about the schedule, early next February? In summary, patch 1 is simple and straightforward. It just don't use /proc/ioports and don't use resource attribute created by igb_uio and use the standard resource attribute under /sys/pci/. As i explained, the resource attribute created by igb_uio is exactly the same thing as the standard resource attribute under /sys/pci/. Patch 1 fixes messy things. Patch 2 fixes wrong assumptions (BAR is IO bar). Customers have been pushing us for quite a long time. Besides, at least in China,  virtio in VM with MMIO bar is a de-facto implementation. It brings quite much trouble not only to cloud users, but also to us self when we run DPDK. > >> Thanks huawei >> >>>> Could you please post v6? >>>> >>>> Thanks, >>>> Maxime >>>> >>>>>> >>>>>> It is not too late for this release, as the change will not be that >>>>>> intrusive. But if you prepare such patch, please base it on top >>>>>> of my >>>>>> virtio rework series; To make it easier to you, I added it to the >>>>>> dpdk- >>>>>> next-virtio tree: >>>>>> https://git.dpdk.org/next/dpdk-next-virtio/log/?h=virtio_pmd_rework_v2 >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Maxime >>>>>> >>>>>