From owner-freebsd-net@FreeBSD.ORG Fri Dec 2 01:18:18 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CF0016A41F; Fri, 2 Dec 2005 01:18:18 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA48D43D55; Fri, 2 Dec 2005 01:18:16 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 01 Dec 2005 17:18:16 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id jB21IGT9032895; Thu, 1 Dec 2005 17:18:16 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id jB21IGuu032894; Thu, 1 Dec 2005 17:18:16 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200512020118.jB21IGuu032894@ambrisko.com> In-Reply-To: <438D6FB9.FFBD8593@freebsd.org> To: Andre Oppermann Date: Thu, 1 Dec 2005 17:18:16 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, scottl@freebsd.org, Jack Vogel , yongari@freebsd.org Subject: Re: Hey everyone X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2005 01:18:18 -0000 Andre Oppermann writes: | Jack Vogel wrote: | | Dear Jack, | | > I wanted to introduce myself to the list. I am now the primary contact | > at Intel for our drivers. There was some earlier email I saw in the archive | > about 82571/2 support, and I want to confirm that that code is coming. | | for a too long time Intel has abandoned their direct involvement in | the FreeBSD 'em' driver. And you have two people with direct commit | rights to the FreeBSD CVS tree. | | In the meantime we have taken the driver maintainance into our own | hands, have rewritten parts of it and got a lot more conforming code. | Not to mention that we were able to increase the performance significantly | too. We have fixed many show-stopper bugs which were wedging the hardware | as well. ... and introduced a machine lock-up bug :-( Jack has a fix for it. So it works both ways. | Before you continue development on your own FreeBSD driver please have a | very close look the version we have in our CVS tree. You may benefit from | taking that as base and continue development from it instead of your own | code. The CVS commit messages explain in much detail which problems we | found and how we solved them. | http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/em/if_em.c | | Intel would help us a lot if you would release the Erratas to your 'em' | chip famility. I think you might be a little harsh. I think I understand where both sides are coming from. I know when I was at Vernier and Prafulla was maintaining things that he didn't take some cool changes that Sam Leffler did for us with jumbo packets so IPsec with HW crypto screamed. Since this was going to be hard for Intel to make backward compatible they didn't take the jumbo packet stuff with #ifdef mess. Now yes, Intel has been somewhat slow getting the latest greatest stuff into FreeBSD recently but in general it's a lot better then Broadcom. So we need to leverage their access to non-public documents and that Intel pays them to work on this stuff but not just for FreeBSD. I totally understand how things can get slowed down. At the company I work for that pays me to do FreeBSD work I have several FreeBSD fixes, patches and new stuff. Some is locked under NDA and can only be shared via those that have mutual NDA's. Other stuff is in a form good enough for our customers but not ready for FreeBSD. Also since our product is based on FreeBSD 4.X taking our fixes for that to FreeBSD -current -> 6 -> 5 -> 4 is a huge pain and the hacks that are okay to fix our problem and move on it not good enough for FreeBSD. Since I have to fight the next fire, I don't have the cycles to get to the point to commit. I wouldn't mind sharing the open code with people to help out (read people that can code things and not just test). Since it isn't complete I can't commit it to CVS. I guess I could use Perforce but that is yet another thing to deal with. Now I would have our work trees, Perforce and CVS repo's that add's even more work. It's almost getting to the point it is to hard to do work on FreeBSD! Now I'm sure we will be moving to FreeBSD 6 and things will get better for me. It was a good thing we didn't move to FreeBSD 5 or I'd have even more hassle. | > I hope to be adding some new feature support as well. I have been | > eyeing TSO which is going to need stack changes, if anyone out there | > has been working or just thinking about that get in touch with me about it. | | We have already looked into TSO a bit and so far the result is inconclusive. | We may not want to make any large changes to the TCP code to faciliate any | particular TSO architecture. To make the case in favor of supporting TSO | it has to be shown that is provides real-world benefits and extensive | benchmark results have to be provided. Any changes to our TCP code to | support TSO must be well designed and be generic supporting other vendors | TSO as well. However I must say that a really compelling has to be made | for TSO to justify the changes and the associated long term code maintainance | hurdles with it. | | Please have a look at this paper discussing TSO among other things: | | http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20TCP%20Stack.pdf Yes, I wonder the value of TSO and even HW crypto IPsec off-loading with IP stacks built in. Our network stack is very powerful and has lots of hooks into it that allow lots of things to be inter-mixed. I doubt HW offloading will permit the level of integration we have now. I've told various vendors that pitch this stuff no thanks. Usually most of it isn't open. | > In any case, I am kept quite busy but I will make every effort to be here | > and be as responsive as i can. | | Please get in contact with Gelb Smirnoff , Pyun YongHyeon | and Scott Long . Those folks have | assumed maintainership of the 'em' driver and contributed many important fixes | and performance enhancements. | | For the time being I guess it is the best if we collect the direct CVS | access of pdeuskar and tackerman and you submit patches to 'em' through | one of the above contacts at FreeBSD. I do agree that things should be consolidated. Let's give Jack some time to get up to speed since he seems really responsive. I think Jack coming on board is a good thing from what I've experienced so far with him. Intel in the past has accepted some bug fixes I sent to them so I don't think they totally ignore us. Doug A.