All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.duyck@gmail.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [RFC PATCH 03/20] mm: Add documentation for page fragment APIs
Date: Mon, 19 Dec 2016 12:10:58 -0800	[thread overview]
Message-ID: <20161219201058.27116.89821.stgit@localhost.localdomain> (raw)
In-Reply-To: <20161219200456.27116.28900.stgit@localhost.localdomain>

From: Alexander Duyck <alexander.h.duyck@intel.com>

This is a first pass at trying to add documentation for the page_frag APIs.
They may still change over time but for now I thought I would try to get
these documented so that as more network drivers and stack calls make use
of them we have one central spot to document how they are meant to be used.

Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
 Documentation/vm/page_frags |   42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)
 create mode 100644 Documentation/vm/page_frags

diff --git a/Documentation/vm/page_frags b/Documentation/vm/page_frags
new file mode 100644
index 000000000000..a6714565dbf9
--- /dev/null
+++ b/Documentation/vm/page_frags
@@ -0,0 +1,42 @@
+Page fragments
+--------------
+
+A page fragment is an arbitrary-length arbitrary-offset area of memory
+which resides within a 0 or higher order compound page.  Multiple
+fragments within that page are individually refcounted, in the page's
+reference counter.
+
+The page_frag functions, page_frag_alloc and page_frag_free, provide a
+simple allocation framework for page fragments.  This is used by the
+network stack and network device drivers to provide a backing region of
+memory for use as either an sk_buff->head, or to be used in the "frags"
+portion of skb_shared_info.
+
+In order to make use of the page fragment APIs a backing page fragment
+cache is needed.  This provides a central point for the fragment allocation
+and tracks allows multiple calls to make use of a cached page.  The
+advantage to doing this is that multiple calls to get_page can be avoided
+which can be expensive at allocation time.  However due to the nature of
+this caching it is required that any calls to the cache be protected by
+either a per-cpu limitation, or a per-cpu limitation and forcing interrupts
+to be disabled when executing the fragment allocation.
+
+The network stack uses two separate caches per CPU to handle fragment
+allocation.  The netdev_alloc_cache is used by callers making use of the
+__netdev_alloc_frag and __netdev_alloc_skb calls.  The napi_alloc_cache is
+used by callers of the __napi_alloc_frag and __napi_alloc_skb calls.  The
+main difference between these two calls is the context in which they may be
+called.  The "netdev" prefixed functions are usable in any context as these
+functions will disable interrupts, while the "napi" prefixed functions are
+only usable within the softirq context.
+
+Many network device drivers use a similar methodology for allocating page
+fragments, but the page fragments are cached at the ring or descriptor
+level.  In order to enable these cases it is necessary to provide a generic
+way of tearing down a page cache.  For this reason __page_frag_cache_drain
+was implemented.  It allows for freeing multiple references from a single
+page via a single call.  The advantage to doing this is that it allows for
+cleaning up the multiple references that were added to a page in order to
+avoid calling get_page per allocation.
+
+Alexander Duyck, Nov 29, 2016.


  parent reply	other threads:[~2016-12-19 20:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-19 20:10 [Intel-wired-lan] [RFC PATCH 00/20] Enable the use of build_skb in igb/ixgbe Alexander Duyck
2016-12-19 20:10 ` [Intel-wired-lan] [RFC PATCH 01/20] mm: Rename __alloc_page_frag to page_frag_alloc and __free_page_frag to page_frag_free Alexander Duyck
2016-12-19 20:10 ` [Intel-wired-lan] [RFC PATCH 02/20] mm: Rename __page_frag functions to __page_frag_cache, drop order from drain Alexander Duyck
2016-12-19 20:10 ` Alexander Duyck [this message]
2016-12-19 20:11 ` [Intel-wired-lan] [RFC PATCH 04/20] igb: Add support for DMA_ATTR_WEAK_ORDERING Alexander Duyck
2016-12-19 20:11 ` [Intel-wired-lan] [RFC PATCH 05/20] igb: Use length to determine if descriptor is done Alexander Duyck
2016-12-19 20:11 ` [Intel-wired-lan] [RFC PATCH 06/20] igb: Limit maximum frame Rx based on MTU Alexander Duyck
2016-12-19 20:11 ` [Intel-wired-lan] [RFC PATCH 07/20] igb: Add support for padding packet Alexander Duyck
2016-12-19 20:11 ` [Intel-wired-lan] [RFC PATCH 08/20] igb: Add support for ethtool private flag to allow use of legacy Rx Alexander Duyck
2016-12-19 20:11 ` [Intel-wired-lan] [RFC PATCH 09/20] igb: Break out Rx buffer page management Alexander Duyck
2016-12-19 20:11 ` [Intel-wired-lan] [RFC PATCH 10/20] igb: Revert "igb: Revert support for build_skb in igb" Alexander Duyck
2016-12-19 20:11 ` [Intel-wired-lan] [RFC PATCH 11/20] ixgbe: Add function for checking to see if we can reuse page Alexander Duyck
2016-12-19 20:11 ` [Intel-wired-lan] [RFC PATCH 12/20] ixgbe: Only DMA sync frame length Alexander Duyck
2016-12-19 20:11 ` [Intel-wired-lan] [RFC PATCH 13/20] ixgbe: Update driver to make use of DMA attributes in Rx path Alexander Duyck
2016-12-19 20:12 ` [Intel-wired-lan] [RFC PATCH 14/20] ixgbe: Update code to better handle incrementing page count Alexander Duyck
2016-12-19 20:12 ` [Intel-wired-lan] [RFC PATCH 15/20] ixgbe: Make use of order 1 pages and 3K buffers independent of FCoE Alexander Duyck
2016-12-19 20:12 ` [Intel-wired-lan] [RFC PATCH 16/20] ixgbe: Use length to determine if descriptor is done Alexander Duyck
2016-12-19 20:12 ` [Intel-wired-lan] [RFC PATCH 17/20] ixgbe: Break out Rx buffer page management Alexander Duyck
2016-12-19 20:12 ` [Intel-wired-lan] [RFC PATCH 18/20] ixgbe: Add support for padding packet Alexander Duyck
2016-12-19 20:12 ` [Intel-wired-lan] [RFC PATCH 19/20] ixgbe: Add private flag to control buffer mode Alexander Duyck
2016-12-19 20:12 ` [Intel-wired-lan] [RFC PATCH 20/20] ixgbe: Add support for build_skb Alexander Duyck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161219201058.27116.89821.stgit@localhost.localdomain \
    --to=alexander.duyck@gmail.com \
    --cc=intel-wired-lan@osuosl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.