Documentation/networking/x25-iface.txt

   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 module) 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.