From owner-cvs-src@FreeBSD.ORG Mon Jun 11 19:45:29 2007 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2888116A41F; Mon, 11 Jun 2007 19:45:29 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id F09D513C480; Mon, 11 Jun 2007 19:45:28 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.14.0/8.14.0) with ESMTP id l5BJjSVw026626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jun 2007 15:45:28 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id l5BJj0dh081289; Mon, 11 Jun 2007 15:45:00 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18029.42579.130017.451610@grasshopper.cs.duke.edu> Date: Mon, 11 Jun 2007 15:45:00 -0400 (EDT) To: Andre Oppermann In-Reply-To: <466DA400.6000003@freebsd.org> References: <200706111459.l5BExvTp020932@repoman.freebsd.org> <466D9BBB.1060601@freebsd.org> <466D9D94.1020908@samsco.org> <466DA400.6000003@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: cvs-src@freebsd.org, Scott Long , src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/sys mbuf.h src/sys/net if_ethersubr.c src/sys/dev/mxge mxge_lro.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2007 19:45:29 -0000 Andre Oppermann writes: > Scott Long wrote: > > Andre Oppermann wrote: > >> Andrew Gallatin wrote: > >>> gallatin 2007-06-11 14:59:56 UTC > >>> > >>> FreeBSD src repository > >>> > >>> Modified files: > >>> sys/sys mbuf.h sys/net > >>> if_ethersubr.c sys/dev/mxge mxge_lro.c Log: > >>> Allow drivers, such as cxgb and mxge, which support LRO to bypass > >>> the MTU check in ether_input() on LRO merged frames. > >>> Discussed with: kmacy > >> Not discussed with: andre > >> > >> Your change isn't the right way to make this work. LRO is an interface > >> capability (that should have the option to disable it) and the test in > >> ether_input() should go on that instead. LRO is not an information > >> that is needed beyond ether_input() and thus doesn't have to be a mbuf > >> flag. > >> > >> I've indicated that I'm working in this area as well and at least > >> dropping an email or a ping IRC would have been nice. I would have > >> told you the above right away. My common version of LRO isn't ready > >> yet as I'm a bit short on time and I chose to concentrate on TCP it- > >> self. We only have to make sure that we don't exclude a common LRO > >> implementation due to API/ABI issues for 7.1R. > >> > > > > Drew's commit looks simple and non-obtrusive enough that it can likely > > be replaced once your perfected LRO implementation is done and in the > > tree. Until that happens, I can't imagine a good reason to block his > > and Kip's work. > > I'm blocking nothing. Read again what I wrote. I complained about > a technically wrong approach to solve a particular side problem. In > the meantime it got backed out because someone else complained too. I specifically *didn't* make it an interface flag *because* of your promised generic LRO support. Ie, I didn't want to have any standard, documented interface to carry around for what is nothing more than a temporary hack to allow 10GbE with standard frames to not suck on FreeBSD in the short term. Per-driver LRO support is a nightmare that should be ripped out when your generic support is ready. I'm really looking forward to your work, and tried to keep the per-driver stuff as unobtrusive as possible. As to the other complaint, Sam complained about the scarcity of mbuf flags, not about LRO in general. We agreed that, since its basically a temporary hack, the best thing to do would be to move the frame length check under DIAGNOSTIC, where it should be anyway. FWIW, LRO triples receive performance for standard frames (3.xGb/s -> 9.3Gb/s) on decent hardware. Drew