From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (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 A960F3E5A36 for ; Fri, 5 Jun 2026 18:44:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780685044; cv=none; b=fHB02ZmUl5LgvvjFVJQ8Xy5u+LORQGA2WHx8VCGDl1mkPqLxw4k8dZ3eALMg8QuN+Ehhr+/E8/AyvIvki5XCBE7cpucNv000bxh3RZpaTKnQ2sTV4FxXuIu6L9h2JJhlpYx0RqQ9jSEKBnGSjItWADuwzPCmE44rShnF3jqEvlc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780685044; c=relaxed/simple; bh=jptZDNz6y+ZlDE7Z2+X6vsmedleZEP/GgTVJ8MIVCV8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mQQzAq/AodIZ4GMJzE3oQXJf7hxaHNK8EMkVBeCU1NHV0Ah7sx7NRQWOa0dlprdrxM/6o5WtQEcPomWWGtPAhSvubt+/wbFxtLMpFRsSz0WP3oi2STYQIOacsEMYRkebMptmDhZ097NRF41S+8jKjB/leybMpHe183XCNrTRFQk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=qUh+nclv; arc=none smtp.client-ip=209.85.214.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qUh+nclv" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-2c0c3546924so15614665ad.3 for ; Fri, 05 Jun 2026 11:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780685043; x=1781289843; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=VmToUT+A6qp8UgJ/VhXar74M6fIQJS1C/pR1f1V3ExQ=; b=qUh+nclvgiHYKzX3b/kDCvzXL/O6elBYjQ0Y2BtzxFxe6Q7xZG239BaIL2RKL8XZzL vpWhSBYMKiVYN/Z77EnauJ1L/pZIRV9cnLxjZav6YlpKNmSLAoqsL5a63WDyRdf2HZ5Z SDorrWNZX/kTLWwY5g0zdRVpmLfo2EH/+B6Qvag5sHDi/7gmLd6ARvd71WRiRVjPhgYJ f6yxBKbfC+XzSkRLourk6ogx2MDz8T70pAWO1IIrzJNsSbbQ7w+oN5p8MK0feSaZP7JQ WcNCA+aT8d9qbLYSx20PhXjlpUFL0y2DJrBbI0O1sy4YfyojDK0hkrTvmVaCaOrqVUgH ZWIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780685043; x=1781289843; h=in-reply-to:content-transfer-encoding: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=VmToUT+A6qp8UgJ/VhXar74M6fIQJS1C/pR1f1V3ExQ=; b=pHkywOSi8ZMhknIL4eg7lZsb5bvf+eK5tfJtpmYGZoA9ggXuLEyso3e1jx/9TjezNL jj5SR9fRfVsJEikwxBQUnleMsq62/pUrS9jkGzP76NpYn0og1zDLL8zL36ahidr4pMDA gOQChl8crzXvOP6JSKEBf/vrej9hljS3YGyZphLqzQu1yNorDW/N7Wd0d/5EouXmwYDA uUZWQI39IhJ/ovEwCjKsasDxNwKyn2JV5/2IteZg/kov9IBP1xN3biye/jX7bC+LjqVX lb4Miim1vmqtvXbk8X9nnEmyV4E6LAc6IVU9R/M2PJ++s1e/bylDbsVMBifASdmVOjSZ pCgA== X-Forwarded-Encrypted: i=1; AFNElJ8I1y2Lq/ubWaDlERtIGxyaBu78Ie8raRL3XVn+U8PFTvhrIYmEYv+Hc0tR6+0nPGQx0yyOLx6bBoCP19A=@vger.kernel.org X-Gm-Message-State: AOJu0YyY8Dv0RBTxwoxxwqTVo65wQN8D22H/fJHyot7W6YIvXLa/E/xf Mg4iAsLgFfHgB9bAiShPY+wqG5k7Q4C+E+bozWJlczqhY61yq3d1M0ld X-Gm-Gg: Acq92OGYbb5FuJu1puXozH3XN1ePmm9Q0G+tjAQpBjEYYeM4LP3rwPxlQVvctX2WGfK cK5ucFYlbR9yAvRG5Xur/NJO1SiCjUhTe6KZnpoI4yMbHHKiZy24F69seY4vjRHI3Y+kEoahBWY Bq387yTKIRnj2C/Xv4sqIp79yJYCkTDcX15NOUgdCypWdxpAERh7xB2l8SKEsfq8q4Opkmrhhhk kOiO0XBlVybs/qVvgYrWhWtBmaMyo7rJRs/PVKIT9t7dfHGtRdPgFkHg66Xedu37Xqez8myMXVB fBuNFrpkqCuCs/rygCkZVdapSgxR8eIceney9nNgrIV4JHQzu5JhKcu7/5Gnaa/TVc1LK2ThXZi Uc8s8vdOcRe+MMCiz/YM71Zt7Gza6SUeUVJc8UgSl4tDElfycSJ8P37dfJEJzBuf295nSPM4nyr xx9wyGJqOePtS9d2ZGvUBJyWL7bP2cxIXDz53wvlCmwjTxKe1JJWK9Wlw= X-Received: by 2002:a17:903:18c:b0:2c0:e5ee:f56c with SMTP id d9443c01a7336-2c1e881fefemr54368775ad.20.1780685042865; Fri, 05 Jun 2026 11:44:02 -0700 (PDT) Received: from devvm29614.prn0.facebook.com ([2a03:2880:ff:58::]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c1663981basm96908105ad.67.2026.06.05.11.44.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2026 11:44:02 -0700 (PDT) Date: Fri, 5 Jun 2026 11:44:00 -0700 From: Bobby Eshleman To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Donald Hunter , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Andrew Lunn , Gerd Hoffmann , Vivek Kasireddy , Sumit Semwal , Shuah Khan , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-kselftest@vger.kernel.org, sdf@fomichev.me, razor@blackwall.org, daniel@iogearbox.net, almasrymina@google.com, matttbe@kernel.org, skhawaja@google.com, dw@davidwei.uk, Bobby Eshleman Subject: Re: [PATCH net-next 2/4] udmabuf: emit one sg entry per pinned folio Message-ID: References: <20260603-tcpdm-large-niovs-v1-0-f37a4ac6726c@meta.com> <20260603-tcpdm-large-niovs-v1-2-f37a4ac6726c@meta.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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, Jun 05, 2026 at 11:30:07AM +0200, Christian König wrote: > On 6/4/26 02:42, Bobby Eshleman wrote: > > From: Bobby Eshleman > > > > get_sg_table() emitted one PAGE_SIZE sg entry per page even when the > > underlying folio was larger. > > > > Instead, walk folios[] and emit one sg entry per folio. When folios > > represent large pages (as is for MFD_HUGETLB), each sg entry is a large > > page. Normal PAGE_SIZE sg tables are unchanged. > > > > Required by net/core/devmem to support rx-buf-size > PAGE_SIZE with > > udmabuf. > > That doesn't explain why this is required. Sure, can definitely add. Devmem currently requires dmabuf sg entries to be length and size aligned when it allocates niovs for NIC page pools. Though udmabuf is not violating any dmabuf contract by emitting PAGE_SIZE entries and the above restriction is probably more a shortfalling of devmem, by emitting a single entry per folio this patch allows udmabuf to be used by devmem for large pages. > > Please note that accessing the pages/folio of an sg-table returned by DMA-buf is illegal and strictly forbidden! > > Regards, > Christian. It seems both devmem and io_uring zcrx at least introspect through to the sg-table to build NIC page pools (not accessing the memory itself, however). Is there a better way? Best, Bobby > > > Signed-off-by: Bobby Eshleman > > --- > > drivers/dma-buf/udmabuf.c | 47 ++++++++++++++++++++++++++++++++++++++++++----- > > 1 file changed, 42 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > > index 94b8ecb892bb..f28dd3788ada 100644 > > --- a/drivers/dma-buf/udmabuf.c > > +++ b/drivers/dma-buf/udmabuf.c > > @@ -141,26 +141,63 @@ static void vunmap_udmabuf(struct dma_buf *buf, struct iosys_map *map) > > vm_unmap_ram(map->vaddr, ubuf->pagecount); > > } > > > > +/* Return the number of contiguous pages backed by the folio at @i. > > + * A udmabuf may map only part of a folio, or reference the same folio > > + * in multiple non-contiguous runs, so folio_nr_pages() can't be used. > > + */ > > +static pgoff_t udmabuf_folio_nr_pages(struct udmabuf *ubuf, pgoff_t i) > > +{ > > + struct folio *f = ubuf->folios[i]; > > + pgoff_t j; > > + > > + for (j = 1; i + j < ubuf->pagecount; j++) { > > + if (ubuf->folios[i + j] != f) > > + break; > > + /* Same folio, but not a sequential offset within it. */ > > + if (ubuf->offsets[i + j] != ubuf->offsets[i] + j * PAGE_SIZE) > > + break; > > + } > > + return j; > > +} > > + > > +/* Count the contiguous folio runs in @ubuf, one sg entry per run. */ > > +static unsigned int udmabuf_sg_nents(struct udmabuf *ubuf) > > +{ > > + unsigned int nents = 0; > > + pgoff_t i; > > + > > + for (i = 0; i < ubuf->pagecount; i += udmabuf_folio_nr_pages(ubuf, i)) > > + nents++; > > + return nents; > > +} > > + > > static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, > > enum dma_data_direction direction) > > { > > struct udmabuf *ubuf = buf->priv; > > - struct sg_table *sg; > > struct scatterlist *sgl; > > - unsigned int i = 0; > > + struct sg_table *sg; > > + pgoff_t i, run; > > + unsigned int nents; > > int ret; > > > > + nents = udmabuf_sg_nents(ubuf); > > + > > sg = kzalloc_obj(*sg); > > if (!sg) > > return ERR_PTR(-ENOMEM); > > > > - ret = sg_alloc_table(sg, ubuf->pagecount, GFP_KERNEL); > > + ret = sg_alloc_table(sg, nents, GFP_KERNEL); > > if (ret < 0) > > goto err_alloc; > > > > - for_each_sg(sg->sgl, sgl, ubuf->pagecount, i) > > - sg_set_folio(sgl, ubuf->folios[i], PAGE_SIZE, > > + sgl = sg->sgl; > > + for (i = 0; i < ubuf->pagecount; i += run) { > > + run = udmabuf_folio_nr_pages(ubuf, i); > > + sg_set_folio(sgl, ubuf->folios[i], run << PAGE_SHIFT, > > ubuf->offsets[i]); > > + sgl = sg_next(sgl); > > + } > > > > ret = dma_map_sgtable(dev, sg, direction, 0); > > if (ret < 0) > > > > -- > > 2.53.0-Meta > > >