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 maybe a few microseconds, before the softint can
> run. If your li
On Wed, Feb 17, 2016 at 2:13 PM, Taylor R Campbell
wrote:
>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
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 itself is very limi
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 state is up.
It's
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
>> if_link_state_change_si needs to proce
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
> if_link_state_change_si needs to process the whole queue in one go),
> that approach looks fine t
On Tuesday 16 February 2016 22:20:37 Taylor R Campbell wrote:
> This has the consequence that if the link goes up/down in quick
> succession, and then up/down in quick succession, &c., with the queue
> processed after each up/down transition, userland will never be
> notified. However, if the link
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 transitions, and is queu
Date: Tue, 16 Feb 2016 08:38:55 +
From: Roy Marples
The queue can be kept quite short because we don't care about any prior
entries each time state changes to LINK_STATE_DOWN.
Also, we don't care about any prior entries (other than LINK_STATE_DOWN)
when
setting LINK_STATE
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;
>
> s = splnet();
> if (ifp->if_link_state_pend
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
>> and
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 ifp->if_link_queu
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
14 matches
Mail list logo
