Messages in this thread | | | Date | Tue, 11 Jul 2023 09:37:05 -0700 | From | Jakub Kicinski <> | Subject | Re: [PATCH v5 RFC 1/6] page_pool: frag API support for 32-bit arch with 64-bit DMA |
| |
On Tue, 11 Jul 2023 12:59:00 +0200 Alexander Lobakin wrote: > I'm fine with that, although ain't really able to work on this myself > now :s (BTW I almost finished Netlink bigints, just some more libie/IAVF > crap).
FWIW I was thinking about the bigints recently, and from ynl perspective I think we may want two flavors :( One which is at most the length of platform's long long, and another which is always a bigint. The latter will be more work for user space to handle, so given 99% of use cases don't need more than 64b we should make its life easier?
> It just needs to be carefully designed, because if we want move ALL the > inlines to a new header, we may end up including 2 PP's headers in each > file. That's why I'd prefer "core/driver" separation. Let's say skbuff.c > doesn't need page_pool_create(), page_pool_alloc(), and so on, while > drivers don't need some of its internal functions. > OTOH after my patch it's included in only around 20-30 files on > allmodconfig. That is literally nothing comparing to e.g. kernel.h > (w/includes) :D
Well, once you have to rebuilding 100+ files it gets pretty hard to clean things up ;)
I think I described the preferred setup, previously:
$path/page_pool.h:
#include <$path/page_pool/types.h> #include <$path/page_pool/helpers.h>
$path/page_pool/types.h - has types $path/page_pool/helpers.h - has all the inlines
C sources can include $path/page_pool.h, headers should generally only include $path/page_pool/types.h.
| |