On Sat, Aug 19, 2023 at 11:49 AM David Ahern [off-list ref] wrote:

On 8/19/23 9:22 AM, Jesper Dangaard Brouer wrote:

quoted

I do see the problem of depending on having a struct page, as the
page_pool_iov isn't related to struct page.  Having "page" in the name
of "page_pool_iov" is also confusing (hardest problem is CS is naming,
as we all know).

To support more allocator types, perhaps skb->pp_recycle bit need to
grow another bit (and be renamed skb->recycle), so we can tell allocator
types apart, those that are page based and those whom are not.

quoted

I think the feedback has been strong to not multiplex yet another
memory type into that struct, that is not a real page. Which is why
we went into this direction. This latest series limits the impact largely
to networking structures and code.

Some what related what I'm objecting to: the "page_pool_iov" is not a
real page, but this getting recycled into something called "page_pool",
which funny enough deals with struct-pages internally and depend on the
struct-page-refcnt.

Given the approach changed way from using struct page, then I also don't
see the connection with the page_pool. Sorry.

I do not care for the page_pool_iov name either; I presumed it was least
change to prove an idea and the name and details would evolve.

How about something like buffer_pool or netdev_buf_pool that can operate
with either pages, dma addresses, or something else in the future?

Sounds good. I suggested this name, but I see how using page in the
name is not very clear.

quoted

quoted

As for the LSB trick: that avoided adding a lot of boilerplate churn
with new type and helper functions.

Says the lazy programmer :-P ... sorry could not resist ;-)

:-) For the record, there is a prior version that added a separate type.

I did not like the churn it brought and asked for this.

Use of the LSB (or bits depending on alignment expectations) is a common
trick and already done in quite a few places in the networking stack.
This trick is essential to any realistic change here to incorporate gpu
memory; way too much code will have unnecessary churn without it.

I do prefer my earlier suggestion though where the skb_frag_t has a
union of relevant types though. Instead of `struct page *page` it could
be `void *addr` with the helpers indicating page, iov, or other.

Okay. I think that is how we did it previously.