From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f51.google.com (mail-oa1-f51.google.com [209.85.160.51]) (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 EFFE637EFEB for ; Tue, 16 Jun 2026 20:58:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781643487; cv=none; b=pj9Ui0VDXeRN5sWbfjx0MDn+URwnyJ8lVoGHg/OtftJR18J1o0b0br4LICRiUrUZCMBgg8ylVbJnU5XRcFJyJU4dxlnSErebIjjg6aNT+zByAhiEoDzAsAMEfnLxwGdwJ7pYJBPc7WEaEu0R/By/HZzcU/Wzi+egPUrG1AswvoQ= 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.51 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-f51.google.com with SMTP id 586e51a60fabf-442a79dd881so1323441fac.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=WEixQXcqiIb1mTrKfo/pwOH1m21bxFe9993tPYsBY6y9LG7/x79f0ftPKYubS01BLW SJIcgudVpS0zUrnJBNu25yonXeNrdIbbxCDNQCrjS/WcVBiVhbe4nFYL5iYAd05Ni3lc JqFMh9NPU7af97txE+LeovbTlzrjQlYmR3R72CbL9F0VHpP40RjwM1q1Kkzwh4XSIAC6 Cv7FxSAPY4wZbyJDjHQFqB1uJwKzHIf41O6fnIUhv7wW9ARe0JJTaMZTBmQJFpv/N3ra Ja6mnXP00pmm47grwd5rFCSxVR3XUGB9DTJx0/6uMKa/p7ztBubii5WDqa5d0ihTtAUA Tzmw== X-Forwarded-Encrypted: i=1; AFNElJ8hufmrh+mC7yGEkFeyKiiLXVXghQ8zW6Vu1Yxw8mTHYZnjYeiLDR6e3W9pNz2G2k3oZdmG+W46a8HCibg=@vger.kernel.org X-Gm-Message-State: AOJu0YwQtQTfUtQLHJoT5ayWLM4SaqiS2nbRWOsv3E3WqsgayvxbRvIg ONx4WrJdjAUGmF9Zs3xHWWpioVaiFby61j/MhXj8xi4FYhPQ27XxJZ/1 X-Gm-Gg: Acq92OHkrVKpZS0SlsL7g5CqvjgOCo6a3tC+UpHB+S/Qp1+6Aq2j1rNrThZgafuROkc FpZo3Ox0+ndg2JUbJy8FvmkZNCjQzPLB9hJKOX2+UKhVuxWfwRZkW8vqABu/mF1sSwZeaS/E5oV 4r9P0/eifVQyh5fvBKAffzyrm484FSkREcCe3Szfl3SOaEVn43J0SCUAVFp8U5pYn/WBVoMkE0E UVYL85dy0TFX63eYDabEpzQTGXJ0rc9SjSM2XGB3UaZx0e4tmS7OY3yVSuceMH/EB9UsGrTH18n y6BYgO7gPbPBQWh14d64T8ZQYudZdaNYIjtJKO+oXqbI5JjcyIl9+JKRUsNNuq1bCrrOSArRyJh t0oe1/KvX45O3BvuKY6x8GmWlXm2x8ZDnfCbpAK0ouXl5zodoJRIzhbHD2JL3RPvyU6dtLxhY5x MCJu1HCCJ6VG48DS0wnmn2wFIboZ+izrv0LqQiqKLuNz8= 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: 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: 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 >