On 8/13/24 01:15, Jakub Kicinski wrote:
On Mon, 12 Aug 2024 20:04:41 +0100 Pavel Begunkov wrote:
quoted
quoted
quoted
Also don't see the upside of the explicit "non-capable" flag,
but I haven't thought of that. Is there any use?
Or maybe I don't get what you're asking, I explained
why to have that "PP_IGNORE_PROVIDERS" on top of the flag
saying that it's supported.
Which "non-capable" flag you have in mind? A page pool create
flag or one facing upper layers like devmem tcp?
Let me rephrase - what's the point of having both PP_PROVIDERS_SUPPORTED
and PP_IGNORE_PROVIDERS at the page pool level? PP_CAP_NET(MEM|IOV),
and it's either there or it's not.
The second flag solves a problem with initializing page pools
with headers, but let's forget about it for now, it's rather a
small nuance, would probably reappear when someone would try to
use pp_params->queue for purposes different from memory providers.
If you're thinking about advertising the support all the way to the
user, I'm not sure if page pool is the right place to do so. It's more
of a queue property.
Nope. Only the first "SUPPORTED" flag serves that purpose in a way
by failing setup like netlink devmem dmabuf binding and returning
the error back to user.
BTW, Mina, the core should probably also check that XDP isn't installed
before / while the netmem is bound to a queue.
--
Pavel Begunkov