From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Alexander Duyck <alexander.duyck@gmail.com>,
netdev@vger.kernel.org, davem@davemloft.net,
jeffrey.t.kirsher@intel.com, Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH 2/2] net: Update alloc frag to reduce get/put page usage and recycle pages
Date: Thu, 12 Jul 2012 08:33:49 -0700 [thread overview]
Message-ID: <4FFEEE5D.7020305@intel.com> (raw)
In-Reply-To: <1342069601.3265.8218.camel@edumazet-glaptop>
On 07/11/2012 10:06 PM, Eric Dumazet wrote:
> On Wed, 2012-07-11 at 19:02 -0700, Alexander Duyck wrote:
>
>> The gain will be minimal if any with the 1500 byte allocations, however
>> there shouldn't be a performance degradation.
>>
>> I was thinking more of the ixgbe case where we are working with only 256
>> byte allocations and can recycle pages in the case of GRO or TCP. For
>> ixgbe the advantages are significant since we drop a number of the
>> get_page calls and get the advantage of the page recycling. So for
>> example with GRO enabled we should only have to allocate 1 page for
>> headers every 16 buffers, and the 6 slots we use in that page have a
>> good likelihood of being warm in the cache since we just keep looping on
>> the same page.
>>
> Its not possible to get 16 buffers per 4096 bytes page.
Actually I was talking about buffers from the device, not buffers from
the page. However, it is possible to get 16 head_frag buffers from the
same 4K page if we consider recycling. In the case of GRO we will end
up with the first buffer keeping the head_frag, and all of the remaining
head_frags will be freed before we call netdev_alloc_frag again. So
what will end up happening is that each GRO assembled frame from ixgbe
would start with a recycled page used for the previously freed
head_frags, the page will be dropped from netdev_alloc_frag after we run
out of space, a new page will be allocated for use as head_frags, and
finally those head_frags will be freed and recycled until we hit the end
of the GRO frame and start over. So if you count them all then we end
up using the page up to 16 times, maybe even more depending on how the
page offset reset aligns with the start of the GRO frame.
> sizeof(struct skb_shared_info)=0x140 320
>
> Add 192 bytes (NET_SKB_PAD + 128)
>
> Thats a minimum of 512 bytes (but ixgbe uses more) per skb.
>
> In practice for ixgbe, its :
>
> #define IXGBE_RXBUFFER_512 512 /* Used for packet split */
> #define IXGBE_RX_HDR_SIZE IXGBE_RXBUFFER_512
>
> skb = netdev_alloc_skb_ip_align(rx_ring->netdev, IXGBE_RX_HDR_SIZE)
>
> So 4 buffers per PAGE
>
> Maybe you plan to use IXGBE_RXBUFFER_256 or IXGBE_RXBUFFER_128 ?
I have a patch that is in testing in Jeff Kirsher's tree that uses
IXGBE_RXBUFFER_256. With your recent changes it didn't make sense to
use 512 when we would only copy 256 bytes into the head. With the size
set to 256 we will get 6 buffers per page without any recycling.
Thanks,
Alex
next prev parent reply other threads:[~2012-07-12 15:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-12 0:18 [PATCH 1/2] tcp: Fix out of bounds access to tcpm_vals Alexander Duyck
2012-07-12 0:18 ` [PATCH 2/2] net: Update alloc frag to reduce get/put page usage and recycle pages Alexander Duyck
2012-07-12 0:29 ` Eric Dumazet
2012-07-12 1:11 ` David Miller
2012-07-12 2:02 ` Alexander Duyck
2012-07-12 5:06 ` Eric Dumazet
2012-07-12 15:33 ` Alexander Duyck [this message]
2012-07-12 0:32 ` [PATCH 1/2] tcp: Fix out of bounds access to tcpm_vals David Miller
2012-07-12 1:46 ` 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=4FFEEE5D.7020305@intel.com \
--to=alexander.h.duyck@intel.com \
--cc=alexander.duyck@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).