Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | X.25 Device Driver Interface 1.1 |
2 | ||
3 | Jonathan Naylor 26.12.96 | |
4 | ||
5 | This is a description of the messages to be passed between the X.25 Packet | |
6 | Layer and the X.25 device driver. They are designed to allow for the easy | |
7 | setting of the LAPB mode from within the Packet Layer. | |
8 | ||
9 | The X.25 device driver will be coded normally as per the Linux device driver | |
10 | standards. Most X.25 device drivers will be moderately similar to the | |
11 | already existing Ethernet device drivers. However unlike those drivers, the | |
12 | X.25 device driver has a state associated with it, and this information | |
13 | needs to be passed to and from the Packet Layer for proper operation. | |
14 | ||
15 | All messages are held in sk_buff's just like real data to be transmitted | |
16 | over the LAPB link. The first byte of the skbuff indicates the meaning of | |
17 | the rest of the skbuff, if any more information does exist. | |
18 | ||
19 | ||
20 | Packet Layer to Device Driver | |
21 | ----------------------------- | |
22 | ||
23 | First Byte = 0x00 | |
24 | ||
25 | This indicates that the rest of the skbuff contains data to be transmitted | |
26 | over the LAPB link. The LAPB link should already exist before any data is | |
27 | passed down. | |
28 | ||
29 | First Byte = 0x01 | |
30 | ||
31 | Establish the LAPB link. If the link is already established then the connect | |
32 | confirmation message should be returned as soon as possible. | |
33 | ||
34 | First Byte = 0x02 | |
35 | ||
36 | Terminate the LAPB link. If it is already disconnected then the disconnect | |
37 | confirmation message should be returned as soon as possible. | |
38 | ||
39 | First Byte = 0x03 | |
40 | ||
41 | LAPB parameters. To be defined. | |
42 | ||
43 | ||
44 | Device Driver to Packet Layer | |
45 | ----------------------------- | |
46 | ||
47 | First Byte = 0x00 | |
48 | ||
49 | This indicates that the rest of the skbuff contains data that has been | |
50 | received over the LAPB link. | |
51 | ||
52 | First Byte = 0x01 | |
53 | ||
54 | LAPB link has been established. The same message is used for both a LAPB | |
55 | link connect_confirmation and a connect_indication. | |
56 | ||
57 | First Byte = 0x02 | |
58 | ||
59 | LAPB link has been terminated. This same message is used for both a LAPB | |
60 | link disconnect_confirmation and a disconnect_indication. | |
61 | ||
62 | First Byte = 0x03 | |
63 | ||
64 | LAPB parameters. To be defined. | |
65 | ||
66 | ||
67 | ||
68 | Possible Problems | |
69 | ================= | |
70 | ||
71 | (Henner Eisen, 2000-10-28) | |
72 | ||
73 | The X.25 packet layer protocol depends on a reliable datalink service. | |
74 | The LAPB protocol provides such reliable service. But this reliability | |
75 | is not preserved by the Linux network device driver interface: | |
76 | ||
77 | - With Linux 2.4.x (and above) SMP kernels, packet ordering is not | |
78 | preserved. Even if a device driver calls netif_rx(skb1) and later | |
79 | netif_rx(skb2), skb2 might be delivered to the network layer | |
80 | earlier that skb1. | |
81 | - Data passed upstream by means of netif_rx() might be dropped by the | |
82 | kernel if the backlog queue is congested. | |
83 | ||
84 | The X.25 packet layer protocol will detect this and reset the virtual | |
85 | call in question. But many upper layer protocols are not designed to | |
86 | handle such N-Reset events gracefully. And frequent N-Reset events | |
87 | will always degrade performance. | |
88 | ||
89 | Thus, driver authors should make netif_rx() as reliable as possible: | |
90 | ||
91 | SMP re-ordering will not occur if the driver's interrupt handler is | |
92 | always executed on the same CPU. Thus, | |
93 | ||
94 | - Driver authors should use irq affinity for the interrupt handler. | |
95 | ||
96 | The probability of packet loss due to backlog congestion can be | |
97 | reduced by the following measures or a combination thereof: | |
98 | ||
99 | (1) Drivers for kernel versions 2.4.x and above should always check the | |
100 | return value of netif_rx(). If it returns NET_RX_DROP, the | |
101 | driver's LAPB protocol must not confirm reception of the frame | |
102 | to the peer. | |
103 | This will reliably suppress packet loss. The LAPB protocol will | |
104 | automatically cause the peer to re-transmit the dropped packet | |
105 | later. | |
106 | The lapb module interface was modified to support this. Its | |
107 | data_indication() method should now transparently pass the | |
108 | netif_rx() return value to the (lapb mopdule) caller. | |
109 | (2) Drivers for kernel versions 2.2.x should always check the global | |
110 | variable netdev_dropping when a new frame is received. The driver | |
111 | should only call netif_rx() if netdev_dropping is zero. Otherwise | |
112 | the driver should not confirm delivery of the frame and drop it. | |
113 | Alternatively, the driver can queue the frame internally and call | |
114 | netif_rx() later when netif_dropping is 0 again. In that case, delivery | |
115 | confirmation should also be deferred such that the internal queue | |
116 | cannot grow to much. | |
117 | This will not reliably avoid packet loss, but the probability | |
118 | of packet loss in netif_rx() path will be significantly reduced. | |
119 | (3) Additionally, driver authors might consider to support | |
120 | CONFIG_NET_HW_FLOWCONTROL. This allows the driver to be woken up | |
121 | when a previously congested backlog queue becomes empty again. | |
122 | The driver could uses this for flow-controlling the peer by means | |
123 | of the LAPB protocol's flow-control service. |