Re: CVS commit: src/sys/net

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Wed, Feb 17, 2016 at 2:13 PM, Taylor R Campbell
<campbell+netbsd-source-changes-d%mumble.net@localhost> wrote:
>    Date: Wed, 17 Feb 2016 11:49:48 +0900
>    From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
>
>    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.
>
> This is the part I'm still not sure about: Roy's patch reduces up/down
> to just down, but leaves down/up alone.  I'm guessing that Roy expects
> applications like dhcpcd to want to clear some state if the link ever
> goes down, but to be uninterested in knowing that the link went up for
> a microsecond and then back down again.
>
>    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).
>
> 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 link state is changing that many times so quickly,
> losing an event or two is probably the least of your worries

Yeah, it's nitpicking, but for that reason, I think it's better to pass
events as they are to userland.

> -- but
> you're probably more interested in seeing something like ...down...up
> than ...up/up/up.

Yes. (up/up/up events are eliminated in the first place though.)

  ozaki-r