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 2842BA04B5; Tue, 12 Jan 2021 18:38:36 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B8167140EE8; Tue, 12 Jan 2021 18:37:46 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mails.dpdk.org (Postfix) with ESMTP id 24931140EDB for ; Tue, 12 Jan 2021 18:37:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610473064; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VEy4LjtCSU98JUUcvJGSyQVDbfhYKEXojC9hGAT5Pqc=; b=J6mIajzMFx+NpjRgm0hnm+D1rmg47XIFqpiiUiqFqWpeJKgxDeCOnrnm09OJXdTXcOQjMw mk8jRKHtdTAbUzhOmF1crv0k4Hazo8ney8Wy7A+QNieTpOQisryqHS/cNPO74HrQEZ/2mH vFADO9MERzLycAUjBYC/PlwqzAgJFNE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-186-fuwhQyLCMwmY7CIfwvtMEQ-1; Tue, 12 Jan 2021 12:37:37 -0500 X-MC-Unique: fuwhQyLCMwmY7CIfwvtMEQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4E654107ACF7; Tue, 12 Jan 2021 17:37:36 +0000 (UTC) Received: from [10.36.110.24] (unknown [10.36.110.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3CFA45B6A3; Tue, 12 Jan 2021 17:37:31 +0000 (UTC) To: =?UTF-8?B?6LCi5Y2O5LyfKOatpOaXtuatpOWIu++8iQ==?= , 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: Maxime Coquelin Message-ID: Date: Tue, 12 Jan 2021 18:37:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <1603381885-88819-1-git-send-email-huawei.xhw@alibaba-inc.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=maxime.coquelin@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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 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? 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 > On X86, it assumes only PIO is supported. > > All of the above is too much twisted. > This patch unifies the way to get both PIO and MMIO address for different driver > and arch, all from standard resource attr under pci sysfs. > > We distinguish PIO and MMIO by their address like how kernel does. It is ugly but works. > > v2 changes: > - add more explanation in the commit message > > v3 changes: > - fix patch format issues > > v4 changes: > - fixes for RTE_KDRV_UIO_GENERIC -> RTE_PCI_KDRV_UIO_GENERIC > > v5 changes: > - split into three seperate patches > > huawei.xhw (3): > PCI: use PCI standard sysfs entry to get PIO address > PCI: support MMIO in rte_pci_ioport_map/unap/read/write > PCI: don't use vfio ioctl call to access PIO resource > > drivers/bus/pci/linux/pci.c | 89 +------------------- > drivers/bus/pci/linux/pci_uio.c | 177 ++++++++++++++++++++++++++++------------ > 2 files changed, 128 insertions(+), 138 deletions(-) >