MIME-Version: 1.0 Server: CERN/3.0 Date: Sunday, 01-Dec-96 19:21:08 GMT Content-Type: text/html Content-Length: 10196 Last-Modified: Monday, 06-May-96 15:04:08 GMT Project Report: U-Net Kernel Endpoint

CS516 HIGH PERFORMANCE COMPUTER ARCHITECTURE

Final Project : Kernel Endpoint for U-Net

March 28 - May 2, 1996

Ankit Patel and Gerry Toll

{apatel@cs.cornell.edu, gtoll@tc.cornell.edu}



Project Description

Kernel Endpoint for U-Net

One drawback of U-Net is that it doesn't allow existing applications and kernel facilities (e.g. TCP/IP) to easily share the underlying network hardware with U-Net based user-level applications. There are at least two ways that this problem can be solved.

One idea is to implement the required services through a library of user level functions that use U-Net as the transport mechanism. Another approach is to actually construct an endpoint inside of the kernel, and allow it to access the network hardware via the U-Net device driver. We decided on the latter because in the long run, it should provide more flexibility than the library-based implementation. Once the kernel endpoint is in place, any type of data can be transmitted across the network, regardless of protocol. Additionally, we may even be able to communicate with non-U-Net hosts if we're careful about using compatible header formats. Our idea is to take advantage of the "virtual network interface" provided by the U-Net driver and to treat it as a real network card inside of the kernel.

While any communication using the kernel endpoint will no doubt be slower than user-level endpoints, the idea is to allow many applications to multiplex on one kernel endpoint and for existing socket-based apps to at least run.The idea is not to implement IP or other high-level protocols; but essentially to replace the low-level kernel functions for sending data to an ATM or Ethernet card with routines which read/write to the kernel endpoint.

Project milestones

March 28 : Project Proposal

We have met with Matt Welsh to get a better idea of what this project will involve. We believe that the best platform for this project will be on a PC running Linux, using Fast Ethernet hardware. Ideally, the abstraction provided by U-Net should allow our code to also work across the ATM hardware, but whether this proves to be true remains to be seen and is beyond the scope of this project. If time permits, this would be a natural extension to our work. It is our understanding that the basic idea of this project is to provide the ability for the kernel to access the U-Net interface via the already written U-Net driver. We will therefore be writing code to bridge the gap between IP and the U-Net device driver.

Our understanding through diagrams : A look at the Network Architectures

April 18 : Checkpoint Meeting

Setup of hardware - Two pentium PCs are interconnected through Fast Ethernet, using a null modem.
Setup of software - Linux as well as U-Net software is loaded on the machines, the Kernel code has been compiled.
The U-Net pingpong application has been tested to run properly, however, sometimes CRC errors are received which are possibly due to absence of Fast Ethernet Hub and also, the expected latency is not obtained.

With this basic setup, we have divided the project into two basic parts, so that each of us can concentrate on one of them,
(1) kendpt-lib : a kernel-level implementation of devtulip and libunet.
(2) kendpt-dev : a pseudo-ethernet driver that is implemented using kendpt-lib.

Major issues decided to be solved

Solutions for the above issues

(April 19- ) Getting into the code...Wanna-be hackers! Here is the kernel code...and the U-Net code...go man, hack it!

May 3 : Poster Presentation

Project Status

Well, the semester is over with, so whether we're done or not, the project is over with. Unfortunately, we ran into too many difficulties, and we never finished. The majority of the code is written, and all of the major issues seem to be resolved.

Expected Overhead and Future Extensions

Thanks a lot ...

to our Instructor, Thorsten von Eicken for providing us with the opportunity (and hardware) to work on this project, and Matt Welsh for maintaining his patience while explaining (and re-explaining) the U-Net driver internals as well as providing us with guidance throughout this project.

Additional thanks go out to Alan Cox, Michael K. Johnson, and the linux-kernel mailing list for their assistance in solving our Linux namei() problems.

Related Links

For information on U-Net : U-Net Home Page

For information on Linux : Linux Documentation Project

All information related to TCP/IP is maintained at Ohio State in their online list of Internet RFC's