netdev - Re: [PATCH net-next 0/3] netem: add nsec scheduling and slot feature

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA93jw7Kb2YnOjH7Xk5ci5W8Y6vgWTpTwhpi=xngShPxUErmmw@mail.gmail.com>
Date:   Wed, 8 Nov 2017 13:45:05 -0800
From:   Dave Taht <dave.taht@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 0/3] netem: add nsec scheduling and slot feature

On Tue, Nov 7, 2017 at 4:26 PM, Stephen Hemminger
<stephen@...workplumber.org> wrote:
> On Tue,  7 Nov 2017 12:59:33 -0800
> Dave Taht <dave.taht@...il.com> wrote:
>
>> This patch series converts netem away from the old "ticks" interface and
>> userspace API, and adds support for a new "slot" feature intended to
>> emulate bursty macs such as WiFi and LTE better.
>>
>> Dave Taht (3):
>>   netem: convert to qdisc_watchdog_schedule_ns
>>   netem: add uapi to express delay and jitter in nanosec
>>   netem: support delivering packets in delayed time slots
>>
>>  include/uapi/linux/pkt_sched.h |  10 +++
>>  net/sched/sch_netem.c          | 144 ++++++++++++++++++++++++++++++++---------
>>  2 files changed, 125 insertions(+), 29 deletions(-)
>>
>
> Dave, thanks for the patch.
> One issue is that it needs to keep binary compatibility both for kernel and iproute.
> That means that users of new kernel should be able to use old versions of iproute
> without any visible impact (and vice versa).
>
> For the kernel, that means if new attributes are not present the old attributes
> would be used.

For the kernel patchset you are commenting on, this was the case. There was no
way to send via an old iproute2 a jitter or delay value that would
trigger sending
the new attributes, although the old api has severe rounding errors as you get
down to a few us.

I just sent a kernel v2 that always sends the old and new attributes.

>For iproute2 that means send both new and old versions.

This, in the iproute2 patchset, didn't, as I assumed new versions of
iproute2 would only be used with newer kernels. I'll respin that.

I did want to somehow, one day, obsolete ticks, but I guess
that is not possible.

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619