Hey everyone

Doug Ambrisko ambrisko at ambrisko.com
Fri Dec 2 01:18:18 GMT 2005


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 <glebius at freebsd.org>, Pyun YongHyeon
| <yongari at FreeBSD.org> and Scott Long <scottl at freebsd.org>.  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.


More information about the freebsd-net mailing list