Hi,
>>>>> "jamal" == jamal <[EMAIL PROTECTED]> writes:
>> With the current scheme, lapb first acknowleges reception of
>> the frame and after that, netif_rx() might still discard it --
>> which is evil.
>>
jamal> This might screw things a bit. Can you defer to say first
jamal> call netif_rx() then acknowledge or is this hard-coded into
jamal> the f/ware?
This depends on the firmware. I don´t know. The software lapb module
could be modified to honor a return vale appropriately. But software
lapb should be moved above netif for several other reasons anyway
(although even there, honoring a return value for flow control
would make sense). Maybe it is a good idea to make the congestion
return values not netif specific, but making them part of a generic
"return semantics for delivering packets to upper layers".
The driver maintainers will need to investigate this and take appropriate
actions depending on the firmware´s capabilities.
My personal use of the X.25 stack was using it in DTE-DTE mode over
isdn where I use the isdn-driver´s internal lapb (x75i) implementation.
Unfortunatly, the interface to the isdn lower layers does not allow to
return an rx_busy condition.
>> Provided that netif_would_drop(dev) is reliable (a subsequent
jamal> I think this would make it a little more complex than
jamal> necessary; the queue state might change right after you
Yes, the scenario I had in mind (where it would have been reliable)
was a little short-sighted (see reply to Andi´s message).
jamal> If you cant defer the acknowledgement until netif_rx()
jamal> returns then what we could do is instead:
jamal> 1) for devices that are registered with hardware flow
jamal> control ==> you have to register as a
jamal> CONFIG_NET_HW_FLOWCONTROL device.
jamal> a) to let them queue that last packet before they are
jamal> shut-up, the assumption is they respect the protocol and
jamal> will 'back-off' after that.
jamal> b) return BLG_CNG_WOULD_DROP
jamal> instead to the device and give it the responsibility to
jamal> free the skb or store it wherever it wants but not in the
jamal> backlog.
jamal> I personally prefer a). Reason: If we have done all the
jamal> work so far(context switch etc) and we know the device is
jamal> well behaved(meaning it is not going to send another packet
jamal> without beiong told things are fine) then it is probably
jamal> wiser to just let that packet get on the backlog queue.
Yes, a) that would make life much simpler for driver writers (but more
difficult for you ;). If it is doable without adding overhead to the
general path, it would be nice to provide that semantics to HW_FLOWCONTROLed
devices.
However, even with a), after being HW-flow-controlled and setting rx_busy
condition, there could still arrive some more packets until the send window
is full. They either need to be discarded at once or queued somewhere else.
If we don´t want to discard them, you need to accept packets up
to the window size from a device after it has been HW flow conrolled.
Henner
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
