From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757575AbZBDTTk (ORCPT ); Wed, 4 Feb 2009 14:19:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757574AbZBDTTM (ORCPT ); Wed, 4 Feb 2009 14:19:12 -0500 Received: from sj-iport-1.cisco.com ([171.71.176.70]:36193 "EHLO sj-iport-1.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755620AbZBDTTK (ORCPT ); Wed, 4 Feb 2009 14:19:10 -0500 X-IronPort-AV: E=Sophos;i="4.37,380,1231113600"; d="scan'208";a="137851383" From: Roland Dreier To: Willy Tarreau Cc: David Miller , herbert@gondor.apana.org.au, zbr@ioremap.net, jarkao2@gmail.com, dada1@cosmosbay.com, ben@zeus.com, mingo@elte.hu, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, jens.axboe@oracle.com Subject: Re: [PATCH v2] tcp: splice as many packets as possible at once References: <20090204081201.GB10445@ioremap.net> <20090204085432.GA21638@1wt.eu> <20090204085907.GA19388@gondor.apana.org.au> <20090204.010146.18100191.davem@davemloft.net> <20090204091217.GA21385@1wt.eu> X-Message-Flag: Warning: May contain useful information Date: Wed, 04 Feb 2009 11:19:06 -0800 In-Reply-To: <20090204091217.GA21385@1wt.eu> (Willy Tarreau's message of "Wed, 4 Feb 2009 10:12:17 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 04 Feb 2009 19:19:07.0112 (UTC) FILETIME=[7301DE80:01C986FD] Authentication-Results: sj-dkim-4; header.From=rdreier@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > And the arbitrary choice of 9k for jumbo frames was total crap too. > It's clear that no hardware designer was involved in the process. > They have to stuff 16kB of RAM on a NIC to use only 9. And we need > to allocate 3 pages for slightly more than 2. 7.5 kB would have been > better in this regard. 9K was not totally arbitrary. The CRC used for checksumming ethernet packets has a probability of undetected errors that goes up about 11-thousand something bytes. So the real limit is ~11000 bytes, and I believe ~9000 was chosen to be able to carry 8K NFS payloads + all XDR and transport headers without fragmentation. - R.