On Mon, Apr 15, 2024 at 09:19:39PM +0800, Yunsheng Lin wrote:
> +API interface
> +=============
> +As the design and implementation of page_frag API, the allocation side does not
"... implies, the allocation side ..."
> +allow concurrent calling, it is assumed that the caller must ensure there is not
"... . Instead, it is assumed that ...:
> +concurrent alloc calling to the same page_frag_cache instance by using it's own
"... by using its own ..."
> +lock or rely on some lockless guarantee like NAPI softirq.
> +
> +Depending on different use cases, callers expecting to deal with va, page or
> +both va and page for them may call page_frag_alloc_va*, page_frag_alloc_pg*,
> +or page_frag_alloc* API accordingly.
> +
> +There is also a use case that need minimum memory in order for forward
> +progressing, but can do better if there is more memory available. Introduce
Did you mean "... but more performant if more memory is available"?
> +page_frag_alloc_prepare() and page_frag_alloc_commit() related API, the caller
s/Introduce/Using/
> +requests the minimum memory it need and the prepare API will return the maximum
> +size of the fragment returned, caller need to report back to the page_frag core
"The caller needs to either call the commit API ..."
> +how much memory it actually use by calling commit API, or not calling the commit
"... to report how much memory it actually uses ..."
> +API if deciding to not use any memory.
"... or not do so if deciding to not use any memory."
Thanks.
--
An old man doll... just what I always wanted! - Clara