From owner-freebsd-net@FreeBSD.ORG Mon Feb 26 05:21:10 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9F4216A405 for ; Mon, 26 Feb 2007 05:21:10 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238]) by mx1.freebsd.org (Postfix) with ESMTP id 74B4713C491 for ; Mon, 26 Feb 2007 05:21:10 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1159051wxc for ; Sun, 25 Feb 2007 21:21:09 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UtMyQBxpbcySV40OK4SE9bve8+9zjZcNyelmWLG2kJdxmhy046DAmCZGEKzBc8fYCJi0nxUCd4nVbVWNNkRi1fahZlS+1Dm2QUIDh+Vtp6d1tW5kX8iCCAdGg2zK+Ob8kPdVwR+UfkhUa4XlgsLQDIjBQo58uzt04B4ma/qofe8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O7tVPQD9HwJE1yBQt/HI9vHj1LNzVXf4qzw7Sn2LA6Tiyy2fJTfyyIjm8ubB3rzw9UUi2ND/NitMfb8jstWgk/9yhMsKgG2/cyj9lzVvQjtmPpVEuWd48DONff24URera5y+XfHFqrOfmxfNMuWdixEgtrXgEqwv0LKBPpr1zYU= Received: by 10.114.13.1 with SMTP id 1mr515025wam.1172465616664; Sun, 25 Feb 2007 20:53:36 -0800 (PST) Received: by 10.114.103.15 with HTTP; Sun, 25 Feb 2007 20:53:36 -0800 (PST) Message-ID: <2a41acea0702252053v2357b5f5tefbcf58375be1a2f@mail.gmail.com> Date: Sun, 25 Feb 2007 20:53:36 -0800 From: "Jack Vogel" To: "Andre Oppermann" In-Reply-To: <45E1A3B4.7090002@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45E19B54.9060007@freebsd.org> <45E1A3B4.7090002@freebsd.org> Cc: Kip Macy , freebsd-net Subject: Re: improved TSO interface needed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2007 05:21:10 -0000 On 2/25/07, Andre Oppermann wrote: > Kip Macy wrote: > > On 2/25/07, Andre Oppermann wrote: > >> Kip Macy wrote: > >> > Evidently FreeBSD violates the LSO spec by sending down up to socket > >> > buffer sized TSO segments to the network card. Is there a way to set > >> > this other than reducing net.inet.tcp.sendbuf_max to a compliant value > >> > (64k)? And is there a way to for a device to communicate to the stack > >> > the maximum length of an mbuf chain? > >> > >> From netinet/ip_output.c: > >> > >> * When doing TSO limit a burst to TCP_MAXWIN minus the > >> * IP, TCP and Options length to keep ip->ip_len from > >> * overflowing. Prevent the last segment from being > >> * fractional thus making them all equal sized and set > >> * the flag to continue sending. > >> > >> TCP_MAXWIN is 64K. > > > > It is good to know that this how it is supposed to work even if it > > doesn't. You didn't directly answer my last question, since they're > > all supposed to be equal does that mean the max should be 32? > > The current TSO code will send mbuf chains of up to 64K (minus headers) > to be split into MSS sized packets as specified by mbuf packet header > usually resulting in an MTU of 1500 bytes. > > There is no way at the moment to tell the stack to send shorter mbuf > chain while still using TSO. > > A google search for "LSO" doesn't yield any useful answers. The stack > doesn't send socket buffer sized mbuf chains if it larger than 64K. > > Can you explain the problem you're seeing in more details perhaps? That'd > certainly help in finding a fix for your problem. LSO is MicroSlop's term for TSO :) As usual, they rename it, and next they do something non-standard to er 'differentiate' as the euphemism goes... Kinda what Sun's lawsuit back in the 90s against their Java strategy was all about :) Nevertheless, I don't understand Kip either, when we do TSO there is no evidence on the wire, it still has MTU sized packets. I fail to see why I should care about some LSO spec, what does it break? Jack