Kyle Swenson | 8d8f654 | 2021-03-15 11:02:55 -0600 | [diff] [blame] | 1 | # NTB Drivers |
| 2 | |
| 3 | NTB (Non-Transparent Bridge) is a type of PCI-Express bridge chip that connects |
| 4 | the separate memory systems of two computers to the same PCI-Express fabric. |
| 5 | Existing NTB hardware supports a common feature set, including scratchpad |
| 6 | registers, doorbell registers, and memory translation windows. Scratchpad |
| 7 | registers are read-and-writable registers that are accessible from either side |
| 8 | of the device, so that peers can exchange a small amount of information at a |
| 9 | fixed address. Doorbell registers provide a way for peers to send interrupt |
| 10 | events. Memory windows allow translated read and write access to the peer |
| 11 | memory. |
| 12 | |
| 13 | ## NTB Core Driver (ntb) |
| 14 | |
| 15 | The NTB core driver defines an api wrapping the common feature set, and allows |
| 16 | clients interested in NTB features to discover NTB the devices supported by |
| 17 | hardware drivers. The term "client" is used here to mean an upper layer |
| 18 | component making use of the NTB api. The term "driver," or "hardware driver," |
| 19 | is used here to mean a driver for a specific vendor and model of NTB hardware. |
| 20 | |
| 21 | ## NTB Client Drivers |
| 22 | |
| 23 | NTB client drivers should register with the NTB core driver. After |
| 24 | registering, the client probe and remove functions will be called appropriately |
| 25 | as ntb hardware, or hardware drivers, are inserted and removed. The |
| 26 | registration uses the Linux Device framework, so it should feel familiar to |
| 27 | anyone who has written a pci driver. |
| 28 | |
| 29 | ### NTB Transport Client (ntb\_transport) and NTB Netdev (ntb\_netdev) |
| 30 | |
| 31 | The primary client for NTB is the Transport client, used in tandem with NTB |
| 32 | Netdev. These drivers function together to create a logical link to the peer, |
| 33 | across the ntb, to exchange packets of network data. The Transport client |
| 34 | establishes a logical link to the peer, and creates queue pairs to exchange |
| 35 | messages and data. The NTB Netdev then creates an ethernet device using a |
| 36 | Transport queue pair. Network data is copied between socket buffers and the |
| 37 | Transport queue pair buffer. The Transport client may be used for other things |
| 38 | besides Netdev, however no other applications have yet been written. |
| 39 | |
| 40 | ### NTB Ping Pong Test Client (ntb\_pingpong) |
| 41 | |
| 42 | The Ping Pong test client serves as a demonstration to exercise the doorbell |
| 43 | and scratchpad registers of NTB hardware, and as an example simple NTB client. |
| 44 | Ping Pong enables the link when started, waits for the NTB link to come up, and |
| 45 | then proceeds to read and write the doorbell scratchpad registers of the NTB. |
| 46 | The peers interrupt each other using a bit mask of doorbell bits, which is |
| 47 | shifted by one in each round, to test the behavior of multiple doorbell bits |
| 48 | and interrupt vectors. The Ping Pong driver also reads the first local |
| 49 | scratchpad, and writes the value plus one to the first peer scratchpad, each |
| 50 | round before writing the peer doorbell register. |
| 51 | |
| 52 | Module Parameters: |
| 53 | |
| 54 | * unsafe - Some hardware has known issues with scratchpad and doorbell |
| 55 | registers. By default, Ping Pong will not attempt to exercise such |
| 56 | hardware. You may override this behavior at your own risk by setting |
| 57 | unsafe=1. |
| 58 | * delay\_ms - Specify the delay between receiving a doorbell |
| 59 | interrupt event and setting the peer doorbell register for the next |
| 60 | round. |
| 61 | * init\_db - Specify the doorbell bits to start new series of rounds. A new |
| 62 | series begins once all the doorbell bits have been shifted out of |
| 63 | range. |
| 64 | * dyndbg - It is suggested to specify dyndbg=+p when loading this module, and |
| 65 | then to observe debugging output on the console. |
| 66 | |
| 67 | ### NTB Tool Test Client (ntb\_tool) |
| 68 | |
| 69 | The Tool test client serves for debugging, primarily, ntb hardware and drivers. |
| 70 | The Tool provides access through debugfs for reading, setting, and clearing the |
| 71 | NTB doorbell, and reading and writing scratchpads. |
| 72 | |
| 73 | The Tool does not currently have any module parameters. |
| 74 | |
| 75 | Debugfs Files: |
| 76 | |
| 77 | * *debugfs*/ntb\_tool/*hw*/ - A directory in debugfs will be created for each |
| 78 | NTB device probed by the tool. This directory is shortened to *hw* |
| 79 | below. |
| 80 | * *hw*/db - This file is used to read, set, and clear the local doorbell. Not |
| 81 | all operations may be supported by all hardware. To read the doorbell, |
| 82 | read the file. To set the doorbell, write `s` followed by the bits to |
| 83 | set (eg: `echo 's 0x0101' > db`). To clear the doorbell, write `c` |
| 84 | followed by the bits to clear. |
| 85 | * *hw*/mask - This file is used to read, set, and clear the local doorbell mask. |
| 86 | See *db* for details. |
| 87 | * *hw*/peer\_db - This file is used to read, set, and clear the peer doorbell. |
| 88 | See *db* for details. |
| 89 | * *hw*/peer\_mask - This file is used to read, set, and clear the peer doorbell |
| 90 | mask. See *db* for details. |
| 91 | * *hw*/spad - This file is used to read and write local scratchpads. To read |
| 92 | the values of all scratchpads, read the file. To write values, write a |
| 93 | series of pairs of scratchpad number and value |
| 94 | (eg: `echo '4 0x123 7 0xabc' > spad` |
| 95 | # to set scratchpads `4` and `7` to `0x123` and `0xabc`, respectively). |
| 96 | * *hw*/peer\_spad - This file is used to read and write peer scratchpads. See |
| 97 | *spad* for details. |
| 98 | |
| 99 | ## NTB Hardware Drivers |
| 100 | |
| 101 | NTB hardware drivers should register devices with the NTB core driver. After |
| 102 | registering, clients probe and remove functions will be called. |
| 103 | |
| 104 | ### NTB Intel Hardware Driver (ntb\_hw\_intel) |
| 105 | |
| 106 | The Intel hardware driver supports NTB on Xeon and Atom CPUs. |
| 107 | |
| 108 | Module Parameters: |
| 109 | |
| 110 | * b2b\_mw\_idx - If the peer ntb is to be accessed via a memory window, then use |
| 111 | this memory window to access the peer ntb. A value of zero or positive |
| 112 | starts from the first mw idx, and a negative value starts from the last |
| 113 | mw idx. Both sides MUST set the same value here! The default value is |
| 114 | `-1`. |
| 115 | * b2b\_mw\_share - If the peer ntb is to be accessed via a memory window, and if |
| 116 | the memory window is large enough, still allow the client to use the |
| 117 | second half of the memory window for address translation to the peer. |
| 118 | * xeon\_b2b\_usd\_bar2\_addr64 - If using B2B topology on Xeon hardware, use |
| 119 | this 64 bit address on the bus between the NTB devices for the window |
| 120 | at BAR2, on the upstream side of the link. |
| 121 | * xeon\_b2b\_usd\_bar4\_addr64 - See *xeon\_b2b\_bar2\_addr64*. |
| 122 | * xeon\_b2b\_usd\_bar4\_addr32 - See *xeon\_b2b\_bar2\_addr64*. |
| 123 | * xeon\_b2b\_usd\_bar5\_addr32 - See *xeon\_b2b\_bar2\_addr64*. |
| 124 | * xeon\_b2b\_dsd\_bar2\_addr64 - See *xeon\_b2b\_bar2\_addr64*. |
| 125 | * xeon\_b2b\_dsd\_bar4\_addr64 - See *xeon\_b2b\_bar2\_addr64*. |
| 126 | * xeon\_b2b\_dsd\_bar4\_addr32 - See *xeon\_b2b\_bar2\_addr64*. |
| 127 | * xeon\_b2b\_dsd\_bar5\_addr32 - See *xeon\_b2b\_bar2\_addr64*. |