[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090203121808.GA9218@gondor.apana.org.au>
Date: Tue, 3 Feb 2009 23:18:08 +1100
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Evgeniy Polyakov <zbr@...emap.net>
Cc: david@...g.hm, Jarek Poplawski <jarkao2@...il.com>,
David Miller <davem@...emloft.net>, w@....eu,
dada1@...mosbay.com, ben@...s.com, mingo@...e.hu,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
jens.axboe@...cle.com
Subject: Re: [PATCH v2] tcp: splice as many packets as possible at once
On Tue, Feb 03, 2009 at 03:12:19PM +0300, Evgeniy Polyakov wrote:
>
> It is a solution, but I think it will behave noticebly worse than
> with decresed MTU.
Not necessarily. Remember GSO/GRO in essence are just hacks to
get around the fact that we can't increase the MTU to where we
want it to be. MTU reduces the cost over the entire path while
GRO/GSO only do so for the sender and the receiver.
In other words when given the choice between a larger MTU with
copying or GRO, the larger MTU will probably win anyway as it's
optimising the entire path rather than just the receiver.
> That's the main point: how to deal with broken hardware? I think (but
> have no strong numbers though) that having 6 packets with 1500 MTU
> combined into GRO/LRO frame will be processed way faster than copying 9k
> MTU into 3 pages and process single skb.
Please note that with my scheme, you'd only start copying if you
can't allocate a linear skb. So if memory fragmentation doesn't
happen then there is no copying at all.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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