[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 04 May 2012 23:51:33 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
CC: Alexander Duyck <alexander.h.duyck@...el.com>,
netdev@...r.kernel.org, davem@...emloft.net,
jeffrey.t.kirsher@...el.com
Subject: Re: [PATCH 0/3] First pass of cleanups for pskb_expand_head
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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists