Hi,
>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
Alan> LAPB does not expect ever to see re-ordering. Its a point to
Alan> point wire level MAC protocol.
Yes, it was never designed for handling re-ordering because this cannot
happen on a single wire (and for that reason it is not fair to blame LAPB
for not handling re-ordering efficiently). But it seems that re-ordering
will by handled nevertheless -- by retransmission of the not-in-sequence
frames. At least the X.25 layer 2 spec for LAPB requires:
"Reception of out-of-sequence I frames
When the DCE receives a valid I frame whose send state sequence
number N(S) is incorrect, it will discard the information field of
the I frame and transmit an REJ frame with the N(R) set to one
higher than the N(S) of the last correctly received I frame. ...
... The DCE will then discard the information field of all I frames
received until the expected I frame is correctly received"
Not very efficient, but it should work. And as long as re-ordering
only happend occasionally, efficiency should not matter. And the fact
that LAPB can actually recover from re-ordering problems really shows that
it is good design: it can even recover from errors that were considered
impossible in the design environment.
Alan> 'Smart hardware is broken' repeat .. ;) - but yes its an
;)
Alan> issue there. These cards could bypass netif_rx and call
Alan> directly to the lapb top end though ?
Yes, something like this. Maybe whatīs missing is a standard
interface in the kernel that allows to access reliable datalink
service.
Further, itīs not just a netif_rx() issue. dev_queue_xmit() does not
provide reliable datalink semantics, either. The default network
scheduler may re-order frames or drop them. But this could
be fixed by providing a special LAPB network scheduler which takes
care about preserving reliable LAPB semantics. Maybe a LAPB network
scheduler would even be the best place to hook in the software lapb
processing: the standard network scheduler queues could serve
simultaneously as the output queue for lapb. Putting lapb anywhere else
requires a dedicated LAPB output queue.
Further, Iīm wondering whether other protocols are also affected by
re-ordering problems. X.25 is not the only protocol which relies on
frames beeing received in sequence. Frame relay or ATM networks are also
required to deliver frames/cells in sequence. And upper layer protocols
might depend on this.
Maybe a general solution to the problem whould be to provide a special
skb->rx_seqno field for SMP kernels. Device drivers can maintain an
rx counter (they usually do so anyway in struct net_device_stats.rx_packets)
which is incremented whenever a new frame is received. The driver
then sets skb->rx_seqno to that value before calling netif_rx().
Then upper layerīs worried about netif_rx() re-ordering can detect
this and act appropriately. Only device drivers and protocols affected
by re-ordering need to do so. Thus, protocols like tcp/ip which already
can handle re-ordering by themselves wontīt be affected. They will
only suffer from the increased skb size by sizeof(skb->rx_seqno).
Maybe a convention to hook the rx_seqno into skb->cb could even work around
this. Itīs not trival yet when different upper layer protocols receive frames
from the device. NET_RX_SOFTIRQ handler would need to map the device
specific sequence numbers to consecutive protocol specific sequence numbers
before calling ptype->func().
Henner
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:12 EST