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 6E8DEA054F; Wed, 24 Feb 2021 16:46:14 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2B2294069B; Wed, 24 Feb 2021 16:46:14 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 60C5540040 for ; Wed, 24 Feb 2021 16:46:12 +0100 (CET) IronPort-SDR: 8qf4JKu/Ub4gxP2V3bfiBjdnE9kGHd8zNfJhxVRxMtc2WMrvnA32YbTQM3dlQhoxDu0YLlSvwf +LHHd7ShDvag== X-IronPort-AV: E=McAfee;i="6000,8403,9905"; a="185263036" X-IronPort-AV: E=Sophos;i="5.81,203,1610438400"; d="scan'208";a="185263036" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Feb 2021 07:45:54 -0800 IronPort-SDR: Vo0HDk8bdyuWjmVVT45pM5oXnRp0DWemRF/j5H+PXQRTOmK5evYi7kUivBT+ijSC6jtttBYQhF 6CGl1am1vYyw== X-IronPort-AV: E=Sophos;i="5.81,203,1610438400"; d="scan'208";a="442126630" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.253.18]) ([10.213.253.18]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Feb 2021 07:45:41 -0800 To: =?UTF-8?B?6LCi5Y2O5LyfKOatpOaXtuatpOWIu++8iQ==?= , 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 References: <1611890309-99135-1-git-send-email-huawei.xhw@alibaba-inc.com> <1614014118-91150-1-git-send-email-huawei.xhw@alibaba-inc.com> <1614014118-91150-3-git-send-email-huawei.xhw@alibaba-inc.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <08e5172f-36ce-13d9-5c96-9d6d1e71153a@intel.com> Date: Wed, 24 Feb 2021 15:45:11 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v7 2/2] bus/pci: support MMIO in PCI ioport accessors 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 2/23/2021 2:20 PM, 谢华伟(此时此刻） wrote: > > On 2021/2/23 1:25, Ferruh Yigit wrote: >> On 2/22/2021 5:15 PM, 谢华伟(此时此刻） wrote: >>> From: "huawei.xhw" >>> >>> With IO BAR, we get PIO(programmed IO) address. >>> With MMIO BAR, we get mapped virtual address. >>> We distinguish PIO(Programmed IO) and MMIO(memory mapped IO) by their address >>> like how kernel does. >>> ioread/write8/16/32 is provided to access PIO/MMIO. >>> By the way, for virtio on arch other than x86, BAR flag indicates PIO but is >>> mapped. >>> >>> Signed-off-by: huawei xie >>> Reviewed-by: Maxime Coquelin >> >> <...> >> >>> + >>> +static inline void iowrite8(uint8_t val, void *addr) >>> +{ >>> +    (uint64_t)(uintptr_t)addr >= PIO_MAX ? >>> +        *(volatile uint8_t *)addr = val : >>> +        outb(val, (unsigned long)addr); >> >> //copying question from previous version: >> >> Is the 'outb_p' to 'outb' conversion intentional? And if so why? >> >> Same of the all 'outb_p', 'outw_p', 'outl_p'. > > There is no need to delay for virtio device, as we can see in virtio legacy driver. > > IMO, the delay is for ugly old device. The device itself should assure the > previous IO completes when the subsequent IO instruction arrives. > Can there be any virtio legacy device needing this? What is the downside of using "pause until the I/O completes" versions?