From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 19 01:45:56 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 0C7B71065672; Mon, 19 Sep 2011 01:45:56 +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 C3EAA8FC19; Mon, 19 Sep 2011 01:45:55 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id B2B707300A; Mon, 19 Sep 2011 04:01:31 +0200 (CEST) Date: Mon, 19 Sep 2011 04:01:31 +0200 From: Luigi Rizzo To: Arnaud Lacombe Message-ID: <20110919020131.GA11657@onelab2.iet.unipi.it> References: <4E744BCE.7060302@sepehrs.com> <20110917203218.GC13993@michelle.cdnetworks.com> <20110918210647.GA8930@onelab2.iet.unipi.it> 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: Mon, 19 Sep 2011 01:45:56 -0000 On Sun, Sep 18, 2011 at 06:05:33PM -0400, Arnaud Lacombe wrote: > Hi, > > On Sun, Sep 18, 2011 at 5:06 PM, Luigi Rizzo wrote: > > 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. > > > I forgot to mention that in this case, the code full of > EM_MULTIQUEUE's #ifdef and shared code is still fully compatible with > the multiqueue's architecture. The only thing removed is a conditional > and an assignation in the driver's attachment which was enabling the > feature, ie. the cost you point out is still paid today, without any > benefit. the above suggests that you have a wonderful opportunity: with just a little bit of time and effort you should be able to complete/re-enable the missing code, run tests that you believe significant (given your statement below) and prove or disprove the comment about performance. cheers luigi > > Now I might also openly question the test method used by the folks at > Intel, just seeing how much issue I've had with the driver (I still > have for some, even if not driver related), which have not been > reproduced there. > > Finally, when someone say "performance are better that way", the first > thing I'd be tempted to ask is: "What is your test ? How did you > collects the numbers ? How did you reach the conclusion ?". None of > this stuff is public. > regards, > - Arnaud