[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20100920.095920.52212843.davem@davemloft.net>
Date: Mon, 20 Sep 2010 09:59:20 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: jarkao2@...il.com
Cc: eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next-2.6] net: pskb_expand_head() optimization
From: Jarek Poplawski <jarkao2@...il.com>
Date: Mon, 20 Sep 2010 07:21:49 +0000
> On Sun, Sep 19, 2010 at 05:17:25PM -0700, David Miller wrote:
>> We definitely don't use frag lists for performance, if you look
>> in the GRO history the GRO code specifically has been changed
>> to prefer accumulating into the page vector whenever possible
>> because using frag lists is a lot slower.
>
> Yes, and GRO made frag lists more popular btw.
Yes. However, realize that this is only really a legacy from
inet_lro.
These drivers could restructure themselves to operate on pages.
I am pretty sure the hardware would be amicable to this and it
would likely improve performance just as favoring page vector
accumulation did for GRO.
> Btw, I wonder what is the exact reason we can't use only
> NET_SKBUFF_DATA_USES_OFFSET?
As Eric explained, and then demonstrated, it generates a non-trivial
increased amount of code.
This is almost certainly why Arnaldo didn't make it unconditional
back when he implemented the SKB data offset changes for 64-bit.
In my opinion, this duality of SKB pointer handling never causes
real problems because any change mistakenly accessing the pointers
directly usually gets caught by the first person who builds it on
64-bit :-)
--
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