From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (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 8D22D10EC for ; Fri, 15 Dec 2023 02:11:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--shakeelb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="S4ihFpEG" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-1d36403e815so1926135ad.0 for ; Thu, 14 Dec 2023 18:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1702606276; x=1703211076; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=Hn2u3ohnyQZ77hNqSlm/EvFnLZDsF+Ox+1yQ+iYOeGU=; b=S4ihFpEGaGASqDXTKfIcJabS3ty2QxSafop+BYrFlYS3RFOOEXc4/eKAaKZjzU4WWh DRXxnvX7n3k/XvfTLWvDbDI7EuR8uo9fqmsBj1c8yy9c253JKQ6y5iHHgfx2WBSiVhqA 2KaQxhu0iAwy+KIml+CkrMRTA2GIVTgZvPP7BdOXDTLu9HND3PfxIVB0/V1suO6spBxu w+ugljbilT8Xyj+wPr5aH1wcv+/1s6U3TWDxYLvRPl9zk0ug9BodKQROgmm6vOHwTIcs r8iMGrzQdnS2SkDKDnKlkoTa1Io+H5bE4s67IUAtJ3FgiB0G2oYsfA9jZ4ClQJbAipA7 /6tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702606276; x=1703211076; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=Hn2u3ohnyQZ77hNqSlm/EvFnLZDsF+Ox+1yQ+iYOeGU=; b=OX0sc55xA9GFLuD0zOqTo5e8Cc9hcwl5nU6kdX010P/nbvMQgVEAKkRaQkJHj1otpR LU6m/uDMqu5ksGa2Ac3rHKIZdh4KWhNXvllvfu9sUxv1EeumEFWMqJs/baa0rBLDdWRC MT1GKA7gIGZ/R2K+x1t1aWkwGqZcpBCpHjxXhbdl6qBnX9KDAM3DCvmupbUjb3kN1r/h uRZ8VnqDBCj7gQ62k8YJXwoqNk1YQYsIXtDEOn75nZ8zhX+CBS6bHQtuhUHgQDZwzWNH UL0hzMbPWtOk0SZ0yAxsayDibFDIOjKaFDNn7wOajCHjfd8HHJQvRhcacLTZG7Nr59Ny uiSg== X-Gm-Message-State: AOJu0YzpWxtVBk41kGX2xxAbMXldZoKniZL0aYljx0DHek0lUNvNljNU ubPU4YV2b5HyQBuBHMNFZz8PxTI3QEa7jA== X-Google-Smtp-Source: AGHT+IFer5ptuGEEfLFmjy3FBazRTAHYraFtWH6cjZkWuSL5hJETliQbOEPas4rAqb9tpBNPAqzbmDmViSQbnQ== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a17:902:f690:b0:1d0:8be8:bb7c with SMTP id l16-20020a170902f69000b001d08be8bb7cmr1969874plg.4.1702606275789; Thu, 14 Dec 2023 18:11:15 -0800 (PST) Date: Fri, 15 Dec 2023 02:11:14 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20231214020530.2267499-1-almasrymina@google.com> <20231214020530.2267499-5-almasrymina@google.com> Message-ID: <20231215021114.ipvdx2bwtxckrfdg@google.com> Subject: Re: [RFC PATCH net-next v1 4/4] net: page_pool: use netmem_t instead of struct page in API From: Shakeel Butt To: Mina Almasry Cc: Yunsheng Lin , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Greg Kroah-Hartman , "Rafael J. Wysocki" , Sumit Semwal , "Christian =?utf-8?B?S8O2bmln?=" , Michael Chan , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Wei Fang , Shenwei Wang , Clark Wang , NXP Linux Team , Jeroen de Borst , Praveen Kaligineedi , Shailend Chand , Yisen Zhuang , Salil Mehta , Jesse Brandeburg , Tony Nguyen , Thomas Petazzoni , Marcin Wojtas , Russell King , Sunil Goutham , Geetha sowjanya , Subbaraya Sundeep , hariprasad , Felix Fietkau , John Crispin , Sean Wang , Mark Lee , Lorenzo Bianconi , Matthias Brugger , AngeloGioacchino Del Regno , Saeed Mahameed , Leon Romanovsky , Horatiu Vultur , UNGLinuxDriver@microchip.com, "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Jassi Brar , Ilias Apalodimas , Alexandre Torgue , Jose Abreu , Maxime Coquelin , Siddharth Vadapalli , Ravi Gunasekaran , Roger Quadros , Jiawen Wu , Mengyuan Lou , Ronak Doshi , VMware PV-Drivers Reviewers , Ryder Lee , Shayne Chen , Kalle Valo , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Stefan Hajnoczi , Stefano Garzarella , Shuah Khan , "=?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?=" , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Justin Stitt , Jason Gunthorpe , Willem de Bruijn Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 14, 2023 at 08:27:55AM -0800, Mina Almasry wrote: > On Thu, Dec 14, 2023 at 4:05=E2=80=AFAM Yunsheng Lin wrote: > > [...] > > I perfer the second one personally, as devmem means that it is not > > readable from cpu. >=20 > From my POV it has to be the first one. We want to abstract the memory > type from the drivers as much as possible, not introduce N new memory > types and ask the driver to implement new code for each of them > separately. >=20 Agree with Mina's point. Let's aim to decouple memory types from drivers.