On Thu, May 23, 2019 at 1:06 PM Eric Dumazet <eric.duma...@gmail.com> wrote:
>
>
>
> On 5/23/19 9:45 AM, Willem de Bruijn wrote:
> > The SO_TXTIME API enables packet tranmission with delayed delivery.
> > This is currently supported by the ETF and FQ packet schedulers.
> >
> > Evaluate the interface with both schedulers. Install the scheduler
> > and send a variety of packets streams: without delay, with one
> > delayed packet, with multiple ordered delays and with reordering.
> > Verify that packets are released by the scheduler in expected order.
> >
> > The ETF qdisc requires a timestamp in the future on every packet. It
> > needs a delay on the qdisc else the packet is dropped on dequeue for
> > having a delivery time in the past. The test value is experimentally
> > derived. ETF requires clock_id CLOCK_TAI. It checks this base and
> > drops for non-conformance.
> >
> > The FQ qdisc expects clock_id CLOCK_MONOTONIC, the base used by TCP
> > as of commit fb420d5d91c1 ("tcp/fq: move back to CLOCK_MONOTONIC").
> > Within a flow there is an expecation of ordered delivery, as shown by
> > delivery times of test 4. The FQ qdisc does not require all packets to
> > have timestamps and does not drop for non-conformance.
> >
> > The large (msec) delays are chosen to avoid flakiness.
> >
> > Output:
> >
> > SO_TXTIME ipv6 clock monolithic
>
> s/monolithic/monotonic/
Oops. That's actually fixed in the latest version, just not in the
commit message. I'll send a v2 just to update that. Thanks Eric.
Having some trouble with git send-email and gmail today, hence the
email from my google.com account, too.
>
> > payload:a delay:33 expected:0 (us)
> >
> > SO_TXTIME ipv4 clock monolithic
> > payload:a delay:44 expected:0 (us)
> >
> > SO_TXTIME ipv6 clock monolithic
> > payload:a delay:10049 expected:10000 (us)
> >
> > SO_TXTIME ipv4 clock monolithic
> > payload:a delay:10105 expected:10000 (us)
>
>
> Thanks for the test Willem.
>
> Acked-by: Eric Dumazet <eduma...@google.com>
>
