From: David Miller <davem@davemloft.net>
To: eric.dumazet@gmail.com
Cc: ian.campbell@citrix.com, netdev@vger.kernel.org
Subject: Re: [PATCH 2/6] net: pad skb data and shinfo as a whole rather than individually
Date: Thu, 05 Jan 2012 14:13:31 -0500 (EST) [thread overview]
Message-ID: <20120105.141331.83457091828476806.davem@davemloft.net> (raw)
In-Reply-To: <1325785607.4759.12.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 05 Jan 2012 18:46:47 +0100
>> @@ -189,8 +189,7 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
>> * aligned memory blocks, unless SLUB/SLAB debug is enabled.
>> * Both skb->head and skb_shared_info are cache line aligned.
>> */
>> - size = SKB_DATA_ALIGN(size);
>> - size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
>> + size = SKB_DATA_ALIGN(size + sizeof(struct skb_shared_info));
>> data = kmalloc_node_track_caller(size, gfp_mask, node);
>> if (!data)
>> goto nodata;
>
> Unfortunately this makes the frequently use part of skb_shared_info not
> any more in a single cache line.
>
> This will slow down many operations like kfree_skb() of cold skbs (TX
> completion for example)
My concerns match Eric's here.
Ian, you state that you attempted to look into schemes that put the
destructor info somewhere other than skb_shared_info() and that none
of them worked well.
But what kind of issues do you run into if you add this into struct
page itself? Other subsystems could then use this facility too, and
if I recall there was even some talk of this.
next prev parent reply other threads:[~2012-01-05 19:13 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-05 17:09 [PATCH 0/6 v2] skb paged fragment destructors Ian Campbell
2012-01-05 17:13 ` [PATCH 1/6] net: pack skb_shared_info more efficiently Ian Campbell
2012-01-05 18:30 ` Eric Dumazet
2012-01-05 19:09 ` David Miller
2012-01-05 17:13 ` [PATCH 2/6] net: pad skb data and shinfo as a whole rather than individually Ian Campbell
2012-01-05 17:46 ` Eric Dumazet
2012-01-05 19:13 ` David Miller [this message]
2012-01-05 20:00 ` Ian Campbell
2012-01-07 18:18 ` David Miller
2012-01-05 19:19 ` Ian Campbell
2012-01-05 20:22 ` Eric Dumazet
2012-01-06 11:20 ` Ian Campbell
2012-01-06 12:33 ` Eric Dumazet
2012-01-06 13:20 ` Ian Campbell
2012-01-06 13:37 ` Eric Dumazet
2012-01-06 13:49 ` Ian Campbell
2012-01-06 13:29 ` Ian Campbell
2012-01-05 17:13 ` [PATCH 3/6] net: add support for per-paged-fragment destructors Ian Campbell
2012-01-06 1:15 ` Michał Mirosław
2012-01-06 8:50 ` Ian Campbell
2012-01-05 17:13 ` [PATCH 4/6] net: only allow paged fragments with the same destructor to be coalesced Ian Campbell
2012-01-05 17:13 ` [PATCH 5/6] net: add paged frag destructor support to kernel_sendpage Ian Campbell
2012-01-05 19:15 ` David Miller
2012-01-05 20:04 ` Ian Campbell
[not found] ` <1325783399.25206.413.camel-o4Be2W7LfRlXesXXhkcM7miJhflN2719@public.gmane.org>
2012-01-05 17:13 ` [PATCH 6/6] sunrpc: use SKB fragment destructors to delay completion until page is released by network stack Ian Campbell
2012-01-05 17:27 ` [PATCH 0/6 v2] skb paged fragment destructors David Laight
2012-01-05 17:34 ` 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=20120105.141331.83457091828476806.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=ian.campbell@citrix.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).