intel checksum offload
pyunyh at gmail.com
Mon Sep 19 16:59:21 UTC 2011
On Mon, Sep 19, 2011 at 10:17:22AM -0400, Arnaud Lacombe wrote:
> On Mon, Sep 19, 2011 at 5:28 AM, Adrian Chadd <adrian at freebsd.org> 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
More information about the freebsd-hackers