From: Jakub Kicinski <kuba@kernel.org>
To: Mina Almasry <almasrymina@google.com>
Cc: "David Ahern" <dsahern@kernel.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
bpf@vger.kernel.org, "Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
"Michael Chan" <michael.chan@broadcom.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Paolo Abeni" <pabeni@redhat.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Jesper Dangaard Brouer" <hawk@kernel.org>,
"John Fastabend" <john.fastabend@gmail.com>,
"Wei Fang" <wei.fang@nxp.com>,
"Shenwei Wang" <shenwei.wang@nxp.com>,
"Clark Wang" <xiaoning.wang@nxp.com>,
"NXP Linux Team" <linux-imx@nxp.com>,
"Jeroen de Borst" <jeroendb@google.com>,
"Praveen Kaligineedi" <pkaligineedi@google.com>,
"Shailend Chand" <shailend@google.com>,
"Yisen Zhuang" <yisen.zhuang@huawei.com>,
"Salil Mehta" <salil.mehta@huawei.com>,
"Jesse Brandeburg" <jesse.brandeburg@intel.com>,
"Tony Nguyen" <anthony.l.nguyen@intel.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Marcin Wojtas" <mw@semihalf.com>,
"Russell King" <linux@armlinux.org.uk>,
"Sunil Goutham" <sgoutham@marvell.com>,
"Geetha sowjanya" <gakula@marvell.com>,
"Subbaraya Sundeep" <sbhatta@marvell.com>,
hariprasad <hkelam@marvell.com>, "Felix Fietkau" <nbd@nbd.name>,
"John Crispin" <john@phrozen.org>,
"Sean Wang" <sean.wang@mediatek.com>,
"Mark Lee" <Mark-MC.Lee@mediatek.com>,
"Lorenzo Bianconi" <lorenzo@kernel.org>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Saeed Mahameed" <saeedm@nvidia.com>,
"Leon Romanovsky" <leon@kernel.org>,
"Horatiu Vultur" <horatiu.vultur@microchip.com>,
UNGLinuxDriver@microchip.com,
"K. Y. Srinivasan" <kys@microsoft.com>,
"Haiyang Zhang" <haiyangz@microsoft.com>,
"Wei Liu" <wei.liu@kernel.org>,
"Dexuan Cui" <decui@microsoft.com>,
"Jassi Brar" <jaswinder.singh@linaro.org>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
"Jose Abreu" <joabreu@synopsys.com>,
"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
"Siddharth Vadapalli" <s-vadapalli@ti.com>,
"Ravi Gunasekaran" <r-gunasekaran@ti.com>,
"Roger Quadros" <rogerq@kernel.org>,
"Jiawen Wu" <jiawenwu@trustnetic.com>,
"Mengyuan Lou" <mengyuanlou@net-swift.com>,
"Ronak Doshi" <doshir@vmware.com>,
"VMware PV-Drivers Reviewers" <pv-drivers@vmware.com>,
"Ryder Lee" <ryder.lee@mediatek.com>,
"Shayne Chen" <shayne.chen@mediatek.com>,
"Kalle Valo" <kvalo@kernel.org>,
"Juergen Gross" <jgross@suse.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Oleksandr Tyshchenko" <oleksandr_tyshchenko@epam.com>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Martin KaFai Lau" <martin.lau@linux.dev>,
"Song Liu" <song@kernel.org>,
"Yonghong Song" <yonghong.song@linux.dev>,
"KP Singh" <kpsingh@kernel.org>,
"Stanislav Fomichev" <sdf@google.com>,
"Hao Luo" <haoluo@google.com>, "Jiri Olsa" <jolsa@kernel.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Stefano Garzarella" <sgarzare@redhat.com>,
"Shuah Khan" <shuah@kernel.org>,
"Mickaël Salaün" <mic@digikod.net>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Bill Wendling" <morbo@google.com>,
"Justin Stitt" <justinstitt@google.com>,
"Jason Gunthorpe" <jgg@nvidia.com>,
"Shakeel Butt" <shakeelb@google.com>,
"Yunsheng Lin" <linyunsheng@huawei.com>,
"Willem de Bruijn" <willemdebruijn.kernel@gmail.com>
Subject: Re: [RFC PATCH net-next v1 2/4] net: introduce abstraction for network memory
Date: Mon, 18 Dec 2023 14:06:45 -0800 [thread overview]
Message-ID: <20231218140645.461169a7@kernel.org> (raw)
In-Reply-To: <CAHS8izOeCdA+WVRYbieTqaCyadARsOpYttAXh7Lhu-B7RC3Tmg@mail.gmail.com>
On Sun, 17 Dec 2023 00:14:59 -0800 Mina Almasry wrote:
> > > Sure thing I can do that. Is it better to do something like:
> > >
> > > struct netmem_ref;
> > >
> > > like in this patch:
> > >
> > > https://lore.kernel.org/linux-mm/20221108194139.57604-1-torvalds@linux-foundation.org/
> > >
> > > Asking because checkpatch tells me not to add typedefs to the kernel,
> > > but checkpatch can be ignored if you think it's OK.
> > >
> > > Also with this approach I can't use container_of and I need to do a
> > > cast, I assume that's fine.
> > >
> >
> > Isn't that the whole point of this set - to introduce a new data type
> > and avoid casts?
I don't see how we can avoid casts if the type of the referenced object
is encoded on the low bits of the pointer. If we had a separate member
we could so something like:
struct netmem_ref {
enum netmem_type type;
union {
struct page *p;
struct page_pool_iov *pi;
};
};
barring crazy things with endian-aware bitfields, we need at least one
cast.
> My understanding here the requirements from Jason are:
>
> 1. Never pass a non-page to an mm api.
> 2. If a mangle a pointer to indicate it's not a page, then I must not
> call it mm's struct page*, I must add a new type.
>
> I think both requirements are met regardless of whether
> netmem_to_page() is implemented using union/container_of or straight
> casts. folios implemented something similar being unioned with struct
> page to avoid casts.
Folios overlay a real struct page. It's completely different.
> I honestly could go either way on this. The union
> provides some self documenting code and avoids casts.
Maybe you guys know some trick to mask out the bottom bit :S
> The implementation without the union obfuscates the type and makes it much
> more opaque.
Some would say that that's the damn point of the wrapping..
You don't want non-core code futzing with the inside of the struct.
> I finished addressing the rest of the comments and I have this series
> and the next devmem TCP series ready to go, so I fired v2 of this
> patchset. If one feels strongly about this let me know and I will
> re-spin.
You didn't address my feedback :|
struct netmem which contains struct page by value is almost as bad
as passing around pretend struct page pointers.
next prev parent reply other threads:[~2023-12-18 22:06 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 2:05 [RFC PATCH net-next v1 0/4] Abstract page from net stack Mina Almasry
2023-12-14 2:05 ` [RFC PATCH net-next v1 1/4] vsock/virtio: use skb_frag_page() helper Mina Almasry
2023-12-14 6:27 ` David Ahern
2023-12-14 8:19 ` Stefano Garzarella
2023-12-14 2:05 ` [RFC PATCH net-next v1 2/4] net: introduce abstraction for network memory Mina Almasry
2023-12-14 6:34 ` David Ahern
2023-12-16 2:51 ` Jakub Kicinski
2023-12-16 22:10 ` Mina Almasry
2023-12-17 1:45 ` David Ahern
2023-12-17 8:14 ` Mina Almasry
2023-12-18 22:06 ` Jakub Kicinski [this message]
2023-12-18 22:38 ` Mina Almasry
2023-12-19 17:27 ` Shakeel Butt
2023-12-14 2:05 ` [RFC PATCH net-next v1 3/4] net: add netmem_t to skb_frag_t Mina Almasry
2023-12-14 2:05 ` [RFC PATCH net-next v1 4/4] net: page_pool: use netmem_t instead of struct page in API Mina Almasry
2023-12-14 12:05 ` Yunsheng Lin
2023-12-14 16:27 ` Mina Almasry
2023-12-15 2:11 ` Shakeel Butt
2023-12-15 11:04 ` Yunsheng Lin
2023-12-15 16:47 ` Shakeel Butt
2023-12-16 3:01 ` Jakub Kicinski
2023-12-16 19:46 ` Shakeel Butt
2023-12-16 22:06 ` Mina Almasry
2023-12-20 3:01 ` Mina Almasry
2023-12-21 11:32 ` Yunsheng Lin
2023-12-21 21:22 ` Mina Almasry
2023-12-22 6:42 ` Yunsheng Lin
2024-01-02 16:14 ` Mina Almasry
2024-01-03 9:47 ` Yunsheng Lin
2024-01-03 18:38 ` Mina Almasry
2024-01-04 8:48 ` Yunsheng Lin
2024-01-04 18:24 ` Mina Almasry
2024-01-05 8:40 ` Yunsheng Lin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231218140645.461169a7@kernel.org \
--to=kuba@kernel.org \
--cc=Mark-MC.Lee@mediatek.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.torgue@foss.st.com \
--cc=almasrymina@google.com \
--cc=andrii@kernel.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=anthony.l.nguyen@intel.com \
--cc=ast@kernel.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=christian.koenig@amd.com \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=doshir@vmware.com \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=gakula@marvell.com \
--cc=gregkh@linuxfoundation.org \
--cc=haiyangz@microsoft.com \
--cc=haoluo@google.com \
--cc=hawk@kernel.org \
--cc=hkelam@marvell.com \
--cc=horatiu.vultur@microchip.com \
--cc=hpa@zytor.com \
--cc=ilias.apalodimas@linaro.org \
--cc=jaswinder.singh@linaro.org \
--cc=jeroendb@google.com \
--cc=jesse.brandeburg@intel.com \
--cc=jgg@nvidia.com \
--cc=jgross@suse.com \
--cc=jiawenwu@trustnetic.com \
--cc=joabreu@synopsys.com \
--cc=john.fastabend@gmail.com \
--cc=john@phrozen.org \
--cc=jolsa@kernel.org \
--cc=justinstitt@google.com \
--cc=kpsingh@kernel.org \
--cc=kvalo@kernel.org \
--cc=kys@microsoft.com \
--cc=leon@kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linyunsheng@huawei.com \
--cc=lorenzo@kernel.org \
--cc=martin.lau@linux.dev \
--cc=matthias.bgg@gmail.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mengyuanlou@net-swift.com \
--cc=mic@digikod.net \
--cc=michael.chan@broadcom.com \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=mw@semihalf.com \
--cc=nathan@kernel.org \
--cc=nbd@nbd.name \
--cc=ndesaulniers@google.com \
--cc=netdev@vger.kernel.org \
--cc=oleksandr_tyshchenko@epam.com \
--cc=pabeni@redhat.com \
--cc=pkaligineedi@google.com \
--cc=pv-drivers@vmware.com \
--cc=r-gunasekaran@ti.com \
--cc=rafael@kernel.org \
--cc=rogerq@kernel.org \
--cc=ryder.lee@mediatek.com \
--cc=s-vadapalli@ti.com \
--cc=saeedm@nvidia.com \
--cc=salil.mehta@huawei.com \
--cc=sbhatta@marvell.com \
--cc=sdf@google.com \
--cc=sean.wang@mediatek.com \
--cc=sgarzare@redhat.com \
--cc=sgoutham@marvell.com \
--cc=shailend@google.com \
--cc=shakeelb@google.com \
--cc=shayne.chen@mediatek.com \
--cc=shenwei.wang@nxp.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=sstabellini@kernel.org \
--cc=stefanha@redhat.com \
--cc=sumit.semwal@linaro.org \
--cc=tglx@linutronix.de \
--cc=thomas.petazzoni@bootlin.com \
--cc=wei.fang@nxp.com \
--cc=wei.liu@kernel.org \
--cc=willemdebruijn.kernel@gmail.com \
--cc=x86@kernel.org \
--cc=xiaoning.wang@nxp.com \
--cc=yisen.zhuang@huawei.com \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.