From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id B7EE7A034F;
Thu, 25 Feb 2021 05:00:03 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 2C98740692;
Thu, 25 Feb 2021 05:00:03 +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 C86824067B
for <dev@dpdk.org>; Thu, 25 Feb 2021 05:00:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=alibaba-inc.com; s=default;
t=1614225595; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type;
bh=Wd/kDOgwA5tgwzquvk5EM7f3LrDvXVQIQPPnskk369o=;
b=v70elRjiKRS/ZV3A/AUrB1pxAdwKbS5jOtOOSyAPNc3w6MqZ9C5OQHU8g26I0ziipNKRsspCtlawr6dLdzrZbJGmZXHi2D4IKuq1oqG+qby9H045Lwv8dKl700bABeobVc4oU3U0vRZzlptIR1g/KCpN//sb/SJZ/cdaZBgxGKs=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R221e4; CH=green; DM=||false|;
DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=ay29a033018047201;
MF=huawei.xhw@alibaba-inc.com; NM=1; PH=DS; RN=8; SR=0;
TI=SMTPD_---.Jcw1QO2_1614225593;
Received: from 30.39.199.149(mailfrom:huawei.xhw@alibaba-inc.com
fp:SMTPD_---.Jcw1QO2_1614225593) by smtp.aliyun-inc.com(127.0.0.1);
Thu, 25 Feb 2021 11:59:53 +0800
To: Ferruh Yigit <ferruh.yigit@intel.com>, 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>
<b34311c7-5b09-a1f6-1957-c9e19bb2a273@intel.com>
<e53cfa75-4505-c0fe-2214-1d066b2e28ba@alibaba-inc.com>
<08e5172f-36ce-13d9-5c96-9d6d1e71153a@intel.com>
From: "=?UTF-8?B?6LCi5Y2O5LyfKOatpOaXtuatpOWIu++8iQ==?="
<huawei.xhw@alibaba-inc.com>
Message-ID: <967cfffb-1955-afc2-8479-0afa255b317f@alibaba-inc.com>
Date: Thu, 25 Feb 2021 11:59:53 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <08e5172f-36ce-13d9-5c96-9d6d1e71153a@intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
On 2021/2/24 23:45, Ferruh Yigit wrote:
> 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" <huawei.xhw@alibaba-inc.com>
>>>>
>>>> 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 <huawei.xhw@alibaba-inc.com>
>>>> Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
>>>
>>> <...>
>>>
>>>> +
>>>> +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?
The pause version delays sometime by writing to 0x80 debug port. virtio
doesn't need this. virtio legacy PMD driver doens't use this.
Any device relying on this i think is buggy. How could the device rely
on some uncertain cpu cycles to behave correct?
>
> What is the downside of using "pause until the I/O completes" versions?
The downside in virtio PMD is a small performance penalty when we use it
to notify backend. CPU executes unnecessary serializing IO instruction.
I check kernel code, io wrapper for in/out doesn't use p version.