From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Gregory Price <gregory.price@memverge.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
<linux-cxl@vger.kernel.org>, <navneet.singh@intel.com>,
<ira.weiny@intel.com>
Subject: Re: "release early" preview of DCD enabling
Date: Fri, 14 Apr 2023 13:04:14 +0100 [thread overview]
Message-ID: <20230414130414.00007c88@Huawei.com> (raw)
In-Reply-To: <ZDWVkJKVThJzhMzM@memverge.com>
On Tue, 11 Apr 2023 13:14:56 -0400
Gregory Price <gregory.price@memverge.com> wrote:
> On Sun, Apr 09, 2023 at 12:07:36AM -0700, Dan Williams wrote:
> > Here is an early draft of the DCD work that Navneet has spearheaded.
> > Given the interest level I thought it best to do the remaining
> > development and refinement of the functionality in the open. For now
> > this is just a git branch that will become a patchkit on the mailing
> > list in a few weeks.
> >
> > Questions are welcome, but I do not recommend a formal review until the
> > patches hit the mailing list.
> >
> > This has had some checkout on an internal functional model, I expect
> > QEMU and/or cxl_test grows an emulation of DCD before this patchkit is
> > committed for mainline.
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl.git/log/?h=for-6.5/dcd-preview
>
> Awesome!
>
> for the QEMU folks, has anyone be actively working on a DCD device? I
> was going to start looking at it, but didn't want to duplicate work.
Not that I know of. Was thinking I might hack some of it together, but
not gotten to it yet.
For and end goal I think we want:
a) Add all the config stuff for DCD regions - perhaps hardcode one initially.
b) Device that generates DCD events (don't care on interface to make them happen but maybe start
with QMP similar to injection interfaces).
c) Device that maps the DCD extents through to doing the correct read and write behavior for
reads that aren't in DCD extents.
d) A standards based way to poke the FM-API. Tunneling and / or MCTP CCIs
Can probably split this up though so if multiple people are hacking on it they don't clash.
(a) and (b) needed to do anything useful with kernel side.
(c) needed for testing long term, but don't care initially.
(d) mostly separable - needed for a 'nice' test setup but not for basic functionality testing.
If you want to take a look at (a) and (b) and maybe (c) that would be great.
There is lots of independent stuff to do for (d) so maybe I'll focus on that in short term?
How's that work for you?
Jonathan
>
> ~Gregory
next prev parent reply other threads:[~2023-04-14 12:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-09 7:07 "release early" preview of DCD enabling Dan Williams
2023-04-11 17:14 ` Gregory Price
2023-04-14 12:04 ` Jonathan Cameron [this message]
2023-04-17 16:41 ` Fan Ni
2023-04-21 21:28 ` nifan
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=20230414130414.00007c88@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=dan.j.williams@intel.com \
--cc=gregory.price@memverge.com \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=navneet.singh@intel.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