Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Feb 1999 02:09:38 -0500 (EST)
From:      Bill Paul <wpaul@skynet.ctr.columbia.edu>
To:        dg@root.com
Cc:        hackers@freebsd.org
Subject:   Re: How to handle jumbo etherney frames
Message-ID:  <199902220709.CAA14944@skynet.ctr.columbia.edu>
In-Reply-To: <199902220110.RAA15394@implode.root.com> from "David Greenman" at Feb 21, 99 05:10:15 pm

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902220709.CAA14944>