Hello!
> But I realized another problem X.25 related SMP problem -- this time
> related to input. The protocol design assumes that the transmission
> path preserves the packet ordering. It seems that with 2.4.0 SMP, the ordering
> of the packets when received from the wire is not necessarily the same
> as when delivered to the protocolīs receive method. Is this true?
This is true.
> recover from such errors transparently. Unfortunatly, the current design
> assumes that the LAPB layer is performed below the network interface.
I.e. on hard irq? It was not a good idea.
> Although this allows to support controllers which implement LAPB in firmware,
This is really difficult case.
> this seems to break the assumptions made by upper layers. The upper layer
> assumes that LAPB devices provide a reliable datalink service. But the Linux
> network interfaces do not preserve such reliable semantics. (Network
> interfaces may drop frames, e.g. when NET_RX input queue overruns,
No way to fix. I do not know how to make this.
> and on SMP packet sequencing might change),
Though this one can be fixed by restricting affinity,
all this smells like you cannot use netif_rx() for such devices.
netif_rx() is used for normal "unreliable" devices, it loses any
sense as soon as we require some reliability...
[ Dave, all this sounds bad. ]
Alexey
-
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 : Fri Sep 15 2000 - 21:00:26 EST