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?
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?
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?
Can we pass events as they are as much as possible? I don't complain
that
event reductions in the kernel, but I think it should be down based on
time
series manner (e.g., pick latest three events), not based on some
priority
things. If we accept event reductions, we can do it with bit-encoding
(w/o a linked list (memory allocations)), for example represent the
state
as 2 bits and encode event series into a variable (say 16 events in
int).
Of course we could.
But until we understand a reason why this is needed why should we?
Roy
