Date: Mon, 23 Jun 1997 12:00:25 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: FreeBSD-SCSI@FreeBSD.ORG Subject: DPT for FreeBSD - New Driver Message-ID: <XFMail.970623120025.Shimon@i-Connect.Net>
next in thread | raw e-mail | index | archive | help
Hi Y'all, We just completed a new version of the DPT driver. It will be available momentarily on ftp://sendero-ppp.i-connect.net/crash. Highlights: * Some minor bug fixes. * Initial working sample of the Raid Manager driver Raid Manager Driver: The DPT SCSI subsystem allows a high degree of tuning and configuration control. For these features to run under FreeBSD, we have added a character device driver. Pending approval and acceptance, here are some highlights and ``how to play'' notes: * There are two interfaces, an IOCTL interface which is a superset of the standard DPT interface. This is being made compatible with the SCO and UnixWare interfaces. ALL the pertinent DPT calls will be supported, in addition to some ``local'' FreeBSD specific ones. These later ones are mapped to mirror the READ/WRITE interface described below. * The R/W interface allows you to write an ASCII message to the controller and then read the result. To make things a bit safer, no action is taken on the write operation, only on the READ. Results are provided as ASCII readable records. * To install the interface, create /dev/dptX, where X is the controller number. Set the major number to 130 (pending approval) and the minor number to match X The first DPT is /dev/dpt0 130,0, then /dev/dpt1 130,1, etc. * To WRITE a command, simply use ``echo -n "some command'' > /dev/dptX. you need the -n as without it echo makes TWO write system calls; one with the message, one with the '\n'. Without the -n, the command will be NULL; We always remember the last command. * To have the command parsed, executed, and results returned, read 4095 bytes from /dev/dptX. Do not try the cat command yet. It tries to read 64K and gets confused when we return a residual. I wrote a little throwaway that reads 4095 bytes from the port, using syscalls rather than buffered I/O. Called dpt_get.c and in the usual place. * Only few commands are implemented: "dump softc" Will dump the entire softc structure for the controller. Things of interest are the queue management and timers. We time how long it takes for a SCSI command before we actually put it into the DPT (waiting queue), how long it takes the DPT to return to us (submitted queue) and how long before we send it back to the SCSI layer. We keep the maximum depth of each queue, the shortest time spent there and the longest time spent there. Another thing measured is the min/max time the DPT took to execute each type of SCSI command, along with the number of commands executed. "dump metrics" Dumps just the metrics portion of the softc. Future release will include statistics gathered by the DPT hardware. These include I/O by block size, error rates, RAID status, cabinet status, etc. "sintr on" Enables software interrupts. This is the default mode. In this mode, submitting SCSI commands and actually parsing completion errors are done in a separate execution thread. This thread is managed by calling software interrupts to invoke these procedures. For workstation type loads it is quite meaningless, but for heavily loaded servers it is very meaningfull. For example; 256 concurrent processes all doing continious I/O on the disk result, in a non-sintr (see below) load average of about 110-120. This makes the machine very, very sluggish in responding to non-DPT events, as well as DPT events. With sintr on, the same exact load results in LA of about 5 (with occasional peaks at 9). Response and throughput on the DPT is still miserable, but the rest of the system responds very well. This allows us to respond, without timeouts, to real- time network events, even when the disk is absurdely busy. "sintr off" Turns off software interrupts. In this mode, the driver blocks until a command is submitted and the interrupt routine stays in critical section until a completion is resolved. This is almost identical to the normal FreeBSD SCSI driver. NOTE: Changing from one mode to another, on a ``hot'' system is akin to changing gears in a manual transmission without a clutch. It can be done but you really need to know what you are doing. Transalation: Use at your own peril. This is it folks. Please try and break it. We are counting on you :-) Thanx, Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970623120025.Shimon>