Steven Stallion wrote: > Garrett D'Amore wrote: >> In a word: Yes. >> >> I don't know enough about the chipset., but I'd probably allocate more >> than 2, even, since you might be passed down a packet chain and don't >> want to have to putbq() the packets (or have GLDv3 do so for you). >> Although, pcnet isn't going to be fast in any case. :-) You have room >> for 40 1600 byte frames (not including descriptor overhead) -- I'd >> configure 16 frames in each direction -- experience with other NIC >> drivers has shown that such a configuration works well. If that's too >> many, maybe do 16 rx and 8 tx. > > That makes much more sense. The chipset uses 256 byte alignment, so > there could be a pretty fair bit of overhead for smaller packet chains. > > That said, would it make sense to use scatter/gather on the tx side, or > should I just treat it as a typical ring? Network traffic generally breaks down into two classes - big (payload-bearing) frames and small (ack-bearing) frames. The role of a host has a lot to do with the breakdown of big vs. small frames, but you really don't want to make drivers require tweaking to work acceptably in any given role. When hardware gives me the option of scatter/gather, I'll use it, though I'm much happier with 64-byte chunks rather than 256-byte chunks.
I once wrote a driver for the DP8390 for an experimental project, probably 12 years ago. The DP8390 doesn't offer the ability to do scatter/gather on transmit - the NIC requires a single contiguous frame for transmission. Correct? I'd keep two maxframe-sized transmit buffers, then. The DP8390 NIC, and those derived from it, had a double-handful of very annoying bugs; while the details don't spring to mind, I remember it was painful to get any decent performance out of the NIC. A quick search with Google is likely to shed some light on this. Given my recollections of the DP8390, I'd probably spend less time worrying about performance and more time worrying about stability ;-) Cheers, Dana _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
