From: "Dutt, Sudeep" <sudeep.dutt@intel.com>
To: "sherry.sun@nxp.com" <sherry.sun@nxp.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"fugang.duan@nxp.com" <fugang.duan@nxp.com>
Cc: "linux-imx@nxp.com" <linux-imx@nxp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"hch@infradead.org" <hch@infradead.org>,
"kishon@ti.com" <kishon@ti.com>,
"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
"Dutt, Sudeep" <sudeep.dutt@intel.com>,
"Dixit, Ashutosh" <ashutosh.dixit@intel.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"arnd@arndb.de" <arnd@arndb.de>,
"vincent.whitchurch@axis.com" <vincent.whitchurch@axis.com>
Subject: Re: [EXT] Re: [PATCH V5 0/2] Change vring space from nomal memory to dma coherent memory
Date: Thu, 29 Oct 2020 02:03:00 +0000 [thread overview]
Message-ID: <8e6da51572b8e64cf89a1e76f06089e8fa181bc9.camel@intel.com> (raw)
In-Reply-To: <VI1PR04MB49608E4DE25847CC3019A40092140@VI1PR04MB4960.eurprd04.prod.outlook.com>
On Thu, 2020-10-29 at 01:51 +0000, Sherry Sun wrote:
> Hi Greg,
>
> > Subject: Re: [EXT] Re: [PATCH V5 0/2] Change vring space from nomal
> > memory to dma coherent memory
> >
> > On Wed, Oct 28, 2020 at 03:11:15PM +0000, Andy Duan wrote:
> > > From: Greg KH <gregkh@linuxfoundation.org> Sent: Wednesday,
> > > October
> > > 28, 2020 7:14 PM
> > > > On Wed, Oct 28, 2020 at 10:17:39AM +0000, Andy Duan wrote:
> > > > > From: Greg KH <gregkh@linuxfoundation.org> Sent: Wednesday,
> > > > > October 28, 2020 3:07 PM
> > > > > > On Wed, Oct 28, 2020 at 06:05:28AM +0000, Sherry Sun wrote:
> > > > > > > Hi Greg,
> > > > > > >
> > > > > > > > Subject: Re: [PATCH V5 0/2] Change vring space from
> > > > > > > > nomal
> > > > > > > > memory to dma coherent memory
> > > > > > > >
> > > > > > > > On Wed, Oct 28, 2020 at 10:03:03AM +0800, Sherry Sun
> > > > > > > > wrote:
> > > > > > > > > Changes in V5:
> > > > > > > > > 1. Reorganize the vop_mmap function code in patch 1,
> > > > > > > > > which
> > > > > > > > > is done by
> > > > > > > >
> > > > > > > > Christoph.
> > > > > > > > > 2. Completely remove the unnecessary code related to
> > > > > > > > > reassign the used ring for card in patch 2.
> > > > > > > > >
> > > > > > > > > The original vop driver only supports dma coherent
> > > > > > > > > device,
> > > > > > > > > as it allocates and maps vring by _get_free_pages and
> > > > > > > > > dma_map_single, but not use
> > > > > > > > > dma_sync_single_for_cpu/device
> > > > > > > > > to sync the updates of device_page/vring between EP
> > > > > > > > > and
> > > > > > > > > RC, which will cause memory synchronization problem
> > > > > > > > > for
> > > > > > > > > device don't support
> > > >
> > > > hardware dma coherent.
> > > > > > > > >
> > > > > > > > > And allocate vrings use dma_alloc_coherent is a
> > > > > > > > > common way
> > > > > > > > > in kernel, as the memory interacted between two
> > > > > > > > > systems
> > > > > > > > > should use consistent memory to avoid caching
> > > > > > > > > effects. So
> > > > > > > > > here add noncoherent platform
> > > > > > > >
> > > > > > > > support for vop driver.
> > > > > > > > > Also add some related dma changes to make sure
> > > > > > > > > noncoherent
> > > > > > > > > platform works well.
> > > > > > > > >
> > > > > > > > > Sherry Sun (2):
> > > > > > > > > misc: vop: change the way of allocating vrings and
> > > > > > > > > device page
> > > > > > > > > misc: vop: do not allocate and reassign the used
> > > > > > > > > ring
> > > > > > > > >
> > > > > > > > > drivers/misc/mic/bus/vop_bus.h | 2 +
> > > > > > > > > drivers/misc/mic/host/mic_boot.c | 9 ++
> > > > > > > > > drivers/misc/mic/host/mic_main.c | 43 ++------
> > > > > > > > > drivers/misc/mic/vop/vop_debugfs.c | 4 -
> > > > > > > > > drivers/misc/mic/vop/vop_main.c | 70 +--------
> > > > > > > > > ---
> > > > > > > > > drivers/misc/mic/vop/vop_vringh.c | 166 ++++++++++-
> > > > > > > > > ------------
> >
> > ------
> > > > > > > > > include/uapi/linux/mic_common.h | 9 +-
> > > > > > > > > 7 files changed, 85 insertions(+), 218 deletions(-)
> > > > > > > >
> > > > > > > > Have you all seen:
> > > > > > > >
> > > > > > > >
https://eur01.safelinks.protection.outlook.com/?url=https%3A
> > > > > > > > %2F%25
> > > > > > > > 25
> > > > > > > >
> >
> > 2Flore.kernel.org%2Fr%2F8c1443136563de34699d2c084df478181c205db4.16
> > > > > > > >
> >
> > 03854416.git.sudeep.dutt%40intel.com&data=04%7C01%7Csherry.sun%
> > > > > > > >
> >
> > 40nxp.com%7Cc19c987667434969847e08d87b0685e8%7C686ea1d3bc2b4c6f
> > > > > > > >
> >
> > a92cd99c5c301635%7C0%7C0%7C637394615238940323%7CUnknown%7CTW
> > > > > > > >
> >
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > > > > > > >
> >
> > VCI6Mn0%3D%7C1000&sdata=Zq%2FtHWTq%2BuIVBYXFGoeBmq0JJzYd
> > > > > > > > 9zDyv4NVN4TpC%2FU%3D&reserved=0
> > > > > > > >
> > > > > > > > Looks like this code is asking to just be deleted, is
> > > > > > > > that ok with you?
> > > > > > >
> > > > > > > Yes, I saw that patch. I'm ok with it.
> > > > > >
> > > > > > Great, can you please provide a "Reviewed-by:" or "Acked-
> > > > > > by:" for it?
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > greg k-h
> > > > >
> > > > > Sherry took much effort on the features support on i.MX
> > > > > series
> > > > > like
> > > >
> > > > i.MX8QM/i.MX8QXP/i.MX8MM.
> > > > >
> > > > > Now it is a pity to delete the vop code.
> > > > >
> > > > > One question,
> > > > > can we resubmit vop code by clean up, now only for i.MX
> > > > > series as
> > > > > Dutt's
> > > >
> > > > suggestion ?
Resubmitting the VOP code with cleanups tailored for i.MX makes sense
to me.
> > > > > Or we have to drop the design and switch to select other
> > > > > solutions ?
> > >
> > > Okay, we plan to switch to NTB solution.
> >
> > What is a "NTB solution" exactly?
>
> The driver located at drivers/ntb/, it also can setup a point-to-
> point PCI-E bus connecting between two systems.
> But we haven't got a deep look of this driver yet, so we are not sure
> whether it can replace the vop framework.
>
> >
> > >
> > > > If this whole subsystem is being deleted because it is not used
> > > > and
> > > > never shipped, yes, please use a different solution.
> > > >
> > > > I don't understand why you were trying to piggy-back on this
> > > > codebase if the hardware was totally different, for some reason
> > > > I
> > > > thought this was the same hardware. What exactly is this?
> > >
> > > Not the whole codebase, just the vop framework.
> >
> > That didn't answer the question at all, what are you all trying to
> > do here, with
> > what hardware, that the VOP code seemed like a good fit?
>
> Vop is a common framework which is independent of the Intel MIC
> hardware.
> We planed to reuse vop framework on two arm64 architecture devices,
> to setup the connection between two systems based on virtio over
> PCIE.
Yes, we wanted Virtio Over PCIe (VOP) to be independent of the hardware
as much as possible. It did end up under the mic/ driver subsystem
though so it would be good to attempt placing it in a generic folder
which is not tied to a specific hardware layer this time around.
Regards,
Sudeep Dutt
next prev parent reply other threads:[~2020-10-29 2:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-28 2:03 [PATCH V5 0/2] Change vring space from nomal memory to dma coherent memory Sherry Sun
2020-10-28 2:03 ` [PATCH V5 1/2] misc: vop: change the way of allocating vrings and device page Sherry Sun
2020-10-28 2:03 ` [PATCH V5 2/2] misc: vop: do not allocate and reassign the used ring Sherry Sun
2020-10-28 5:58 ` [PATCH V5 0/2] Change vring space from nomal memory to dma coherent memory Greg KH
2020-10-28 6:05 ` Sherry Sun
2020-10-28 7:07 ` Greg KH
2020-10-28 7:11 ` Sherry Sun
2020-10-28 10:17 ` [EXT] " Andy Duan
2020-10-28 11:13 ` Greg KH
2020-10-28 15:11 ` Andy Duan
2020-10-28 15:42 ` Greg KH
2020-10-29 1:51 ` Sherry Sun
2020-10-29 2:03 ` Dutt, Sudeep [this message]
2020-10-28 9:09 ` Vincent Whitchurch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8e6da51572b8e64cf89a1e76f06089e8fa181bc9.camel@intel.com \
--to=sudeep.dutt@intel.com \
--cc=arnd@arndb.de \
--cc=ashutosh.dixit@intel.com \
--cc=fugang.duan@nxp.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=kishon@ti.com \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=sherry.sun@nxp.com \
--cc=vincent.whitchurch@axis.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).