Date: Tue, 25 Jun 1996 21:56:00 -0400 (EDT) From: "Ron G. Minnich" <rminnich@Sarnoff.COM> To: JULIAN Elischer <julian@ref.tfs.com> Cc: hackers@FreeBSD.ORG Subject: Re: Frame relay and ATM support: virtual interface per vpi? Message-ID: <Pine.SUN.3.91.960625212948.28491B-100000@terra> In-Reply-To: <199606252247.PAA00954@ref.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> what do you mean "at the hardware"? MINI is an interface which has 4096 virtual atm interfaces, i.e. 4096 independent sets of control/status registers, memory buffers, and whatever else it takes to support this, at the hardware level. These resources are addressed on page boundaries. User programs can map in an individual interface and control it directly. There's a one-to-one correspondance between VCIs and virtual interfaces. VCI multiplexing is done in hardware, not in software, which is a fundamental difference from other atm interfaces. There's reasons for doing this outside the scope of this discussion, but let's just say it makes cluster computing a whole lot easier. You can get data from app-to-app in a few microseconds, a definite win as compared to the typical O(500 microseconds) you get from existing atm interfaces. The only nice way i've found to do this is to make each hardware mini interface have a corresponding 'if' structure. in practice i doubt very much to see more than a fraction of the virtual interfaces used, but you never know. I'm planning to allocate these structures dynamically. > I put it to you that there is only one driver running, with > one 'instance' of itself, and that there is only one > line to the outside, and one "packet's received" counter. That's an interesting question. If a user takes over a virtual interface, and the OS is basically out of the picture for that virtual interface, then where's the driver? in user mode? metaphysics ... > If you bring down the interface, they should all stop etc.etc. not necessarily. Depends on circumstances. > One might as well argue that ethjernet should be implimented by having > a separate virtual interface for every machine for which there is an > ARP table entry. No, one might as well not. Making a case for a virtual interface for each ATM VCI has no correspondance to an interface per arp table entry. Ethernet and atm are really very different, given the packet vs. vc model. You may find what i found, that trying to screw the vc model into the existing bsd net layer gets somewhat weird. To date, most companies selling software for atm have made the atm interface work like an ethernet interface, only a little different. Not a great idea, long term. anyway, MINI may be a little too far out for standard ATM world right now. I'll be doing this the way I outlined, and it may not fit in with whatever standard comes up. ah well, mini is pretty non-standard anyways. We like its non-standardness, though :-) ron
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.960625212948.28491B-100000>