Received-SPF: pass (google.com: domain of linux-kernel+bounces-146320-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 16 Apr 2024 13:13:35 +0700
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Yunsheng Lin <linyunsheng@huawei.com>, davem@davemloft.net,
	kuba@kernel.org, pabeni@redhat.com
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Alexander Duyck <alexander.duyck@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH net-next v2 14/15] mm: page_frag: update documentation
 for page_frag
Message-ID: <Zh4XD6jP4dLoZN4Q@archie.me>
References: <20240415131941.51153-1-linyunsheng@huawei.com>
 <20240415131941.51153-15-linyunsheng@huawei.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="0I6/Ma35WnVqMhhN"
Content-Disposition: inline
In-Reply-To: <20240415131941.51153-15-linyunsheng@huawei.com>


--0I6/Ma35WnVqMhhN
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 15, 2024 at 09:19:39PM +0800, Yunsheng Lin wrote:
> +API interface
> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> +As the design and implementation of page_frag API, the allocation side d=
oes not
                                        "... implies, the allocation side .=
=2E."
> +allow concurrent calling, it is assumed that the caller must ensure ther=
e is not
                      "... . Instead, it is assumed that ...:
> +concurrent alloc calling to the same page_frag_cache instance by using i=
t's own
                                                            "... by using i=
ts own ..."
> +lock or rely on some lockless guarantee like NAPI softirq.
> +
> +Depending on different use cases, callers expecting to deal with va, pag=
e 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. Introd=
uce
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_fr=
ag core
                                  "The caller needs to either call the comm=
it API ..."
> +how much memory it actually use by calling commit API, or not calling th=
e 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.

--=20
An old man doll... just what I always wanted! - Clara

--0I6/Ma35WnVqMhhN
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSSYQ6Cy7oyFNCHrUH2uYlJVVFOowUCZh4XCwAKCRD2uYlJVVFO
o85iAP0UEZ96bTaKdZC0FmSard5z0dMjRBPD69wzKG6rmE9CagD+LpsBRsgW1frt
81TmfyhS9gzn/HY0KhWP63uiPguKkQY=
=zrUk
-----END PGP SIGNATURE-----

--0I6/Ma35WnVqMhhN--