On Wed, Feb 17, 2016 at 1:40 PM, Roy Marples <r...@marples.name> wrote: > On 2016-02-17 02:49, Ryota Ozaki wrote: >>> >>> If you don't read the patch, here is the comment I added to the >>> if_link_state_change() function: >>> >>> * Queue a change in the interface link state. >>> * >>> * The queue itself is very limited: >>> * no state can be queued more than once >>> * a higher priority state will remove lower priority states >>> * >>> * The queue state priority in descending order is DOWN, UNKNOWN, UP. >>> * Rationale is that if the kernel can't process the link state change >>> queue >>> * fast enough then userland has no chance of catching up. >>> * Any lossage is logged to the console. >>> * The queue state priority is ordered so that link state aware programs >>> * will still have the correct end result regardless of any lossage. >>> >>> Any comments or objections? >> >> >> I worry about the priority order, where it comes from? I feel that >> the kernel does too much decision; which event is important. I think >> it depends on applications. > > > Fair enough. > Can you state a use case for an application needing the full ordering?
Event tracking of link states for example. > > Let us be more specific > UP: DOWN - UP > Is passed fully > DOWN: UP - DOWN > UP is not passed to userland. > What do you want to achieve in userland during the UP when the kernel > already considers the link DOWN? Even if a UP state is transient, it's an event that may provide us a hint of network conditions for diagnostic. We may be able to get it from the console output, but it's not so convenient; we need to track events via two different facilities. > >> And the priority provides asymmetric event deliveries; when the state >> repeats up and down, a down event is delivered if the final state is down >> while a down event and a up event are delivered if the final state is up. >> It's confusable to me. > > > It's not that confusing :) > If you're an application, what benefit do you have of processing an UP state > on the link when a DOWN state is about to follow? > Aside from logging it (which we still do, just not via a route message just > a console diagnostic) what would you do you with it? > Because a DOWN state is coming, it cannot possibly do anything over the > interface, so why bother? Applications can ignore the UP event. IMO we should delegate such a decision to applications because we don't know all requirements of all applications. ozaki-r