From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 19 16:59:21 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 7FF09106564A; Mon, 19 Sep 2011 16:59:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 21C5C8FC13; Mon, 19 Sep 2011 16:59:21 +0000 (UTC) Received: by iadk27 with SMTP id k27so8665010iad.13 for ; Mon, 19 Sep 2011 09:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=jT1fcJroGTrjUuPTrNeGabuPhWmjhOVx59dpaVyhEJg=; b=UNj5qqOYwwwWjLhYA88rS8/TuU34a/BtdMoLlpx2D1DiU9JjYl0JZ7xQe5NzM9jW8i 0C0s72DLP9geCq00Gj9RSYhTcuUySacRN4Ltb6GDv2vxavd8B4DlwOEXboxCF5+pstXn kcbL/d1PMxngaFqfo085ggrSYDbvH3CH5RIes= Received: by 10.231.63.136 with SMTP id b8mr4498229ibi.43.1316451560571; Mon, 19 Sep 2011 09:59:20 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id z11sm26459737iba.6.2011.09.19.09.59.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Sep 2011 09:59:18 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 19 Sep 2011 09:59:20 -0700 From: YongHyeon PYUN Date: Mon, 19 Sep 2011 09:59:20 -0700 To: Arnaud Lacombe Message-ID: <20110919165920.GA4202@michelle.cdnetworks.com> References: <20110917203218.GC13993@michelle.cdnetworks.com> <20110918210647.GA8930@onelab2.iet.unipi.it> <20110919020131.GA11657@onelab2.iet.unipi.it> <4E76E5B9.9080301@sepehrs.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: Adrian Chadd , freebsd-hackers@freebsd.org, Hooman Fazaeli , Jack Vogel , jfv@freebsd.org, Luigi Rizzo Subject: Re: intel checksum offload X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com 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 16:59:21 -0000 On Mon, Sep 19, 2011 at 10:17:22AM -0400, Arnaud Lacombe wrote: > Hi, > > On Mon, Sep 19, 2011 at 5:28 AM, Adrian Chadd wrote: > > Arnaud (and others), > > > > Liaising with vendors is not an easy task. The reason why Intel (and > > other vendors) don't supply detailed history and reasoning for their > > development efforts is that their engineers are likely tasked with > > "making it work" versus "writing lots of stuff down for public > > release." In some instances, the vendor support of FreeBSD (and "free" > > open source in general) is done as a side-project by some of the > > engineers inside the company. > > > > So in this case, you may find that Jack and the other engineers at > > Intel just don't have the time or resources to dedicate the kinds of > > feedback and support you seem to be after. He and others likely have a > > huge set of tasks to do at work and none of them officially include > > "support FreeBSD/Linux developers by providing detailed feedback and > > assistance." So whenever Jack pops up to help out, he's likely doing > > it in his spare time. :-) > > > Yes, and he seems to really like to waste his spare time by repeating > me for two months to increase `kern.ipc.nmbclusters' to fix issue I > was seeing, when the code was clearly buggy, even when I sent him > patchs fixing issues. > If you think you encountered a driver bug, could you share it with us? I didn't closely follow em(4)/lem(4)/igb(4) changes for a long time so I'm not sure whether I can come up with reasonable fix for the issue but I may be able to help you. > That's sure a very efficient way of managing time. > > - Arnaud > > > Developers can and will disable or remove functionality which is > > problematic because they don't have the time or resources to support > > it. Users may wish to turn on unsupported features and then will > > complain loudly when they don't work; even giving up and moving to > > another piece of equipment because of perceived issues. I agree that > > it would be nice if the developers included _all_ features, > > unsupported or not, so that developers can choose to work on them if > > they wish. It however is a trade-off between trying to provide > > developers with more useful things to tinker with and not increasing > > support load from users (and other developers) who seek to use > > incomplete features. > > > > I hope this helps. > > > > > > Adrian > >