From: Alexei Starovoitov <ast@plumgrid.com>
To: Alexander Duyck <alexander.h.duyck@redhat.com>
Cc: Network Development <netdev@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [RFC PATCH 1/3] net: Split netdev_alloc_frag into __alloc_page_frag and add __napi_alloc_frag
Date: Wed, 26 Nov 2014 21:29:17 -0800 [thread overview]
Message-ID: <CAMEtUuxChWng-QFF=ziq=PLUkSZu1CD1brHUH9OHBg_4AL3FxQ@mail.gmail.com> (raw)
In-Reply-To: <20141127000557.1617.88261.stgit@ahduyck-vm-fedora20>
On Wed, Nov 26, 2014 at 4:05 PM, Alexander Duyck
<alexander.h.duyck@redhat.com> wrote:
> This patch splits the netdev_alloc_frag function up so that it can be used
> on one of two page frag pools instead of being fixed on the
> netdev_alloc_cache. By doing this we can add a NAPI specific function
> __napi_alloc_frag that accesses a pool that is only used from softirq
> context. The advantage to this is that we do not need to call
> local_irq_save/restore which can be a significant savings.
>
> I also took the opportunity to refactor the core bits that were placed in
> __alloc_page_frag. First I updated the allocation to do either a 32K
> allocation or an order 0 page. Then I also rewrote the logic to work from
> the end of the page to the start. By doing this the size value doesn't
> have to be used unless we have run out of space for page fragments.
> Finally I cleaned up the atomic bits so that we just do an
> atomic_sub_return and if that returns 0 then we set the page->_count via an
> atomic_set. This way we can remove the extra conditional for the
> atomic_read since it would have led to an atomic_inc in the case of success
> anyway.
Nice simplification. Complicated, but looks good to me.
I think only replacement of loop with 32k+page begs
better explanation in the commit log. I'm guessing you're
killing intermediate sizes to simplify the code?
Thank you for doing it. It's a great improvement.
next prev parent reply other threads:[~2014-11-27 5:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 0:05 [RFC PATCH 0/3] net: Alloc NAPI page frags from their own pool Alexander Duyck
2014-11-27 0:05 ` [RFC PATCH 1/3] net: Split netdev_alloc_frag into __alloc_page_frag and add __napi_alloc_frag Alexander Duyck
2014-11-27 5:29 ` Alexei Starovoitov [this message]
2014-11-27 0:06 ` [RFC PATCH 2/3] net: Pull out core bits of __netdev_alloc_skb and add __napi_alloc_skb Alexander Duyck
2014-11-27 0:06 ` [RFC PATCH 3/3] fm10k/igb/ixgbe: Use napi_alloc_skb Alexander Duyck
2014-11-27 12:00 ` [RFC PATCH 0/3] net: Alloc NAPI page frags from their own pool Jesper Dangaard Brouer
2014-12-03 3:30 ` David Miller
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='CAMEtUuxChWng-QFF=ziq=PLUkSZu1CD1brHUH9OHBg_4AL3FxQ@mail.gmail.com' \
--to=ast@plumgrid.com \
--cc=alexander.h.duyck@redhat.com \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--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 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.