[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090107130259.GB32336@ioremap.net>
Date: Wed, 7 Jan 2009 16:02:59 +0300
From: Evgeniy Polyakov <zbr@...emap.net>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Willy Tarreau <w@....eu>, Jens Axboe <jens.axboe@...cle.com>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
Jarek Poplawski <jarkao2@...il.com>
Subject: Re: Data corruption issue with splice() on 2.6.27.10
On Wed, Jan 07, 2009 at 11:57:34PM +1100, Herbert Xu (herbert@...dor.apana.org.au) wrote:
> On Wed, Jan 07, 2009 at 01:55:35PM +0100, Willy Tarreau wrote:
> >
> > kernel is 2.6.27.10 + a few patches (squashfs, etc..., nothing related to
>
> 2.6.27 will enable GSO by default if SG is enabled at registration
> time.
So even if later sg was turned off without gso being turned off, it
will try doing fair page transfer and not falling back to the copy.
The simplest case is to also turn gso off, but with older ethtools it is
not possible and you hit the bug.
If I understood correctly Jarek's patch, he wants to allocate a page and
copy linear content of the skb there, so this will end up being the same
case as with splicing from the file. And while generally this may be a
good idea, but with usual 1.5k mtu this will copy every skb, which is
rather bad idea. Will have to think :)
--
Evgeniy Polyakov
--
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