Remember that after an interrupt fires, it will NOT be re-enabled by the kernel until ALL driver handlers tell the kernel that they have completed handling. So, if one driver takes a long, long time servicing a shared interrupt which is masked, if another device on the same interrupt causes an interrupt during that time period, processing of that interrupt can be delayed for an unknown duration of time.
Bottom line is that interrupt sharing can cause problems, and reduce performance, increase cpu consumption, and seriously increase latency. Unless you really need to do it, don't. If you must share interrupts, make sure your drivers are doing the "right thing". Face it - shared interrupts are the new "trans fats" The NetBSD drivers make heavy use of libnbdrvr. While mostly complete, we're expecting that this library will need updates and tuning as time goes on, especially when we start porting more USB devices over at this stage, USB support in the porting library is best characterized as "experimental".
It works, but we haven't exercised it to a large degree. On a board with a PCI bus, you can rely on the pci server being there to tell you about the ethernet hardware - how many interfaces there are, and their hardware parameters.
But what about on a board with no PCI bus? A good example of this is the devnp-mpc85xx. Over time, board-specific information such asn interrupts, etc crept in the driver, and that's not good, because every new board required that the driver binary be altered - yuck.
This required changed to both the startup - to create the hwi entries - and the driver - to use the hwi entries. But at the end of the day, the result is that by using the hwi infrastructure, a new driver binary is not required for every board. Take a look at the devnp-mpx85xx. Now, you will notice that devnp-mpc85xx.
For more information on the hwi stuff, click here. First you have to make sure that you're source is compiled with debugging information included. After hitting the breakpoint in main , do a 'sharedlibrary' command in gdb.
You should see libc loaded in. Set a breakpoint in dlsym. When that's hit your driver should be loaded in but io-pkt hasn't done the first callout into it. Do a 'set solib-search-path' and add the path to your driver and then do a 'sharedlibrary' again. The syms for your driver should now load and you can set a break point where you want your debugging to start. Jumbo packets are packets that carry more payload than the normal bytes.
For Jumbo packets to work, you need all of the protocol stack, the drivers, and the network switches yes, really to support jumbo packets. Even the definition of a jumbo packet is unclear - different people will use different lengths.
Anyways, the io-pkt hardware-independent stack DOES support jumbo packets. Not all network hardware supports jumbo packets generally, newer gige nics do. The native drivers for io-pkt DO support jumbo packes. For example, devnp-i So does the devnp-mpc85xx. If you can use jumbo packets with io-pkt, you can see substantial performance gains because more data can be moved per packet header processing overhead.
How do you configure to operate with jumbo packets? Do this:. What about Transmit Segmentation Offload? Essentially, instead of the stack being responsible for breaking a large IP packet into MTU sized packets, the driver can do this instead. This greatly offloads the amount of CPU required to transmit large amounts of data.
You can tell if a driver supports TSO by typing "ifonfig" and looking at the capabilities section of the interface output. How do you configure the driver to use? For example, with devnp-i CPU Utilization?
Above we have talked about reducing CPU utilization. It is possible to drastically reduce CPU utilization during heavy packet throughput, by using a hardware feature to reduce the number of received packet interrupts, which allows the stack to amortize the cost of the interrupt servicing over more received packets, and hence increase efficiency.
For information on installing this BSP, see the installation note. For the most up-to-date version of these release notes, log into your myQNX account, and then go to the Download Center area of www. Throughout this document, you may see reference numbers associated with particular issues, changes, etc. When corresponding with our Technical Support staff about a given issue, please quote the relevant reference number.
You might also find the reference numbers useful for tracking issues as they become fixed. To extract the source from the archive, use any application that supports the ZIP format e. For 6. These branches contain the source used to create 6. Starting in release 6. How do I get the source? How do I build the source? If you don't properly create a staging area and suitable qconf-override.
If you haven't already done so, install the srcversion patch for specific QNX distribution you are using from the download section of the BSP project as root. Not required for 6. That's it! All the associated header files for the build and binaries created will get installed in your staging directory.
Note : Building from the top-level directory builds everything in the correct order so that all dependencies are satisfied from your staging area. Log In. The text you entered is not a valid object ID. Search Wiki Pages.
Important things to do remember about staging areas: They allow the source to build. This is always good practice when building QNX source anyway, but it's particularly important when building the BSP and Drivers tree, since a 'make install' generally has to be done from the root to build components in the correct order to satisfy dependencies.
0コメント