aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/networking/x25-iface.txt
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@ppc970.osdl.org>2005-04-16 18:20:36 -0400
committerLinus Torvalds <torvalds@ppc970.osdl.org>2005-04-16 18:20:36 -0400
commit1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch)
tree0bba044c4ce775e45a88a51686b5d9f90697ea9d /Documentation/networking/x25-iface.txt
Linux-2.6.12-rc2v2.6.12-rc2
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
Diffstat (limited to 'Documentation/networking/x25-iface.txt')
-rw-r--r--Documentation/networking/x25-iface.txt123
1 files changed, 123 insertions, 0 deletions
diff --git a/Documentation/networking/x25-iface.txt b/Documentation/networking/x25-iface.txt
new file mode 100644
index 000000000000..975cc87ebdd1
--- /dev/null
+++ b/Documentation/networking/x25-iface.txt
@@ -0,0 +1,123 @@
1 X.25 Device Driver Interface 1.1
2
3 Jonathan Naylor 26.12.96
4
5This is a description of the messages to be passed between the X.25 Packet
6Layer and the X.25 device driver. They are designed to allow for the easy
7setting of the LAPB mode from within the Packet Layer.
8
9The X.25 device driver will be coded normally as per the Linux device driver
10standards. Most X.25 device drivers will be moderately similar to the
11already existing Ethernet device drivers. However unlike those drivers, the
12X.25 device driver has a state associated with it, and this information
13needs to be passed to and from the Packet Layer for proper operation.
14
15All messages are held in sk_buff's just like real data to be transmitted
16over the LAPB link. The first byte of the skbuff indicates the meaning of
17the rest of the skbuff, if any more information does exist.
18
19
20Packet Layer to Device Driver
21-----------------------------
22
23First Byte = 0x00
24
25This indicates that the rest of the skbuff contains data to be transmitted
26over the LAPB link. The LAPB link should already exist before any data is
27passed down.
28
29First Byte = 0x01
30
31Establish the LAPB link. If the link is already established then the connect
32confirmation message should be returned as soon as possible.
33
34First Byte = 0x02
35
36Terminate the LAPB link. If it is already disconnected then the disconnect
37confirmation message should be returned as soon as possible.
38
39First Byte = 0x03
40
41LAPB parameters. To be defined.
42
43
44Device Driver to Packet Layer
45-----------------------------
46
47First Byte = 0x00
48
49This indicates that the rest of the skbuff contains data that has been
50received over the LAPB link.
51
52First Byte = 0x01
53
54LAPB link has been established. The same message is used for both a LAPB
55link connect_confirmation and a connect_indication.
56
57First Byte = 0x02
58
59LAPB link has been terminated. This same message is used for both a LAPB
60link disconnect_confirmation and a disconnect_indication.
61
62First Byte = 0x03
63
64LAPB parameters. To be defined.
65
66
67
68Possible Problems
69=================
70
71(Henner Eisen, 2000-10-28)
72
73The X.25 packet layer protocol depends on a reliable datalink service.
74The LAPB protocol provides such reliable service. But this reliability
75is 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
84The X.25 packet layer protocol will detect this and reset the virtual
85call in question. But many upper layer protocols are not designed to
86handle such N-Reset events gracefully. And frequent N-Reset events
87will always degrade performance.
88
89Thus, driver authors should make netif_rx() as reliable as possible:
90
91SMP re-ordering will not occur if the driver's interrupt handler is
92always executed on the same CPU. Thus,
93
94- Driver authors should use irq affinity for the interrupt handler.
95
96The probability of packet loss due to backlog congestion can be
97reduced 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.