lkml.org 
[lkml]   [2000]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.3.4x softnet watchdog and (isdn) demand dialing
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:56    [W:0.027 / U:91.136 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site