M-VIA Design
M-VIA Architecture
The VI Architecture Specification describes VIA as being composed
of three main components: the VI Provider Library (VIPL); the VI Kernel
Agent; and VI NICs. M-VIA further abstracts the Kernel Agent into
the M-VIA Kernel Agent and one or more M-VIA Device Drivers. A VI Kernel
Agent for specific hardware is realized by the combination
of the M-VIA Kernel Agent and the M-VIA Device Driver for the hardware.
M-VIA Kernel Agent
The M-VIA Kernel Agent performs privileged operations on behalf
the VI Provider Library and assists M-VIA Device Drivers with
operations requiring operating system support.
The M-VIA Kernel Agent is divided into the following device independent
functional components:
- Connection Manager
Establishes logical point-to-point connections between VIs.
- Protection Tag Manager
Allocates, deallocates, and validates memory protection tags (Ptags).
- Registered Memory Manager
Handles the registration of user communication buffers and descriptor
buffers.
- Error Queue Manager
Provides a mechanism for posting asynchronous errors by VIA devices
and blocking
- Kernel Extensions
Provides functionality required for efficient implementation.
M-VIA Device Drivers
An M-VIA Device Driver is an abstraction of a VI NIC, and registers
itself with the M-VIA Kernel Agent. The device informs the Kernel Agent
of its capabilities, such
as whether it supports VIA directly in hardware, its native MTU size, the
maximum number of VIA descriptors that can be queued for transmission,
etc. The device also registers device specific functions to be used by the
modular managers of the Kernel Agent layer. The developer of the M-VIA
Device Driver has the
option of overriding any and all of the default functionality provided by the
M-VIA Kernel Agent layer. For example, if a device which provides native VIA
hardware support uses its own mechanism for registering memory, it may
completely replace the Registered Memory Manager with an implementation of
its own. The ability to override all of the default functionality of the
M-VIA Kernel Agent layer should allow any natively supported or software
emulated VIA device to be supported by M-VIA. However, it is conceivable that
a device with native hardware support for VIA which deviates from the
recommendations in the VI Architecture Specification would not be supported.
Device Classes
Many commodity network interfaces can be logically grouped into common
categories such as Ethernet, ATM, FDDI, etc. In order to promote wire level
interoperability and rapid development through code reuse, Modular VIA
employs the use of Device Classes. M-VIA uses slightly finer-grained
classes than network types, such as the EtherRing category mentioned above.
Device Classes enable common routines for a class of network interfaces to be
shared by KAD implementations. Such routines include operations like the
construction and interpretation of media specific VIA headers and
mechanisms for enabling VIA to co-exist with traditional networking
protocols, i.e. TCP/IP. While Device Classes are not explicitly supported by
the M-VIA Device Driver layer, the Device Driver layer is designed to
facilitate the use of such classes. Macros are used for communication
between a KAD implementation and a device class, and these are integrated
into a single loadable kernel module.
VI Provider Library
M-VIA contains a single VI Provider Library, which is interoperable with
native hardware and software VIA devices developed within the Modular
VIA framework. M-VIA Kernel Agent Drivers specify whether ioctl system calls
or fast traps are used by the VI Provider Library to call time-sensitive
VI Kernel Agent services. M-VIA Device Drivers also specify weather the
VIA Doorbell mechanism is supported directly in hardware as a true memory
mapped doorbell or should be emulated with a fast trap.
M-VIA 1.0. Fri, 17 Sep 1999 09:13:43 -0700.
Copyright (C) 1998,1999 Berkeley Lab.