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