Date: Wed, 17 Feb 2016 15:12:31 +0900
From: Ryota Ozaki
On Wed, Feb 17, 2016 at 2:13 PM, Taylor R Campbell
wrote:
> Note that this queueing takes effect only if the link state changes
> multiple times within
On Wed, Feb 17, 2016 at 1:40 PM, Roy Marples 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
Date: Wed, 17 Feb 2016 11:49:48 +0900
From: Ryota Ozaki
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
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
On Wed, Feb 17, 2016 at 10:46 AM, Roy Marples wrote:
> On Tuesday 16 February 2016 22:20:37 Taylor R Campbell wrote:
>> Except for an issue with queueing discussed privately (scheduling a
>> softint that is already scheduled won't cause it to run again, so
>>
Date: Tue, 16 Feb 2016 13:24:15 +
From: Roy Marples
I found the time to work on this, here is the patch I've been running
for an hour or so upping and downing interfaces.
The rule in Roy's patch is that each new state changes kicks out all
higher-priority
Date: Tue, 16 Feb 2016 16:30:54 +0900
From: Ryota Ozaki
On Tue, Feb 16, 2016 at 6:16 AM, Taylor R Campbell
wrote:
> void
> if_link_state_change(struct ifnet *ifp, int link_state)
> {
> int s;
>
On 16/02/2016 08:38, Roy Marples wrote:
> On Tuesday 16 February 2016 13:37:28 you wrote:
>>> Oh, I see. We shouldn't drop any events of link state changes.
>>
>> i don't see any point in keeping a huge series of link changes
>> if they can be collapsed into an equivalent sequence. with VMs
>>
On 16/02/2016 08:38, Roy Marples wrote:
> for (i = 0; i < ifp->if_link_queue_len; i++) {
> if (link_state <= ifp->if_link_queue[i]) {
> ifp->if_link_queue[i] = link_state;
> ifp->if_link_queue_len = i;
This should be
On Tuesday 16 February 2016 13:37:28 you wrote:
> > Oh, I see. We shouldn't drop any events of link state changes.
>
> i don't see any point in keeping a huge series of link changes
> if they can be collapsed into an equivalent sequence. with VMs
> and other user-controlled systems it's possible
10 matches
Mail list logo