From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f50.google.com (mail-oa1-f50.google.com [209.85.160.50]) (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 F00DC39768C for ; Tue, 16 Jun 2026 20:58:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781643487; cv=none; b=HjcZn26C2tFDPsGAjeo5X0W1ICzjijCSjaQBzWpri5U+XDlrEmt8+BtQjIhnyp/jn5SyeSRORYzE9Cfj81He6HdizvjIpoStlGDZ06G8Uj48bMLeiB/F2IHy1v3/FDLwX2o0atoPlS5Rwd7RKJixoI4dxJHONRo31B0kltnqI1o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781643487; c=relaxed/simple; bh=MUmT4WQ8gikQW/FOLoONsetD5u39tuO3VxiIsFbd268=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Yl2mhuxFtdK5btiIiLr6JSruaPxU9AA7fY8Je8TaKL0gCjBCgr/ZvZWV3hGFkyVOPO8ldxJkhZUL0znLs/P/nCMTLRb1kYatiR2tle2N0MdwXddflMtgAcoJN1LaynfAOjzwiw6qG3I1w83Bvz6+4woolstJShqPzR1jxPa2hew= 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=sD26MNSY; arc=none smtp.client-ip=209.85.160.50 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="sD26MNSY" Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-442a79dd881so1323442fac.2 for ; Tue, 16 Jun 2026 13:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781643484; x=1782248284; 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=rG4yjs4p+4H4P31U7PQCtrU7WZ2EeT+JyZMQJymeW5U=; b=sD26MNSYv9ZLMxqb1P8qI+3XPTH8FSD8SWooLHUuiCQ1s6THX8h2d9oZK9otgepkmZ L+7vw5kRLiFhMm4ptzIFb5v7SpJrr4VPdidEvKSkm3rQM7zsNu16TuLbxqzbvApfenPl Bc92wTJuZwFBksaYq+LNEJtqL8qMNArEaK/atLfBq4M5ys37Mkq3NJqEO3nDsQ3RjZnm uAZgzEI+ZYytvvmatKMEPQNndEF5C7AER/T55UeFVWLeLPCZqneogbKrZrNsOsahY1JO gpRzR0Fuf69BQoin4mtTuxrSj23kj93piIP2Ibn1fjn5ZOkwXSlYiw7aRLu3ADWyY4e5 CTyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781643484; x=1782248284; 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=rG4yjs4p+4H4P31U7PQCtrU7WZ2EeT+JyZMQJymeW5U=; b=nh14C81S8WKa//NGezYBH2Lnyf+5dug3b81w7r1nhxxPYe1+xYXd3h4+7Fb58qvtlU jVf8xZw7SmgAmoGKwQ9alv2gzJuPqbJaNrXa95hAXCwvPn6RQzPmZXq4SQqb2UE0/I7U jbFxSwFpcq+HNbehwcP0Kdu9QwFVe7PHLkEqg5o/Yqt1Utv10nIlfHwcgz9xbHWOf18v kQEGXmtlPeLxuEKreTVrQ1MIikzrmwKm2Ea3uuJC2sQREVINFotYVdsmXkXjFZIW3FKe 82+exUIv6UNckSdRQWvbehAuRTS7oRBLRfyEpYeH+BXorKKaPqGP+uGGj6Zb5Y94jai8 zKyw== X-Forwarded-Encrypted: i=1; AFNElJ880lRX4ShW93QJqeo+m4ttxNV/NP+R06i4AmZYE/6dswkZPsrx3N4uxEgncn3G5bsmE+H8o/U=@vger.kernel.org X-Gm-Message-State: AOJu0YwzJX0aoCo5KbnefC1NnPc2Z+eDZEN1jD+pyengMXD5g5H24gsP WeLsJ2wzk0ur8ZQTXzt4zIAFNoDJcY2WdTjfMYZ4LrGBAsV8aNd58o/F X-Gm-Gg: Acq92OEoJcPAb6chI8aBjkuNqN9lniJlHFpeLRp/2CEOCkEoJqRrWL7KA3KXjg97bVt uqKgwTS19xufyJynQinVR/TecA7eaPiOJkJmGLNwARcZAtZamTbgI/77XJXjt9uwQnwOitrLOb6 FNrEn8V/2F/hKGO9ut1o3nwyI+vRppQ6xtrUDTW/0XBYF4DXCYEOi8/92AZAUdkRcO7BZXQVtsq YIOP9gcdIv/AW5rCnU8IQ2icC1hnRAjcThG6X6rKJR6rfIJYJt/FXwWkDn1ZOqTsjU/gBCAo3Lu fJBGDOafuhHkLYWItxVIbieLHupxl9ac/1XU0GJ1XjTLYKU98Su2GNw4rR0onMwhzePekK7aFlz jWGFbbCND9QqMgldEs/FUeb/yEPNbYZjOXKb+BcgDAKTs0/m5mscTPpXecnJmJHiaBXDh6RChT9 ZY2Y6Fg1u9qEQUDy0zjHHpq/iM7tBUo8FlBCx34NFTUmc= X-Received: by 2002:a05:6808:2f0f:b0:479:f7e7:4a81 with SMTP id 5614622812f47-489425d7d4cmr1016628b6e.0.1781643483758; Tue, 16 Jun 2026 13:58:03 -0700 (PDT) Received: from devvm29614.prn0.facebook.com ([2a03:2880:ff:8::]) by smtp.gmail.com with ESMTPSA id 5614622812f47-4875df7fc36sm5099675b6e.9.2026.06.16.13.57.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2026 13:58:03 -0700 (PDT) Date: Tue, 16 Jun 2026 13:57:49 -0700 From: Bobby Eshleman To: "Kasireddy, Vivek" Cc: Donald Hunter , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Andrew Lunn , Gerd Hoffmann , Sumit Semwal , Christian =?iso-8859-1?Q?K=F6nig?= , Shuah Khan , Jason Gunthorpe , "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 v2 2/4] udmabuf: emit one sg entry per pinned folio Message-ID: References: <20260611-tcpdm-large-niovs-v2-0-ee2bf15e7523@meta.com> <20260611-tcpdm-large-niovs-v2-2-ee2bf15e7523@meta.com> Precedence: bulk X-Mailing-List: netdev@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: On Tue, Jun 16, 2026 at 06:04:03AM +0000, Kasireddy, Vivek wrote: > Adding Jason to this discussion. > > Hi Bobby, > > > Subject: [PATCH net-next v2 2/4] udmabuf: emit one sg entry per pinned > > folio > > > > 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 > We have recently merged a patch (that will make it into 7.2) from Jason that > replaced sg_set_folio() with sg_alloc_table_from_pages() in udmabuf driver: > https://gitlab.freedesktop.org/drm/tip/-/commit/5bf888673e0dda5a53220fa0c4956271a46c353c > > Since you are relying on sg_set_folio(), the core argument against its usage > in udmabuf is that it doesn't work well with offsets > PAGE_SIZE, resulting > in a malformed scatterlist. Not sure if this can be fixed easily. > > > represent large pages (as is for MFD_HUGETLB), each sg entry is a large > > page. Normal PAGE_SIZE sg tables are unchanged. > > > > This is helpful for importers like net/core/devmem that expect dmabuf sg > IMO, udmabuf needs to detect whether importers can handle segments that > are > PAGE_SIZE and set the entries appropriately. Please look into how the > GPU drivers and other dmabuf exporters/importers handle this situation, so > that we can adopt best practices to address this issue. > > Thanks, > Vivek Hey Vivek, It sounds looks like that patch might solve my problem. I'll apply and troubleshoot from there. Thanks! Best, Bobby > > > entries to be size and length aligned. Prior to this patch udmabuf > > handed over one PAGE_SIZE sg entry per page, so devmem only saw > > PAGE_SIZE chunks regardless of the underlying folio size. > > > > dma_map_sgtable() does not always merge contiguous pages for us, so we > > do this internally before exporting. > > > > Signed-off-by: Bobby Eshleman > > --- > > drivers/dma-buf/udmabuf.c | 52 > > ++++++++++++++++++++++++++++++++++++++++++----- > > 1 file changed, 47 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > > index 94b8ecb892bb..9b751dd98b12 100644 > > --- a/drivers/dma-buf/udmabuf.c > > +++ b/drivers/dma-buf/udmabuf.c > > @@ -141,26 +141,68 @@ 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. > > + * > > + * Coalescing folios into a single sg entry up front lets importers actually > > + * see large chunks. We can't rely on dma_map_sgtable() to do this for us > > as > > + * the dma_map_direct() path preserves the input scatterlist lengths > > verbatim. > > + */ > > +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 >