Hi,
>>>>> "kuznet" == kuznet <kuznet@ms2.inr.ac.ru> writes:
kuznet> Hello!
>> scheduler may re-order frames
kuznet> It cannot, provided sender holds order until
kuznet> dev_queue_xmit().
But if I set different skb->priority? ;) Well that would be my fault than ..
>> or drop them.
kuznet> Yes. And if you share _single_ device both for reliable
kuznet> and unreliable services, you have to make special tricks.
Well, I think this problem will not occur. For shared service, we
will use a datalink protocol running above netif. (e.g. mixed X.25
and IP over ethernet where X.25 runs on top of 802.2 LLC.2 which
will be implemented above netif). And for smart (firmware lapb)
interfaces, which are the real problem, we won´t need to support
shared service.
>> be fixed by providing a special LAPB network scheduler which
>> takes care about preserving reliable LAPB semantics.
kuznet> Yes. ATM CLIP already does this, look at atm clip.c and
kuznet> sch_atm.c to get an example.
Yes. But the above seems to be a network scheduler specialized
for passing IP down to an ATM tunnel. What I had in mind would
correspond to a special scheduler for an atm net_device (but ATM
does not use stadard linux net_device).
>> that value before calling netif_rx(). Then upper layer´s
>> worried about netif_rx() re-ordering can detect this and act
>> appropriately.
kuznet> etc.
kuznet> No!
kuznet> In fact, it is mathematical fact, that as soon as order is
kuznet> broken once it is _impossible_ to restore it back. No
kuznet> valid actions are invented to do this f.e. for TCP.
Agreed.
kuznet> Though with lapb the situation is different: it cannot
kuznet> lose frames, this changes the situation.
Unfortunatly, the netif_rx might still loose frames, and its concurrent
netif_rx() which re-orders the frames. Thus, we cannot take advantage
of reliable LAPB below netif_rx when packet loss and re-ordering occured
above netif_rx().
kuznet> In any case, order must not be broken, if it is
kuznet> essential. That's answer.
I see. Apparently, IRQ affinity seems the only simple and cheep
solution the re-ordering problem.
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:13 EST