Re: [PATCH net-next v2 14/15] mm: page_frag: update documentation for page_frag

[Bagas Sanjaya <bagasdotme@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]