Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/net

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
Is passed fully
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?


Home | Main Index | Thread Index | Old Index