Date: Mon, 22 Feb 1999 05:53:19 -0800 From: David Greenman <dg@root.com> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: hackers@freebsd.org Subject: Re: How to handle jumbo etherney frames Message-ID: <199902221353.FAA17708@implode.root.com> In-Reply-To: Your message of "Mon, 22 Feb 1999 02:09:38 EST." <199902220709.CAA14944@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902221353.FAA17708>