From: Alexander Duyck <alexander.duyck@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: eric.dumazet@gmail.com, alexander.h.duyck@intel.com,
netdev@vger.kernel.org, edumazet@google.com,
jeffrey.t.kirsher@intel.com
Subject: Re: [PATCH 2/2] tcp: cleanup tcp_try_coalesce
Date: Thu, 03 May 2012 00:08:55 -0700 [thread overview]
Message-ID: <4FA22F07.6060306@gmail.com> (raw)
In-Reply-To: <20120503.015018.1396745597972676005.davem@davemloft.net>
On 5/2/2012 10:50 PM, David Miller wrote:
> From: Alexander Duyck<alexander.duyck@gmail.com>
> Date: Wed, 02 May 2012 22:41:36 -0700
>
>> I think the part that has me confused is how being more precise about
>> removing from truesize gets in the way of detecting abuses of
>> truesize. It seems like it should be more as good as or better then
>> the original approach of just using skb->len.
> You can only trim from truesize if you can be absolutely certain that
> you have removed any reference in the fraglist, or the page'd head, to
> the entire "block" of data.
>
> If the skb still refers to even just one byte in a particular block,
> we must still charge the entire block in the truesize.
I get that, and that is what my code was doing that the old code wasn't
doing. That is why I am confused. I should have another patch ready in
an hour or so that should help to make my position clear.
> For example, NIU has three pools of power-of-2 blocks of data it
> maintainers and the device pulls from to build incoming packets.
>
> So if the chip used one of the 2048 byte buffers, we charge the entire
> 2048 bytes even of the packet is much smaller.
>
> Conversely this means we cannot trim the 2048 part of the truesize of
> that SKB unless we had some mechanism to know for certain 1) what the
> block size of the underlying data is and 2) that we've removed all
> references to that.
>
> Currently this is not really possible, so we therefore defer truesize
> adjustments.
This is true for the frags, but not for the head buffer allocated with
__alloc_skb or build_skb. For either of these we set both truesize and
the end pointer offset based on the ksize(data). The truesize is the
value plus SKB_DATA_ALIGNED(sizeof(struct sk_buff)), and the end pointer
offset is the value minus SKB_DATA_ALIGNED(sizeof(struct
skb_shared_info)). So in the case where we are removing the sk_buff and
skb->head, I am subtracting the end pointer offset plus the aligned
shared info and sk_buff values from skb->truesize to get the size of
just the paged region.
> Behaving otherwise is dangerous, because then we'd potentially end up
> with a lot of memory used, but not actually accounted for by anyone.
I fully agree that is why I was surprised when I was told not to use the
values for skb->truesize that were computed back when we allocated the
skb to determine the truesize to remove from the delta when we were
removing it.
Thanks,
Alex
prev parent reply other threads:[~2012-05-03 7:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-03 3:38 [PATCH 0/2] Cleanups for head_frag usage and tcp_try_coalese Alexander Duyck
2012-05-03 3:38 ` [PATCH 1/2] net: Stop decapitating clones that have a head_frag Alexander Duyck
2012-05-03 3:56 ` Eric Dumazet
2012-05-03 3:39 ` [PATCH 2/2] tcp: cleanup tcp_try_coalesce Alexander Duyck
2012-05-03 4:06 ` Eric Dumazet
2012-05-03 4:58 ` Alexander Duyck
2012-05-03 5:19 ` Eric Dumazet
2012-05-03 5:25 ` David Miller
[not found] ` <20120503.012502.44731688706812861.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2012-05-03 15:14 ` John W. Linville
2012-05-03 15:24 ` Guy, Wey-Yi
2012-05-03 17:07 ` John W. Linville
[not found] ` <20120503170727.GM9285-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
2012-05-03 20:21 ` Guy, Wey-Yi
2012-05-03 5:41 ` Alexander Duyck
2012-05-03 5:50 ` David Miller
2012-05-03 7:08 ` 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=4FA22F07.6060306@gmail.com \
--to=alexander.duyck@gmail.com \
--cc=alexander.h.duyck@intel.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).