From owner-freebsd-current@FreeBSD.ORG Thu Nov 10 19:30:44 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 1BB5716A420; Thu, 10 Nov 2005 19:30:44 +0000 (GMT) In-Reply-To: <200511092237.19062.kirk@strauser.com> from Kirk Strauser at "Nov 9, 2005 10:37:14 pm" To: kirk@strauser.com (Kirk Strauser) Date: Thu, 10 Nov 2005 19:30:44 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20051110193044.1BB5716A420@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: freebsd-current@freebsd.org Subject: Re: Generic Kernel API X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2005 19:30:44 -0000 > On Wednesday 09 November 2005 15:23, Charles Swiger wrote: > > > Of course, it's easier to say such things then to write the code, but > > Apple has achieved pretty good results from the IOKit. > > I'm really out of my depth here, but the one thing Apple seems to have > accomplished with IOKit is abysmal performance. When it no longer takes me > four times longer to backup an iMac than a much slower FreeBSD machine with > an older drive, I'll be more impressed with their technology. > -- > Kirk Strauser When Apple was working on the second generation Airport wireless access points, I and a cow-orker ended up taking a trip to the Apple campus to help debug a problem (they were using VxWorks). In some cases it was possible to crash the access point, though you had to flood it with a lot of traffic to do it. The engineer working on the device had a nice Apple laptop in his office which he was using as a traffic monitor and generator to debug the issue. I arrived armed with my trusty Sony VAIO Picturebook, which uses a Transmeta Crusoe TM5600 667Mhz CPU. I'm pretty sure the Apple laptop had way more CPU horsepower than this. Anyway, the engineer there had been trying to use his laptop to generate a flood of traffic to crash the AP (reproducing a crash is the first step to fixing it), but wasn't able to do it very reliably. For the most part, the AP stubbornly refused to die. So I took out my laptop (with FreeBSD 5.2.1, of all things), plugged in my 3Com xl(4) ethernet card, and ran ttcp to generate a stream of UDP traffic. I was able to crash the AP almost right away. Now, I realize that IOKit looks really neat on paper and conceptually has lots of nice advantages, but in practice I think it has performance problems. I'm sure you can get a Mac to saturate a 100Mbps ethernet link with a TCP stream test, but with that test you'll only end up producing about 8000 frames/second, which really doesn't need that much CPU power. It's when you need to generate 80000 or 100000 frames/second that you start running into problems. Also, while code re-use seems like a laudable goal, you have to be careful how you do it. I don't think there's much difference in the amount of code re-use between an IOKit driver and a standard BSD ifnet network driver. Take a look any any given driver, and while the code may appear to share many structural similarities, it's actually quite different, because the underlying hardware is different. You can abstract away certain machine specific things, like DMA and register access (which we do with busdma and bus_space), but you can't easily create common code for DMA descriptor setup, interrupt handling, chip initialization and so on, because all each chip has different descriptor formats, and interrupt signalling/masking mechanisms and initialization procedures. You have to avoid falling into the trap of thinking you can generalize these things just because you may have found one or two cards/chipsets that look kind of the same. There's another issue, which I think has already become a problem with Windows, which is that there's such a thing as insulating driver developers too much from the underlying OS. As was said earlier in this thread, network and storage are probably the most critical types of driver classes. The more network cards and disk controllers you support, the better. For network adapters, Microsoft has the NDIS miniport API. For disks, they have the storport and scsiport miniport APIs. Behind the scenes, these miniport libraries all use the Windows Driver Model (WDM) which encompasses such things as the I/O manager, IRPs and the Plug&Play manager, but those APIs are very complicated and easy to screw up (IRPs especially), so Microsoft recommends using the NDIS, storport or scsiport APIs instead. In fact, I think you're forbidden to stray outside the scsiport/storport API at all if you want to get your driver WHQL certified and signed (the rules are a little less strict with NDIS because you need to use WDM for things like USB network adapters). That's fine and all, but I think what you end up with is developers who know how to use the particular miniport API that concerns them, but who _don't_ know much about the underlying OS in general, which I think is a _bad_ thing. You _want_ to know how the underlying OS works, because that can help you understand why the miniport library layered on top of the other OS facilities does what it does. You can probably get by without that understanding, but if you did, I wouldn't by a NIC with a driver you wrote. :) -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose =============================================================================