On 8/13/24 01:15, Jakub Kicinski wrote:
On Mon, 12 Aug 2024 20:04:41 +0100 Pavel Begunkov wrote:
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.