From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.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 AC0B65FBBF for ; Fri, 22 Mar 2024 17:40:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711129243; cv=none; b=cSiFtjc6aQNxURVlJLumdtnXRJlTClD6JTB0hoQG3FF1a+1M5SvIBq8FUAL3Dcw3cPNpkgAfdwSU4es2QGs1TckQxi03Z2mq9dkkwgl30dVq14P43YE7t08qQ5Rqt8Xfyztlj19+hC7MV0oP+UWKgr87/fNLFOr4WS+w06lQn3I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711129243; c=relaxed/simple; bh=7T0QYgj6Z0QWJ7WZghtr6Q0zZ77ROAwtyZEJQAtnJrY=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=A8FI7NXMr68e7sdpmDWAJjuCRtjZsOMfTE0XEMO4dxd9CCgsQ82NGEYJ/s+HsMqTIwr088rcABgZDsipBdcJFM+TtnDvhQpfEFVe10PMIth0+RdkXPs8Zt/h/Abfd8HwVanliuTqm1eRlajeoyPkSApL1xgCO+cGxGaKKJSypbU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=NuAiMh/M; arc=none smtp.client-ip=209.85.218.50 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=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="NuAiMh/M" Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-a468004667aso340701766b.2 for ; Fri, 22 Mar 2024 10:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1711129239; x=1711734039; darn=vger.kernel.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=7YM4J2ObtCNq8IqrJeUkrlLZCafy3cmXh0Ri66R+dm4=; b=NuAiMh/MosGpuJph6/CXhnqgtnF7qTB4wgozIjMxlP7xwIMTBUkxGp7jiLeBJeNUA8 uf3RbWvwApbMZFE+1zAiSE/rUFH1AmO4Inn/LeR4eLLIyJhCb6kAZF5e/IqWygoVbAS0 YNddRISS5xPN/6moDsAN0RJLCFP7BYfwoyTBXRz81dPr4VwAGpuAx4kKX1ddy3i+i8J0 GW8CtvhZyNMxHOAbds+zU9+r9Ux6hPYEAFI7Xi+I0b4x9bRWTLPNpPCI2wo9BHwHpm54 90xv2NndkuSs6tCPxxNLMeQMMbA9UkVREUUY00h8sSJNFZUydz03W+30nass1/Zv6OwQ wtCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711129239; x=1711734039; 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=7YM4J2ObtCNq8IqrJeUkrlLZCafy3cmXh0Ri66R+dm4=; b=Lqg2gEA6Q5i8C+gioc7wJVhCusRfXxxpBOwC0+CHdhvbxtpt8bCPMmQjtYI7wlguSK mI6xf2UDg6N/i5/5G8HnsMTHYfJYh+gdjCyS5bnCaXgACoGQRVxOJg9Gks1JiRV3YgvV RGJlMDiG8sFK81ooP98+Rna7xJWaG0juervo7AoTVBfRi3lXZJ235VEzlvqg5OGXXSAc LNKAZcZ4U7T9aTBI38uj48wau4JSYRzkAF0g6bUBdaAjx7fNoinUuo9Tt+TG5NqyB1k5 HRAdefJvYhZlv+MwAY/GqXTJ/KqD50DxFxg7zNkBhNRnIlVgpaJEq8AVEjzl6yz6pv7A N+4Q== X-Forwarded-Encrypted: i=1; AJvYcCVQxWGS8zpsh4QMu4TAwXk+DcIvafYMheNMj7+/7CMCLa66/ci9hT3l3B9ilqUg9Ij8lDxGR3xXnTU/H+Y1r9QDt0fSqfJz X-Gm-Message-State: AOJu0YwCQg4EKGhDCrZw2+0APD/VP+X0JdwKK5/1p1JyR3nvBUbvDkdz 14BBuqtAoaZDZNT0/vctse8BknLGpAji7oPY1ZNhfnwpEm9KlYogRlWo336rpE/R51G8NUtZxZ2 D0DAo7LV0+qvuGvJD45Co63J333TO75SO4K0o X-Google-Smtp-Source: AGHT+IH25NX6qQBoFnVnA4psBCYCRYBaiXOTPUtbfU8ggcYNeDelzQNuP6wH36Jj0kmkf8kYIMZ+vwfa54Dm4tCqR3s= X-Received: by 2002:a17:906:c2d4:b0:a46:befa:f0b0 with SMTP id ch20-20020a170906c2d400b00a46befaf0b0mr293662ejb.45.1711129238808; Fri, 22 Mar 2024 10:40:38 -0700 (PDT) Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240305020153.2787423-1-almasrymina@google.com> <20240305020153.2787423-3-almasrymina@google.com> In-Reply-To: From: Mina Almasry Date: Fri, 22 Mar 2024 10:40:26 -0700 Message-ID: Subject: Re: [RFC PATCH net-next v6 02/15] net: page_pool: create hooks for custom page providers To: Christoph Hellwig Cc: David Wei , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-alpha@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, sparclinux@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-arch@vger.kernel.org, bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Jonathan Corbet , Richard Henderson , Ivan Kokshaysky , Matt Turner , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Andreas Larsson , Jesper Dangaard Brouer , Ilias Apalodimas , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Arnd Bergmann , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , David Ahern , Willem de Bruijn , Shuah Khan , Sumit Semwal , =?UTF-8?Q?Christian_K=C3=B6nig?= , Pavel Begunkov , Jason Gunthorpe , Yunsheng Lin , Shailend Chand , Harshitha Ramamurthy , Jeroen de Borst , Praveen Kaligineedi Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christoph, Sorry for the late reply, I've been out for a few days. On Mon, Mar 18, 2024 at 4:22=E2=80=AFPM Christoph Hellwig wrote: > > On Sun, Mar 17, 2024 at 07:49:43PM -0700, David Wei wrote: > > I'm working on a similar proposal for zero copy Rx but to host memory > > and depend on this memory provider API. > > How do you need a different provider for that vs just udmabuf? > This was discussed on the io_uring ZC RFC in one of the earliest RFCs. Here is a link to Pavel's response: https://patchwork.kernel.org/project/netdevbpf/patch/20231106024413.2801438= -6-almasrymina@google.com/#25589471 The UAPI of wrapping io_uring memory into a udmabuf just to use it with devmem TCP only for the user to have to unwrap it is undesirable to him. > > Jakub also designed this API for hugepages too IIRC. Basically there's > > going to be at least three fancy ways of providing pages (one of which > > isn't actually pages, hence the merged netmem_t series) to drivers. > > How do hugepages different from a normal page allocation? They should > just a different ordered passed to the page allocator. > Yes, that's more-or-less what's what the hugepage memory provider Jakub proposed does. The memory provider would allocate a hugepage and hold a reference to it. Then when the page_pool needs a page, it would allocate a PAGE_SIZE page from said hugepage region and provide it to the page_pool, and the pool back to the driver. This allows the hugepages to work without the page_pool and driver to be hugepage aware and to insert huge page specific processing in it. Other designs for this hugepage use case are possible, I'm just describing Jakub's idea for it as a potential use-case for these hooks. For example technically the page_pool at the moment does support non-0 order allocations, but most drivers simply set the order to 0 and use the page pool only for PAGE_SIZE allocations. An alternative design could be to use this support in the page pool, but that requires every driver to adopt this rather than a core networking change that can apply transparently (to a large extent) to all page_pool drivers. --=20 Thanks, Mina