Re: [PATCH 1/3] Add TX sending hardware timestamp.

[Willem de Bruijn]

> >> >>>> I did not use "Fair Queue traffic policing".
> >> >>>> As for ETF, it is all about ordering packets from different applications.
> >> >>>> How can we achive it with skiping queuing?
> >> >>>> Could you elaborate on this point?
> >> >>>
> >> >>> The qdisc can only defer pacing to hardware if hardware can ensure the
> >> >>> same invariants on ordering, of course.
> >> >>
> >> >> Yes, this is why we suggest ETF order packets using the hardware time-stamp.
> >> >> And pass the packet based on system time.
> >> >> So ETF query the system clock only and not the PHC.
> >> >
> >> > On which note: with this patch set all applications have to agree to
> >> > use h/w time base in etf_enqueue_timesortedlist. In practice that
> >> > makes this h/w mode a qdisc used by a single process?
> >>
> >> A single process theoretically does not need ETF, just set the skb-> tstamp and use a pass through queue.
> >> However the only way now to set TC_SETUP_QDISC_ETF in the driver is using ETF.
> >
> > Yes, and I'd like to eventually get rid of this constraint.
> >
>
> I'm interested in these kind of ideas :-)
>
> What would be your end goal? Something like:
>  - Any application is able to set SO_TXTIME;
>  - We would have a best effort support for scheduling packets based on
>  their transmission time enabled by default;
>  - If the hardware supports, there would be a "offload" flag that could
>  be enabled;
>
> More or less this?

Exactly. Pacing is stateless, so relatively amenable to offload.

For applications that offload pacing to the OS with SO_TXTIME, such as
QUIC, further reduce jitter and timer wake-ups (and thus cycles) by
offloading to hardware.

Not only for SO_TXTIME, also for pacing initiated by the kernel TCP stack.

Initially, in absence of hardware support, at least in virtual environments
offload from guest to host OS.