From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 18 21:06:44 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1C49106566B; Sun, 18 Sep 2011 21:06:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 86FD58FC15; Sun, 18 Sep 2011 21:06:44 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9E4C07300A; Sun, 18 Sep 2011 23:06:47 +0200 (CEST) Date: Sun, 18 Sep 2011 23:06:47 +0200 From: Luigi Rizzo To: Arnaud Lacombe Message-ID: <20110918210647.GA8930@onelab2.iet.unipi.it> References: <4E744BCE.7060302@sepehrs.com> <20110917203218.GC13993@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: jfv@freebsd.org, pyunyh@gmail.com, Hooman Fazaeli , freebsd-hackers@freebsd.org Subject: Re: intel checksum offload X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 21:06:44 -0000 On Sun, Sep 18, 2011 at 03:19:46PM -0400, Arnaud Lacombe wrote: > Hi, > > On Sat, Sep 17, 2011 at 4:32 PM, YongHyeon PYUN wrote: > > On Sat, Sep 17, 2011 at 11:57:10AM +0430, Hooman Fazaeli wrote: > >> Hi list, > >> > >> The data sheet for intel 82576 advertises IP TX/RX checksum offload > >> but the driver does not set CSUM_IP in ifp->if_hwassist. Does this mean that > >> driver (and chip) do not support IP TX checksum offload or the support for > >> TX is not yet included in the driver? ... > This is slightly off-topic, but still.. > > FWIW, I'm not really impressed by what chips claim to support vs. what > has been implemented in the driver. As per the product brief, the ... > [0]: the commit message say "performance was not good", but it is not > the driver's developer to decide whether or not a feature is good or > not. The developer's job is to implement the chip capabilities, and > let it to the user to enable or disable the capabilities. At best, the > developer can decide whether or not to enable the feature by default. actually, this is a perfect example where the developer has done the right thing: implemented the feature, verified that performance is bad, hence presumably removed support for the feature from the code (which also means that the normal code path will run faster because there are no run-time decisions to be made). "optional" features are often costly even when disabled. cheers luigi