On 2024/4/16 14:13, Bagas Sanjaya wrote: > 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. Your wording seems better than mine, will update it accordingly. > > Thanks. >
