Messages in this thread |  | | From | kuznet@ms2 ... | Subject | Re: Q: sock output serialization | Date | Fri, 15 Sep 2000 21:07:38 +0400 (MSK DST) |
| |
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/
|  |