Root/
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 (X25_IFACE_DATA) |
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 (X25_IFACE_CONNECT) |
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 (X25_IFACE_DISCONNECT) |
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 (X25_IFACE_PARAMS) |
40 | |
41 | LAPB parameters. To be defined. |
42 | |
43 | |
44 | Device Driver to Packet Layer |
45 | ----------------------------- |
46 | |
47 | First Byte = 0x00 (X25_IFACE_DATA) |
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 (X25_IFACE_CONNECT) |
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 (X25_IFACE_DISCONNECT) |
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 (X25_IFACE_PARAMS) |
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. |
124 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9