Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 11 Jul 2023 18:59:51 +0200 | Subject | Re: [PATCH v5 RFC 1/6] page_pool: frag API support for 32-bit arch with 64-bit DMA | From | Alexander Lobakin <> |
| |
From: Jakub Kicinski <kuba@kernel.org> Date: Tue, 11 Jul 2023 09:37:05 -0700
> 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
(not sure we shouldn't split a separate thread off this one at this point :D)
`long long` or `long`? `long long` is always 64-bit unless I'm missing something. On my 32-bit MIPS they were :D If `long long`, what's the point then if we have %NLA_U64 and would still have to add dumb padding attrs? :D I thought the idea was to carry 64+ bits encapsulated in 32-bit primitives.
> 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.
Aaah okay, I did read it backwards ._. Moreover, generic stack barely uses PP's inlines, it needs externals mostly.
Thanks, Olek
| ![\](/images/icornerr.gif) |