From owner-freebsd-net@FreeBSD.ORG Mon Feb 26 09:17:11 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 4579A16A401 for ; Mon, 26 Feb 2007 09:17:11 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id A795F13C474 for ; Mon, 26 Feb 2007 09:17:09 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 88888 invoked from network); 26 Feb 2007 08:50:30 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Feb 2007 08:50:30 -0000 Message-ID: <45E2A599.6020500@freebsd.org> Date: Mon, 26 Feb 2007 10:17:13 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Kip Macy References: <45E19B54.9060007@freebsd.org> <45E1A3B4.7090002@freebsd.org> <2a41acea0702252053v2357b5f5tefbcf58375be1a2f@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , Jack Vogel 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 09:17:11 -0000 Kip Macy wrote: >> 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? > > The stack will send down chains where pkthdr.len > 65536 bytes - I'm > also seeing it send down mbuf chains of 66 mbufs or more. I don't > think all cards can handle an arbitrary number of descriptors being > used for a single packet. Getting an mbuf chain with pkthdr.len > 65536 is a bug. Can you describe the test setup a bit more, eg. which programs do you use to generate the traffic? And can you instrument the driver to print the exact size of the oversized chains? I'm interested if it is just a few bytes more or generally overshoots by a larger margin. -- Andre