From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 19 04:55:05 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 405011065672 for ; Mon, 19 Sep 2011 04:55:05 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id B3B1E8FC12 for ; Mon, 19 Sep 2011 04:55:04 +0000 (UTC) Received: by wwn22 with SMTP id 22so3279275wwn.1 for ; Sun, 18 Sep 2011 21:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4edGWcBwq9m9yS5QNvNsp4r6+qufz8HH1NdHhje5toQ=; b=mlxv2Crc2IchegHTN9PE62cQzDWU0aqc8efJQcyEjfj1daEJMJsfuhd/y0ZiAY5vYV loDNAcE9zguWty0UmYcSzbbmu2GTsgvc8WCGxCBzT6ZNG7/SKJfiQTH9TNZSaTjnq6bx 3QF+6++3NY2jFH9ASrrJwWdPiHFYI0yobC0zE= MIME-Version: 1.0 Received: by 10.227.201.130 with SMTP id fa2mr1251623wbb.13.1316406568313; Sun, 18 Sep 2011 21:29:28 -0700 (PDT) Received: by 10.180.106.35 with HTTP; Sun, 18 Sep 2011 21:29:28 -0700 (PDT) In-Reply-To: References: <4E744BCE.7060302@sepehrs.com> <20110917203218.GC13993@michelle.cdnetworks.com> <20110918210647.GA8930@onelab2.iet.unipi.it> <20110919020131.GA11657@onelab2.iet.unipi.it> Date: Sun, 18 Sep 2011 21:29:28 -0700 Message-ID: From: Jack Vogel To: Arnaud Lacombe X-Mailman-Approved-At: Mon, 19 Sep 2011 10:55:34 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: jfv@freebsd.org, pyunyh@gmail.com, Hooman Fazaeli , Luigi Rizzo , 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 04:55:05 -0000 On Sun, Sep 18, 2011 at 7:48 PM, Arnaud Lacombe wrote: > Hi, > > On Sun, Sep 18, 2011 at 10:01 PM, Luigi Rizzo wrote: > > 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. > > > Which I did about a week ago, to finally discover that the NIC only > had only 3 MSI-X vectors configured in its EEPROM[0], and thus the > MSI-X PCI capability field ends up also with being assigned with those > 3 vectors. However, the 82574 datasheet clearly say that up-to 5 > vector can be configured, but I obviously did not find the magic trick > to make it so. Maybe I'll find some time and try to reprogram the > EEPROM. Beside that, it was clear that the old multiqueue did not > support only 3 vector being available and thus fell back on MSI. It is > not clear in jfv@'s comment whether he really tested multiqueue, or > did he test the fall-back MSI mode. > > As the PCI spec is not public, I've not been able to find out from the > few public datasheet how the PCI MSI-X capability field is first > programmed. I'd assume that the BIOS is using the data in the NVM to > program it at power up. > > - Arnaud > > [0]: at least, the MSI_X_NUM field of the NVM at offset 0x1b is 2, > thus 3 vectors. > I give answers to those who treat me with respect, I view them as collaborators, we improve the drivers for everyone's benefit, rather than jumping in to throw a critical remark here, a negative innuendo there... If you notice, the Linux driver did not enable multiqueue on the hardware either, so do you think a whole department of software engineers backed by the hardware engineers who designed the damn thing might have had a reason? IN FACT, as I have a bit more freedom with FreeBSD, I went ahead and tried it for a while just because I could, implementing the code was not difficult. Over time however that code proved to be a source of instability and thus was disabled. I have heard a rumor that the Linux crew may actually be trying a second time to make it work, and that might give me cause to look at it again too, but its not clear if I'll have time with other priorities. Jack