Network Drivers

• Types of network drivers
  The networking stack supports the following types of drivers:
• Loading and unloading a driver
  You can load drivers into the stack from the command line just as with io-net . For example:
• Troubleshooting a driver
  For native drivers and io-net drivers, the nicinfo utility is usually the first debug tool that you'll use (aside from ifconfig ) when problems with networking occur. This will let you know whether or not the driver has properly negotiated at the link layer and whether or not it's sending and receiving packets.
• Problems with shared interrupts
  Having different devices sharing a hardware interrupt is kind of a neat idea, but unless you really need to do it — because you've run out of hardware interrupt lines — it generally doesn't help you much. In fact, it can cause you trouble. For example, if your driver doesn't work (e.g. no received packets), check to see if it's sharing an interrupt with another device, and if so, reconfigure your board so it doesn't.
• Writing a new driver
  
• Debugging a driver using gdb
  If you want to use gdb to debug a driver, youfirst have to make sure that your source is compiled with debugging information included. With your driver code in the correct place in the sys tree ( dev_qnx or dev ), you can do the following:
• Dumping 802.11 debugging information
  The stack's 802.11 layer can dump debugging information. You can enable and disable the dumping by using sysctl settings. If you do:
• Jumbo packets and hardware checksumming
  Jumbo packets are packets that carry more payload than the normal 1500 bytes. Even the definition of a jumbo packet is unclear; different people use different lengths. For jumbo packets to work, the protocol stack, the drivers, and the network switches must all support jumbo packets:
• Padding Ethernet packets
  If an Ethernet packet is shorter than ETHERMIN bytes, padding can be added to the packet to reach the required minimum length. In the interests of performance, the driver software doesn't automatically pad the packets, but leaves it to the hardware to do so if supported. If hardware pads the packets, the contents of the padding depend on the hardware implementation.
• Transmit Segmentation Offload (TSO)
  Transmit Segmentation Offload (TSO) is a capability provided by some modern NIC cards (see, for example, http://en.wikipedia.org/wiki/Large_segment_offload ). Essentially, instead of the stack being responsible for breaking a large IP packet into MTU-sized packets, the driver does it. This greatly offloads the amount of CPU required to transmit large amounts of data.