netdev - Re: [RFC net-next 0/5] TSN: Add qdisc-based config interfaces for traffic shapers

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: <20170920055616.snd6tndvbdnesnck@localhost>
Date:   Wed, 20 Sep 2017 07:56:16 +0200
From:   Richard Cochran <richardcochran@...il.com>
To:     levipearson@...il.com
Cc:     vinicius.gomes@...el.com, netdev@...r.kernel.org,
        intel-wired-lan@...ts.osuosl.org, andre.guedes@...el.com,
        ivan.briano@...el.com, jesus.sanchez-palencia@...el.com,
        boon.leong.ong@...el.com, jhs@...atatu.com,
        xiyou.wangcong@...il.com, jiri@...nulli.us, henrik@...tad.us
Subject: Re: [RFC net-next 0/5] TSN: Add qdisc-based config interfaces for
 traffic shapers

On Tue, Sep 19, 2017 at 07:59:11PM -0600, levipearson@...il.com wrote:
> If some endpoint device shows up with direct Qbv support, this interface would
> probably work well there too, although a talker would need to be able to
> schedule its transmits pretty precisely to achieve the lowest possible latency.

This is an argument for SO_TXTIME.

> One concern here is calling the base-time parameter an interval; it's really
> an absolute time with respect to the PTP timescale. Good documentation will
> be important to this one, since the specification discusses some subtleties
> regarding the impact of different time values chosen here.
> 
> The format for specifying the actual intervals such as cycle-time could prove
> to be an important detail as well; Qbv specifies cycle-time as a ratio of two
> integers expressed in seconds, while extension-time is specified as an integer
> number of nanoseconds.
> 
> Precision with the cycle-time is especially important, since base-time can be
> almost arbitrarily far in the past or future, and any given cycle start should
> be calculable from the base-time plus/minus some integer multiple of cycle-
> time.

The above three points also.

Thanks,
Richard