From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CC27BC4332F for ; Mon, 13 Nov 2023 04:54:33 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CD96710E10A; Mon, 13 Nov 2023 04:54:32 +0000 (UTC) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6EBB310E10A for ; Mon, 13 Nov 2023 04:54:30 +0000 (UTC) Received: by mail-ua1-x933.google.com with SMTP id a1e0cc1a2514c-7b6e1770519so899009241.2 for ; Sun, 12 Nov 2023 20:54:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699851269; x=1700456069; darn=lists.freedesktop.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ulZUsxBjy/DYiq3mQzgGs9wuxEBLqLXZ1LrWDxA7qvo=; b=iyLLnDKrGLhBzcCalSEx4B2vyLkI1cutBR76whdP6DIQKyYS5W+Z7e1LMK0fJg481Y Gr5nIuMHLof58Queg1YUXMegICgFAETvESAGVD7On4BqqsXqaCST/5qgBlkocBLu2iZz 6sImY40qPT8uChSg7rqm6brsOldh/3/ObyWmzq3h18JtZEr7l0PYobv/WpYXllrkfMmo WNl29UG5MiJMAvBmbYAw1RIfI8CRVWO5qif/v5vyRYYsfh/XLjpFMxTLMHa9ge6rD1ix HLEvlG3sgoah6gLfE6OyzDAgsVB2wO2+9jI//6/68xTQJqYk800/aomb39XBoxeh2dXi 5eyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699851269; x=1700456069; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ulZUsxBjy/DYiq3mQzgGs9wuxEBLqLXZ1LrWDxA7qvo=; b=ccJSyI4Bi4UjKtp4pA00bGbTzg785bJ62mMGF1/+LBhuqxZXyrZTFDVkyCpagDvreO V+KQksKTH7EDUbS8FP9zaObl+SoXoEKDXJqXkiV/msa5QSn2JdXBcuTxdMXx2fhb3sZm 6YTucLAXUqvQJ8qcTpwSuTFrwCCAuncd1BxEm/tdRt6JiWkTzW/ttgX6/AHIBov4wxSN bB8ImkzLB7Kqzyl9uFuIV8CpQSF2qXps0rmhT06FS1hYarU6Zv3w8aZFWZkM803ag1ds buLCWG/xNP4MlER8vTy5GLlEp/q6+MW19mmIhOGEDsz5SVqJrZfZDYi/muAJOkvuI3Lh wBuw== X-Gm-Message-State: AOJu0Yzz2K0IreFC5meF6jAk+BlV8/Eyv7PROKKNl1MYxm753AVJl2hB IXHO/JzTxGM0q0SYRQeQ343rlk03wPkVBjaN4W3p0Q== X-Google-Smtp-Source: AGHT+IGBugYmcwQCmYo3XhrW53vx7SnsNtkGBEWopCzRD+dofX6GN+L1OxYsj2HtZsztRRSBDJnHEIwyfhi7gc94JeA= X-Received: by 2002:a67:ab0d:0:b0:45f:4e67:4420 with SMTP id u13-20020a67ab0d000000b0045f4e674420mr2062262vse.2.1699851269262; Sun, 12 Nov 2023 20:54:29 -0800 (PST) MIME-Version: 1.0 References: <20231106024413.2801438-1-almasrymina@google.com> <20231106024413.2801438-7-almasrymina@google.com> <20231110151622.2f45f618@kernel.org> In-Reply-To: <20231110151622.2f45f618@kernel.org> From: Mina Almasry Date: Sun, 12 Nov 2023 20:54:18 -0800 Message-ID: Subject: Re: [RFC PATCH v3 06/12] memory-provider: dmabuf devmem memory provider To: Jakub Kicinski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kaiyuan Zhang , dri-devel@lists.freedesktop.org, Eric Dumazet , linux-kselftest@vger.kernel.org, Shuah Khan , Sumit Semwal , linux-arch@vger.kernel.org, Willem de Bruijn , Jeroen de Borst , Paolo Abeni , linux-media@vger.kernel.org, Jesper Dangaard Brouer , Arnd Bergmann , linaro-mm-sig@lists.linaro.org, Shakeel Butt , Willem de Bruijn , netdev@vger.kernel.org, David Ahern , Ilias Apalodimas , linux-kernel@vger.kernel.org, "David S. Miller" , Praveen Kaligineedi , =?UTF-8?Q?Christian_K=C3=B6nig?= Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Nov 10, 2023 at 3:16=E2=80=AFPM Jakub Kicinski wr= ote: > > On Sun, 5 Nov 2023 18:44:05 -0800 Mina Almasry wrote: > > +static int mp_dmabuf_devmem_init(struct page_pool *pool) > > +{ > > + struct netdev_dmabuf_binding *binding =3D pool->mp_priv; > > + > > + if (!binding) > > + return -EINVAL; > > + > > + if (pool->p.flags & PP_FLAG_DMA_MAP || > > + pool->p.flags & PP_FLAG_DMA_SYNC_DEV) > > + return -EOPNOTSUPP; > > This looks backwards, we should _force_ the driver to use the dma > mapping built into the page pool APIs, to isolate the driver from > how the DMA addr actually gets obtained. Right? > > Maybe seeing driver patches would illuminate. The full tree with driver patches is here: https://github.com/torvalds/linux/compare/master...mina:linux:tcpdevmem-v3 This is probably the most relevant patch, it implements POC page-pool support into GVE + devmem support: https://github.com/torvalds/linux/commit/3c27aa21eb3374f2f1677ece6258f046da= 234443 But, to answer your question, yes, this is a mistake. devmem doesn't need to be mapped, which is why I disabled the flag. Actually what should happen is like you said, we should enforce that PP_FLAG_DMA_MAP is on, and have it be a no-op, so the driver doesn't try to map the devmem on its own. --=20 Thanks, Mina