Hello!
> scheduler may re-order frames
It cannot, provided sender holds order until dev_queue_xmit().
Actually, it is true about all the schedulers, except for
the cases, when reordering is allowed explicitly with special
policing rules.
> or drop them.
Yes. And if you share _single_ device both for reliable and unreliable
services, you have to make special tricks.
> be fixed by providing a special LAPB network scheduler which takes
> care about preserving reliable LAPB semantics.
Yes. ATM CLIP already does this, look at atm clip.c and sch_atm.c
to get an example.
> 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.
etc.
No!
In fact, it is mathematical fact, that as soon as order is broken
once it is _impossible_ to restore it back. No valid actions are
invented to do this f.e. for TCP.
Though with lapb the situation is different: it cannot lose frames,
this changes the situation.
In any case, order must not be broken, if it is essential. That's answer.
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 : Sat Sep 23 2000 - 21:00:13 EST