netdev - Re: [PATCH v2] tcp: splice as many packets as possible at once

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090203122715.GA9307@gondor.apana.org.au>
Date:	Tue, 3 Feb 2009 23:27:15 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Evgeniy Polyakov <zbr@...emap.net>
Cc:	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:18:36PM +0300, Evgeniy Polyakov wrote:
>
> I agree that this will work and will be better than nothing, but copying
> 9kb into 3 pages is rather CPU hungry operation, and I think (but have
> no numbers though) that system will behave faster if MTU is reduced to
> the standard one.

Reducing the MTU can create all sorts of problems so it should be
avoided if at all possible.  These days, path MTU discovery is
haphazard at best.  In fact MTU problems are the main reason why
jumbo frames simply don't get deployed.

> Another solution is to have a proper allocator which will be able to
> defragment the data, if talking about the alternatives to the drop.

Sure, if we can create an allocator that can guarantee contiguous
allocations all the time then by all means go for it.  But until
we get there, doing what I suggested is way better than stopping
the receiving process altogether.

> So:
> 1. copy the whole jumbo skb into fragmented one
> 2. reduce the MTU
> 3. rely on the allocator

Yes, improving the allocator would obviously inrease the performance,
however, there is nothing against employing both methods.  I'd
always avoid reducing the MTU at run-time though.

> For the 'good' hardware and drivers nothing from the above is really needed.

Right, that's why there is a point beyond which improving the
allocator is no longer worthwhile.

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