| Message ID | 1510088376-5527-1-git-send-email-dave.taht@gmail.com |
|---|---|
| Headers | show |
| Series | netem: add nsec scheduling and slot feature | expand |
On Tue, 7 Nov 2017 12:59:33 -0800 Dave Taht <dave.taht@gmail.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 iproute2 that means send both new and old versions.
On Tue, Nov 7, 2017 at 4:26 PM, Stephen Hemminger <stephen@networkplumber.org> wrote: > On Tue, 7 Nov 2017 12:59:33 -0800 > Dave Taht <dave.taht@gmail.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.