From: Alexander Duyck <alexander.duyck@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Alexander Duyck <alexander.h.duyck@intel.com>,
netdev@vger.kernel.org, davem@davemloft.net,
jeffrey.t.kirsher@intel.com
Subject: Re: [PATCH 0/3] First pass of cleanups for pskb_expand_head
Date: Fri, 04 May 2012 23:51:33 -0700 [thread overview]
Message-ID: <4FA4CDF5.3070208@gmail.com> (raw)
In-Reply-To: <1336196671.3752.490.camel@edumazet-glaptop>
On 5/4/2012 10:44 PM, Eric Dumazet wrote:
> On Fri, 2012-05-04 at 17:26 -0700, Alexander Duyck wrote:
>> pull the actual value.
>>
>> There are a few more items that I will try to get to next week. The big one
>> is the fact that pskb_expand_head can mess up the truesize since it can
>> allocate a new head but never updates the truesize. I plan on adding a helper
>> function for the cases where we are just using it unshare the head so I can
>> identify the places where we are actually modifying the size.
> In the old days, truesize adjustements were done after
> pskb_expand_head() calls. (Mabye because some contexts didnt care of
> truesize for ephemeral skbs, not charged to a socket)
>
> So it will be a nice cleanup for sure.
I suspect the reason for no truesize adjustment is because this function
gets called in the transmit path, and we probably should be adjusting
truesize while there is still a desctructor in place that will turn
around and subtract the truesize from the socket memory. I'm still
thinking about what would be the best solution to that, but in the
meantime I figure I can at least add a helper function to handle all the
pskb_expand_head(skb, 0, 0, GFP_ATOMIC) cases and just replace them with
something like skb_unshare_head(skb). That way I will have a better
idea of the few cases where we might actually impact truesize.
prev parent reply other threads:[~2012-05-05 6:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-05 0:26 [PATCH 0/3] First pass of cleanups for pskb_expand_head Alexander Duyck
2012-05-05 0:26 ` [PATCH 1/3] skb: Drop bad code from pskb_expand_head Alexander Duyck
2012-05-05 5:35 ` Eric Dumazet
2012-05-06 17:13 ` David Miller
2012-05-05 0:26 ` [PATCH 2/3] skb: Drop "fastpath" variable for skb_cloned check in pskb_expand_head Alexander Duyck
2012-05-05 5:37 ` Eric Dumazet
2012-05-06 17:13 ` David Miller
2012-05-05 0:26 ` [PATCH 3/3] skb: Add inline helper for getting the skb end offset from head Alexander Duyck
2012-05-05 5:39 ` Eric Dumazet
2012-05-06 17:13 ` David Miller
2012-05-05 5:44 ` [PATCH 0/3] First pass of cleanups for pskb_expand_head Eric Dumazet
2012-05-05 6:51 ` Alexander Duyck [this message]
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=4FA4CDF5.3070208@gmail.com \
--to=alexander.duyck@gmail.com \
--cc=alexander.h.duyck@intel.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 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).