[lkml]   [2000]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Q: sock output serialization

> 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. ]

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.057 / U:18.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site