Hi Alexy,
>>>>> "kuznet" == kuznet <kuznet@ms2.inr.ac.ru> writes:
kuznet> Listen, let's discuss this in more details. I thought
kuznet> about this yesterday and found that I did not understand
kuznet> the problem probably.
kuznet> Could you describe control flow, which you expect? Events
kuznet> are: device open, dial-on-demand, packet sent etc.
Currently, it is like this:
ifconfig up: -> device is open. device remains open, no matter whether the
isdn connection is up or down.
isdn connection is up: -> Nothing special, tbusy (or the equivalent
softnet stuff) is set in the usual manner. (tbusy set
in isdn_net_hard_start_xmit() if internal queues are full,
tbusy cleared when hardware irq signals that queue is empty
enough again.)
If isdn connenction is down and no pending traffic for the device:
Tbusy is not set. Now, if network layer sends down a packet
to the isdn netdevice, the interface triggers demand dialing.
isdn_net_start_xmit() returns 1 and sets tbusy. Thus, network
layer ceases sending down further packets. If network layer
queues further packetes for the isdn netdevice, those packets
will stay in the packet scheduler/device queues.
When in demand dialing stage (with tbusy set):
if isdn connection is established, tbusy is cleared. The
network layer will now restart sending the packets in the device
queues immediately. If establishing the connection fails,
all internal queues are purged, the qdisc is reset, and tbusy
will also be cleared again such that the devide is in the idle state
again.
kuznet> The most suspicious moment is period when tbusy is set.
kuznet> F.e. device should not hold it for very long
kuznet> time. Actually, if dialing is long, it is better to clear
Usually, it is not long. Might be less than a second for rawip encapsulation,
but with ppp it might take longer due to pppd negociation delays. With
interfaces configured for and waiting for a callback from the peer, delay will also increase.
kuznet> queue instead of tail drop, otherwise some datagram
kuznet> services, which are not supposed to block in write(),
kuznet> could block for too long time. Probably, we should make
kuznet> this engine more clever than it is.
Something like: If conenction is not up after a few seconds, clear all queues
and reset qdisc, but remain in dialing stage?
kuznet> Another moment: do you really understand that now packets
kuznet> never achieve driver, if tbusy is set? Another difference,
Yes.
kuznet> which can be confusing and, seems, not clever, is that
kuznet> watchdog is called even if no packets are queued. See?
kuznet> Please, blame 8)
That's what I was wondering about, but did not try to figure out yet.
kuznet> Alexey
Henner
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:19 EST