[lkml]   [2000]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Q: sock output serialization

>>>>> "jamal" == jamal <> 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> 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

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.066 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site