From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 252CC219FC for ; Mon, 2 Feb 2026 20:22:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770063775; cv=none; b=rPW/+HgMuBko4C+4QDLmGF5NU7ITijFHyzcJLh0mPZ0CU5/DG0G+ME0ytZKc6klpRZc2bTSHgvkac310xdvh17uZ44FqgHGs2HFXhVNCoOPbuMcckHnZdXGE2ZtpQ0wKtKXrhc+dSW+72UDI/9hw2F/857+DrExTPVNWwY2ClK4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770063775; c=relaxed/simple; bh=JQfcfUUd8XuDiRHFdF+25+0jAwh/fTTxY7PfkjJ42ug=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bsh19DemAGzRsdf8GVYdvE5VtCXdLpEB0T47KtNV5Hc4k1UycTbfLtkIbUe2KVxJ+6wfixMG5LY3i6q5vwVbCpBNS2CCqKlgCxbdjxhdr+yfIx8BXfFQfJBB603nEU7wa5bI63z2omdmtv/9d5i+pJCgcwq2PhCc5rSKq2ozJcg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=ty27rvxr; arc=none smtp.client-ip=209.85.160.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="ty27rvxr" Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-502acd495feso56369171cf.2 for ; Mon, 02 Feb 2026 12:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1770063773; x=1770668573; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=A5DQQ/80oIeISv/l0flaFn2oFu98ezlgiuT9SahjHUQ=; b=ty27rvxryVFRGBJA/Yy0yu81oPFF8k7qCodFW2YdzKrJ8/y1Lp5ZvQX670mPn3qQO5 4ZHjGqP0nqTIyzla1VOssS6JFPj2lGjrykRj0RHD3w2MZuQBvbbDkx5Sv3FnHks6vkfb rLUjKE10ArykJ9WEiyxPiprRx7p7YNNxklbbxp3bmwSW1P2Sja1o7sborq1YwVkwg53L /iojLnYQEeYtp/o9uFo9j8qtA7W39n0HT/fAEwt33CyDBIZZalcho1y+Z+8N3k6c3xSd um72gi+qYcfeaTokXnfe+F8v37JAf2DpFGfwkBYgtgft7CnGkzyuGmAqH7OL0v5j5COC EzLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770063773; x=1770668573; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=A5DQQ/80oIeISv/l0flaFn2oFu98ezlgiuT9SahjHUQ=; b=vRJMLszg0701DFA9NvFXJW6mRCqwUiSKIe2MZ8o63Vc3Ji7RNOyCU7AMzrvDn5GnoF FUPzAFAytrhfXrWmhfwfVLGwgFBAjN5qp78PIOBbxpDZDvEHQpbn6Bzbc2KXBYx3nitr EL6FWi3dbJYr8uimayrYHzOM7ugqBtKeR/cPMx3hDBhExVGyx6KPtYB1VGlUdlL2zUi7 3w+syoP+2S3tg31p31+FkVumDiq1rRuHSobf4km+H3XuOwd8+GuK525/P/w4pXFLOGC0 sk9elp6dLAY9c+ucAwQ/V+db32o1z2QIRaoQQaZrcsW+FNlBVvta4mE7z99C0kpuoLgv vHeg== X-Forwarded-Encrypted: i=1; AJvYcCUm2jvgh55Mgzo4gIU/5etOd7TyMZVhq1y/cZKZXuuCXgezS5dXKhdbQ/QgTGRYHbMz2tsuhnR8tFnP88Y=@vger.kernel.org X-Gm-Message-State: AOJu0YwtPlGCto/VOn4xvP58E5eO0QUdl6CYFapj1w5BNYLrHA1VwvZS rftp69kgKW/d9GqQZEsElwiVCiY+H3oTWN/+51ZBxjy5rQFGjxbUWmQpmNhkvXdjpkM= X-Gm-Gg: AZuq6aKLQy+JvfIjvPLjA6z8c3uEZLftRCGtXDjd/uxXVE1NAy9zeuThzDfDtrTpvS4 nK3X3OwWq3kO5P8Kit4lIl4pbizxQt8D8Vt65jIQMlfLjaPKMcOVJrtd20A4w93ND+uPsBxxddD XYiTF33DvFDQpwGbbXbg1Bwf71xKDcBIgt/jySBagEfFx1fr339EeKKLrYpodj644ZNKl08T0vE d9V3RZ6IgMSQwE9DMCuokLj9Hzea8H3z8ioPbZa+mMLE+69lnyNQbPAl4pGd7mPbnKLQGktlHue Z3nkhOlsXlg5HU+1K3sOD+Y8ZCww+aS8QKOsGBmN3K9MzVzbbHRMra7niaH1BJROXzTc/tofVYH PaKv/wDlKYX4WepFjRCuW0/onMAVX2viEYwqRtJIS1O4Ndqz60BxWlV8U83jK/2c3bsFIedG7Al F+fkTB+vWiZXL/MUhvwlITXWSRJceNVKOdNpalS6IuGBK6fGlUHJphWtSfcK4+chDPPrQa9g== X-Received: by 2002:ac8:7d86:0:b0:4ee:c1a:f11f with SMTP id d75a77b69052e-505d22fa7ccmr153965971cf.84.1770063772904; Mon, 02 Feb 2026 12:22:52 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-50337ba3981sm112708281cf.16.2026.02.02.12.22.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 12:22:52 -0800 (PST) Date: Mon, 2 Feb 2026 15:22:50 -0500 From: Gregory Price To: Ira Weiny Cc: Dave Jiang , Fan Ni , Jonathan Cameron , Dan Williams , Davidlohr Bueso , Alison Schofield , Vishal Verma , linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev, linux-kernel@vger.kernel.org, Li Ming Subject: Re: [PATCH v9 00/19] DCD: Add support for Dynamic Capacity Devices (DCD) Message-ID: References: <20250413-dcd-type2-upstream-v9-0-1d4911a0b365@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250413-dcd-type2-upstream-v9-0-1d4911a0b365@intel.com> On Sun, Apr 13, 2025 at 05:52:08PM -0500, Ira Weiny wrote: > A git tree of this series can be found here: > > https://github.com/weiny2/linux-kernel/tree/dcd-v6-2025-04-13 > > This is now based on 6.15-rc2. > Extreme necro-bump for this set, but i wonder what folks opinion is on DCD support if we expose a new region control pattern ala: https://lore.kernel.org/linux-cxl/20260129210442.3951412-1-gourry@gourry.net/ The major difference would be elimination of sparse-DAX, which i know has been a concern, in favor of a per-region-driver policy on how to manage hot-add/remove events. Things I've discussed with folks in different private contexts sysram usecase: ---- echo regionN > decoder0.0/create_dc_region /* configure decoders */ echo regionN > cxl/drivers/sysram/bind tagged extents arrive and leave as a group, no sparseness extents cannot share a tag unless they arrive together e.g. set(A) & set(B) must have different tags add and expose daxN.M/uuid as the tag for collective management Can decide whether linux wants to support untagged extents cxl_sysram could choose to track and hotplug untagged extents directly without going through DAX. Partial release would be possible on a per-extent granularity in this case. ---- virtio usecase: (making some stuff up here) ---- echo regionN > decoder0.0/create_dc_region /* configure decoders */ echo regionN > cxl/drivers/virtio/bind tags are required and may imply specific VM routing may or may not use DAX under the hood extents may be tracked individually and add/removed individually if using DAX, this implies 1 device per extent. This probably requires a minimum extent size to be reasonable. Does not expose the memory as SysRAM, instead builds new interface to handle memory management message routing to/from the VMM (N_MEMORY_PRIVATE?) ---- devdax usecase (FAMFS?) ---- echo regionN > decoder0.0/create_dc_region /* configure decoders */ echo regionN > cxl/drivers/devdax/bind All sets of extents appear as new DAX devices Tags are exposed via daxN.M/uuid Tags are required otherwise you can't make sense of what that devdax represents --- Begs the question: Do we require tags as a baseline feature for all modes? No tag - no service. Heavily implied: Tags are globally unique (uuid) But I think this resolves a lot of the disparate disagreements on "what to do with tags" and how to manage sparseness - just split the policy into each individual use-case's respective driver. If a sufficiently unique use-case comes along that doesn't fit the existing categories - a new region-driver may be warranted. ~Gregory