From owner-freebsd-current@FreeBSD.ORG Fri Sep 15 14:15:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B76416A403; Fri, 15 Sep 2006 14:15:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 627AE43D49; Fri, 15 Sep 2006 14:15:24 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8FEFBsp051211; Fri, 15 Sep 2006 10:15:11 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andre Oppermann Date: Fri, 15 Sep 2006 10:14:35 -0400 User-Agent: KMail/1.9.1 References: <20060915102228.GK27667@FreeBSD.org> <450A8467.5050405@freebsd.org> In-Reply-To: <450A8467.5050405@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609151014.36785.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Fri, 15 Sep 2006 10:15:12 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1885/Fri Sep 15 07:19:10 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: current@freebsd.org, freebsd-current@freebsd.org, Mike Tancsa , Ian FREISLICH , Gleb Smirnoff , Jack Vogel Subject: Re: TSO, SMP and the em driver. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2006 14:15:25 -0000 On Friday 15 September 2006 06:45, Andre Oppermann wrote: > Gleb Smirnoff wrote: > > On Wed, Sep 13, 2006 at 10:46:22AM -0500, Brooks Davis wrote: > > B> On Wed, Sep 13, 2006 at 11:08:44AM -0400, John Baldwin wrote: > > B> > On Tuesday 12 September 2006 19:14, Andre Oppermann wrote: > > B> > > Mike Tancsa wrote: > > B> > > > At 12:43 PM 9/12/2006, Andre Oppermann wrote: > > B> > > > > > B> > > >> TSO != (vlan && promisc) > > B> > > > > > B> > > > Sorry, the commonality I was referring to was VLAN hardware tagging and > > B> > > > how it must be enabled for TSO, but that breaks other things. See a few > > B> > > > messages ago > > B> > > > > > B> > http://lists.freebsd.org/pipermail/freebsd-current/2006-September/065818.html > > B> > > > > B> > > I'm sure we can find a workaround for that. > > B> > > > B> > Well, you could have the em(4) driver manually handle TSO in software, which > > B> > is what it does to workaround the VLAN tag problem. (It does VLAN > > B> > encapsulation in the driver.) While VLAN insertion may be trivial, > > B> > re-implementing TCP segmentation in the driver might be a good bit less > > B> > trivial to do. There's not going to be a simple easy workaround for this > > B> > hardware bug. :( > > B> > > B> I'm not sure it's worth worrying about with GbE hardware. Just disable > > B> TSO in promiscuous mode. Where TSO is going to really matter is 10GbE. > > B> No supporting TSO in some configurations with GbE doesn't seem like a > > B> big deal to me. > > > > Yes, makeing TSO and promisc mutually exclusive would be fine. > > There is no point in disabling TSO in when the card is in promisc mode. > Promisc mode only affects the receive path where TSO doesn't do a thing, > it is only used on the send path. The real fix is that the network stack including bpf(4) needs to be aware of VLANs that aren't stored in the packet data (mtag, mbuf header, wherever). If you fixed bridging and bpf to recoginize VLAN IDs in metadata and handle them then em(4) wouldn't need this hack. Also, if my understanding is correct, this hack is really needed for _any_ ethernet driver that supports vlan tagging in hardware unless we fix the stack consumers. -- John Baldwin