From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.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 AC98E7B3AE for ; Thu, 21 Dec 2023 23:23:46 +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="rIee9BHF" Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-db402e6f61dso1739083276.3 for ; Thu, 21 Dec 2023 15:23:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1703201025; x=1703805825; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=cU9mOyLPoF6ZxNM7jnDLVtHU9dKeo3lsrx7E6D/L6sI=; b=rIee9BHFH3w3Z9YC28rgKtx4jr66VuXGwN+IQzUx04pSGohOdVOf65JlJd+b4wY7CT mb2d02bNRGYDyjAmCf35ji7Qo5w4J6W+uR4MoHcrA3sFVi28tEvIqu3o/tuL/eMBSSlx TaWrPrRdCXBVUHD5I6urFnQzzUSZvivuA/lTJVfOncmM1YtQxtJrw1vAKIpLQOPwujKu LYs2vQJkbg8cK+SfRZsV9vxpYa8hXE+XQSj1cYSgol5uj8GAPrT59Wdv9tQezatc4EEF xdCeqO6owtLWCZn/5FT8/qdhBI8a2hex6djOc5zW5mtvTPyd1qdJ0symVw27M5UT+I7u EWng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703201025; x=1703805825; h=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=cU9mOyLPoF6ZxNM7jnDLVtHU9dKeo3lsrx7E6D/L6sI=; b=aKcCPInP57k2eB+TCmWx1sUjrVvFpa+eZr+Q+aKjlKnQKJ1iCMwgwRNZdhwmPZ276/ YbtMVri3ZPAbupuHixVJ5BuH2nm3L9JkENcWLsKyJIk9c6IO3IcyszkRlV626BWMqfZj MZ3ySSn6cm+9Tmg0QUY44TNLQGL81z5xm0+pLmskVtCSEvOvh19Oxz1xq/tgIqVXi8Fq Iq3fAg8yJONsbRgDPDD6JhY2fFQ9OWB5FeSgneKQz6khmzr6HqfA7WTwR5ilXTseEF0Y OvoKAH7iq9mr8sBFnxFp9FXZ8vrQP6nHr/w+JlGkNs8EMHNa1idG68fYFWLkDYMjO0Nw 7SzQ== X-Gm-Message-State: AOJu0YxMNFp4SSzn4GM1kOObtxQGJU5epn/m8QQ/hawcNr4ksI8eVXYP 9gtjmBYjb9ub7hs13ArVtNuH6HpKrgcXOtOM0R2m X-Google-Smtp-Source: AGHT+IHWiT1s/e6el8Gbfa2jmdYfbMdaJTd+pS4T1tXJHPKsVM+5WAmrvhPrUoUOQ5Wk4tJyK70wKIQ5Qx+mgg== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a25:bcc2:0:b0:db5:47c1:e82d with SMTP id l2-20020a25bcc2000000b00db547c1e82dmr189052ybm.6.1703201025720; Thu, 21 Dec 2023 15:23:45 -0800 (PST) Date: Thu, 21 Dec 2023 23:23:43 +0000 In-Reply-To: <20231220214505.2303297-3-almasrymina@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20231220214505.2303297-1-almasrymina@google.com> <20231220214505.2303297-3-almasrymina@google.com> Message-ID: <20231221232343.qogdsoavt7z45dfc@google.com> Subject: Re: [PATCH net-next v3 2/3] net: introduce abstraction for network memory From: Shakeel Butt To: Mina Almasry Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux.dev, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Stefan Hajnoczi , Stefano Garzarella , David Howells , Jason Gunthorpe , "Christian =?utf-8?B?S8O2bmln?=" , Yunsheng Lin , Willem de Bruijn Content-Type: text/plain; charset="us-ascii" On Wed, Dec 20, 2023 at 01:45:01PM -0800, Mina Almasry wrote: > Add the netmem_ref type, an abstraction for network memory. > > To add support for new memory types to the net stack, we must first > abstract the current memory type. Currently parts of the net stack > use struct page directly: > > - page_pool > - drivers > - skb_frag_t > > Originally the plan was to reuse struct page* for the new memory types, > and to set the LSB on the page* to indicate it's not really a page. > However, for compiler type checking we need to introduce a new type. > > netmem_ref is introduced to abstract the underlying memory type. Currently > it's a no-op abstraction that is always a struct page underneath. In > parallel there is an undergoing effort to add support for devmem to the > net stack: > > https://lore.kernel.org/netdev/20231208005250.2910004-1-almasrymina@google.com/ > > Signed-off-by: Mina Almasry > > --- > > v3: > > - Modify struct netmem from a union of struct page + new types to an opaque > netmem_ref type. I went with: > > +typedef void *__bitwise netmem_ref; > > rather than this that Jakub recommended: > > +typedef unsigned long __bitwise netmem_ref; > > Because with the latter the compiler issues warnings to cast NULL to > netmem_ref. I hope that's ok. > Can you share what the warning was? You might just need __force attribute. However you might need this __force a lot. I wonder if you can just follow struct encoded_page example verbatim here.