From owner-freebsd-hackers Sun Feb 21 23: 3:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id 865CA10E84 for ; Sun, 21 Feb 1999 23:02:52 -0800 (PST) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id CAA14944; Mon, 22 Feb 1999 02:09:40 -0500 From: Bill Paul Message-Id: <199902220709.CAA14944@skynet.ctr.columbia.edu> Subject: Re: How to handle jumbo etherney frames To: dg@root.com Date: Mon, 22 Feb 1999 02:09:38 -0500 (EST) Cc: hackers@freebsd.org In-Reply-To: <199902220110.RAA15394@implode.root.com> from "David Greenman" at Feb 21, 99 05:10:15 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2604 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, David Greenman had to walk into mine and say: > >Programming the chip to use a single vlan tag wouldn't require that much > >work. > > Whether to use a VLAN and/or which VLAN to use is a per destination thing, > not a per host/interface thing, so I don't think a single VLAN would be > very useful. Well, supposedly we have some vlan support code in /sys/net/if_vlan.c. What are the odds of getting this to work with for this purpose? > >I'm not really inclined to just implement only standard frame support > >and wait around for large mbuf cluster support to materialize since there's > >no telling how long that could take. I think I may be stuck between a > > Then implement large mbuf support. :-) That's not even remotely funny. All I want to do is write a device driver. That's enough work as it is. You're the principal architect; _you_ implement large mbuf support. > Using malloc for this is probably not a good idea since it wants to > allocate power of two sizes, so you'd needlessly waste a whole page. This > really needs a special allocator specifically designed to deal with the > needs of large mbuf clusters. Again, I think using the external mbuf storage > mechanism is the right way to glue this in. I'm not going to build a whole memory allocator/management subsystem into this driver. Until something else comes along, malloc() will have to do. > One other comment...when I was looking at this stuff I came to the > conclusion that supporting the Tigon 1 was a waste of time since it appears > to be obsolete. Support for just the Tigon 2 should simplify the driver. I disagree. The differences between the Tigon 1 and the Tigon 2 are not that extensive. The Tigon 1 doesn't support the mini receive ring, there are one or two commands that have changed, and you need to load a different firmware image, but for the most part operation is the same. I'd much rather be able to say that the driver supports both chip revs than save a few lines of code. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message