Messages in this thread | | | Date | Sun, 17 Sep 2000 10:32:51 +0200 | From | Henner Eisen <> | Subject | Re: Q: sock output serialization |
| |
Hi,
>>>>> "jamal" == jamal <hadi@cyberus.ca> 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |