From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <stable-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 37E32A0C41 for <public@inbox.dpdk.org>; Tue, 22 Jun 2021 09:38:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 111E04003C; Tue, 22 Jun 2021 09:38:10 +0200 (CEST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by mails.dpdk.org (Postfix) with ESMTP id 530EB4003C for <stable@dpdk.org>; Tue, 22 Jun 2021 09:38:08 +0200 (CEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 8ECDE5807F3; Tue, 22 Jun 2021 03:38:07 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 22 Jun 2021 03:38:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= Qc97k8agkSedWaMrc4NEBi3E+MRIDkm4ydVswHfjVYM=; b=FuLvc0AuYyqmt7Rm CADQsWIbrBAD2u1Bn8zD6d6gpHcRAC6d1mJuuF6BpHA6uBDMEWIO9yLTEwOgx6GQ RowmvCTKf7+OfmoEfts7XjRtrpYosz4WZ9yTuqWEYKs6bHpIe4axX5eAUhbPdG3/ lthipgagU255nUi9DnggtBC6d9ojnbc6Ek7nfAWJo1H+QyXACcknSljzJZDcWJqy luyihZu3V6ZsRAbWkiaAS37CbowHy3uRthXtO1Ib3x5WSI8xS1eK09q7vsAz4uQX sTvfvyxxGgojXqlvXisHC9PPqcd1wSiHwZ1Xclm305JbohI8Sn7r+dOKm1VNtubF xSpaMw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Qc97k8agkSedWaMrc4NEBi3E+MRIDkm4ydVswHfjV YM=; b=UiAYRkUIMdGGdLFjZHkDL7Bt9PHOXWLmgxO5TD0k7XqcPaPcoHhUA5brK swJasaVXrFuTGer6ZnVvu2IpIOMjaSvyVlqj1UcU5ap2MjYqlPnPRivqoq6OQCtU qQqPVjlXtYvqfG33m7sKpgD/1v9asYJvGY/O+OqLnlkW8siXBJR+sR6G29LMuY+6 R/S3NkMeCrvRPUZe4onC6NN6k/tKThlJHx7DXAi5zwykT+DXpaivMyIJvN1UmCNy ANIX1+1n66rTjWCsKZ6ifaxolX46hxHf6M0DjoNkpkf/VccrETSv1gt3Sy+REhZo lm+wY/iMF8Jn9zzcyKOY0Pdljudbw== X-ME-Sender: <xms:XpPRYPdX268omli8Sux4lhtlSGZCaFqPf0ce8zuEwXuifoDjwfGDWw> <xme:XpPRYFN6FoPSfk_jagFtn-mL4fW4wxbk_fUJIZpF7bXaeaeiQRlysF9ii3ysrrVIn rPKHvky0yWEXG6NPw> X-ME-Received: <xmr:XpPRYIj_XLjNRY-Zb1Fo3vqopBiIr6_Lbj93o6oXqwD-PpfaEWlvqzcrjGk6xlFDQzNujYBciSp3jq-tiNg8hUoULfV9OlGAVccmkmji7iM> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeegtddguddvvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedvkeetveeihfegfedtfeejueekkeekueevgfejuedviedvvdev uefgteevtdefveenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: <xmx:XpPRYA9pcNMWCT8Xetbx4iBX2Sgg7XQyNfolkm-ks8OsZ4Og99VDDw> <xmx:XpPRYLv5Vx3VhyR5QuQJepq9INQ5uSjUG8L1w7ffr2r4Mz27yMl34A> <xmx:XpPRYPHyHWwNc91gbD_vz8SfhE5lf3JcbhEJ0-3-Gt7TJK7Kqr1uoQ> <xmx:X5PRYJLrPejjAf9C9QqA9kKfM58UqQFTx-HSzjXNZmGXYi7JWIs-SQ> Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 22 Jun 2021 03:38:04 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: =?utf-8?B?6LCi5Y2O5LyfKOatpOaXtuatpOWIu++8iQ==?= <huawei.xhw@alibaba-inc.com>, "Xueming(Steven) Li" <xuemingl@nvidia.com> Cc: "stable@dpdk.org" <stable@dpdk.org>, Luca Boccassi <bluca@debian.org>, Kevin Traynor <ktraynor@redhat.com>, "david.marchand@redhat.com" <david.marchand@redhat.com>, "maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>, "ferruh.yigit@intel.com" <ferruh.yigit@intel.com>, "grive@u256.net" <grive@u256.net>, "heqing.zhu@intel.com" <heqing.zhu@intel.com>, christian.ehrhardt@canonical.com Date: Tue, 22 Jun 2021 09:38:00 +0200 Message-ID: <9728873.ouvqlBCUrb@thomas> In-Reply-To: <DM4PR12MB5373A2ABF3069C307B2728FCA10B9@DM4PR12MB5373.namprd12.prod.outlook.com> References: <1623912892-108014-1-git-send-email-huawei.xhw@alibaba-inc.com> <DM4PR12MB5373A2ABF3069C307B2728FCA10B9@DM4PR12MB5373.namprd12.prod.outlook.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-stable] [PATCH 20.11 0/2] support both PIO and MMIO BAR for legacy virito device X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches <stable.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/stable>, <mailto:stable-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/stable/> List-Post: <mailto:stable@dpdk.org> List-Help: <mailto:stable-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/stable>, <mailto:stable-request@dpdk.org?subject=subscribe> Errors-To: stable-bounces@dpdk.org Sender: "stable" <stable-bounces@dpdk.org> 20/06/2021 17:02, Xueming(Steven) Li: > Hi Huawei, >=20 > Thanks for the backport! Here is the backport policy: > https://doc.dpdk.org/guides/contributing/stable.html#what-changes-should-= be-backported >=20 > The patch set is small enough, but it changed the public PCI component, a= little risky IMHO. And more important, it is clearly a new feature. I don't think it should be backported, otherwise it means we backport every= thing. > BTW, the patch subject seems different than upstream version, why not use= upstream patch? > We are expecting a line of "[ upstream commit <id> ] at begging of path c= ommit log. >=20 > Best Regards, > Xueming >=20 > > -----Original Message----- > > From: stable <stable-bounces@dpdk.org> On Behalf Of =E8=B0=A2=E5=8D=8E= =E4=BC=9F(=E6=AD=A4=E6=97=B6=E6=AD=A4=E5=88=BB=EF=BC=89 > > Sent: Thursday, June 17, 2021 2:55 PM > > To: stable@dpdk.org > > Cc: david.marchand@redhat.com; maxime.coquelin@redhat.com; ferruh.yigit= @intel.com; grive@u256.net; heqing.zhu@intel.com; =E8=B0=A2 > > =E5=8D=8E=E4=BC=9F(=E6=AD=A4=E6=97=B6=E6=AD=A4=E5=88=BB=EF=BC=89 <huawe= i.xhw@alibaba-inc.com> > > Subject: [dpdk-stable] [PATCH 20.11 0/2] support both PIO and MMIO BAR = for legacy virito device > >=20 > > virtio PMD assumes legacy device only supports PIO(port-mapped) BAR res= ource. This is wrong. As we need to create lots of devices, > > adn PIO resource on x86 is very limited, we expose MMIO(memory-mapped I= /O) BAR. > >=20 > > Kernel supports both PIO and MMIO BAR for legacy virtio-pci device, and= for all other pci devices. This patchset handles different type > > of BAR in the similar way. > >=20 > > In previous implementation, under igb_uio driver we get PIO address fro= m igb_uio sysfs entry; with uio_pci_generic, we get PIO > > address from /proc/ioports for x86, and for other ARCHs, we get PIO add= ress from standard PCI sysfs entry. For PIO/MMIO RW, there > > is different path for different drivers and arch. > >=20 > > All of the above is too much twisted. This patchset unifies the way to = get both PIO and MMIO address for different driver and ARCHs, > > all from standard resource attr under pci sysfs. This is most generic. > >=20 > > We distinguish PIO and MMIO by their address range like how kernel does. > > It is ugly but works. > >=20 > > huawei xie (2): > > bus/pci: use PCI standard sysfs entry to get PIO address > > bus/pci: support MMIO in PCI ioport accessors > >=20 > > drivers/bus/pci/linux/pci.c | 81 --------------- > > drivers/bus/pci/linux/pci_uio.c | 214 ++++++++++++++++++++++++++++----= =2D------- > > 2 files changed, 150 insertions(+), 145 deletions(-) > >=20 > > -- > > 1.8.3.1 >=20 >=20