i386/linux/linux-2.3.21/Documentation/networking/olympic.txt

   1
   2 IBM PCI Pit/Pit-Phy/Olympic CHIPSET BASED TOKEN RING CARDS README
   3
   4 Release 0.2.0 - Release
   5         June 8th 1999 Peter De Schrijver & Mike Phillips
   6
   7
   8 Thanks:
   9 Erik De Cock, Adrian Bridgett and Frank Fiene for their
  10 patience and testing.
  11 Paul Norton without whose tr.c code we would have had
  12 a lot more work to do.
  13
  14 Options:
  15
  16 The driver accepts three options: ringspeed, pkt_buf_sz, and
  17 message_level.
  18
  19 These options can be specified differently for each card found.
  20
  21 ringspeed:  Has one of three settings 0 (default), 4 or 16.  0 will
  22 make the card autosense the ringspeed and join at the appropriate speed,
  23 this will be the default option for most people.  4 or 16 allow you to
  24 explicitly force the card to operate at a certain speed.  The card will fail
  25 if you try to insert it at the wrong speed. (Although some hubs will allow
  26 this so be *very* careful).  The main purpose for explicitly setting the ring
  27 speed is for when the card is first on the ring.  In autosense mode, if the card
  28 cannot detect any active monitors on the ring it will not open, so you must
  29 re-init the card at the appropriate speed.  Unfortunately at present the only
  30 way of doing this is rmmod and insmod which is a bit tough if it is compiled
  31 in the kernel.
  32
  33 pkt_buf_sz:  This is this initial receive buffer allocation size.  This will
  34 default to 4096 if no value is entered. You may increase performance of the
  35 driver by setting this to a value larger than the network packet size, although
  36 the driver now re-sizes buffers based on MTU settings as well.
  37
  38 message_level: Controls level of messages created by the driver. Defaults to 0:
  39 which only displays start-up and critical messages.  Presently any non-zero
  40 value will display all soft messages as well.  NB This does not turn
  41 debuging messages on, that must be done by modified the source code.
  42
  43 Multi-card:
  44
  45 The driver will detect multiple cards and will work with shared interrupts,
  46 each card is assigned the next token ring device, i.e. tr0 , tr1, tr2.  The
  47 driver should also happily reside in the system with other drivers.  It has
  48 been tested with ibmtr.c running, and I personnally have had one Olicom PCI
  49 card and two IBM olympic cards (all on the same interrupt), all running
  50 together.
  51
  52 Variable MTU size:
  53
  54 The driver can handle a MTU size upto either 4500 or 18000 depending upon
  55 ring speed.  The driver also changes the size of the receive buffers as part
  56 of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
  57 to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring
  58 position = 296,000 bytes of memory space, plus of course anything
  59 necessary for the tx sk_buff's.  Remember this is per card, so if you are
  60 building routers, gateway's etc, you could start to use a lot of memory
  61 real fast.
  62
  63 Network Monitor Mode:
  64
  65 By modifying the #define OLYMPIC_NETWORK_MONITOR from 0 to 1 in the
  66 source code the driver will implement a quasi network monitoring
  67 mode.  All unexpected MAC frames (beaconing etc.) will be received
  68 by the driver and the source and destination addresses printed.
  69 Also an entry will be added in  /proc/net called olympic_tr. This
  70 displays low level information about the configuration of the ring and
  71 the adapter. This feature has been designed for network adiministrators
  72 to assist in the diagnosis of network / ring problems.
  73
  74 6/8/99 Peter De Schrijver and Mike Phillips
  75