From owner-freebsd-hackers Mon Feb 22 5:56:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (Postfix) with ESMTP id 1F24B10EB0 for ; Mon, 22 Feb 1999 05:56:13 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id FAA17708; Mon, 22 Feb 1999 05:53:19 -0800 (PST) Message-Id: <199902221353.FAA17708@implode.root.com> To: Bill Paul Cc: hackers@freebsd.org Subject: Re: How to handle jumbo etherney frames In-reply-to: Your message of "Mon, 22 Feb 1999 02:09:38 EST." <199902220709.CAA14944@skynet.ctr.columbia.edu> From: David Greenman Reply-To: dg@root.com Date: Mon, 22 Feb 1999 05:53:19 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> 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 think it's an almost orphaned child of Garrett's. You'll have to ask him about his plans for it. >> >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. Wimp! :-) >> 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. It should be external to the driver. I need to think about this some more. >> 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. Okay...sounds fine to me. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message