Hi Thomas,
On 03/22/2018 03:11 PM, Thomas Gleixner wrote: (...) >> Having the sorting always enabled requires that a valid static clockid is >> passed >> to the qdisc. For the hw offload mode, that means that the PHC and one of the >> system clocks must be synchronized since hrtimers do not support dynamic >> clocks. >> Not all systems do that or want to, and given that we do not want to perform >> crosstimestamping between the packets' clock reference and the qdisc's one, >> the >> only solution for these systems would be using the raw hw offload mode. > > There are two variants of hardware offload: > > 1) Full hardware offload > > That bypasses the queue completely. You just stick the thing into the > scatter gather buffers. Except when there is no room anymore, then you > have to queue, but it does not make any difference if you queue in FIFO > or in time order. The packets go out in time order anyway. Illustrating your variants with the current qdisc's setup arguments. The above is: - sorting off - offload on (I call it a 'raw' fifo as a reference to the usage of qdisc_enqueue_tail() and qdisc_dequeue_head(), basically.) > > 2) Single packet hardware offload > > What you do here is to schedule a hrtimer a bit earlier than the first > packet tx time and when it fires stick the packet into the hardware and > rearm the timer for the next one. The above is: - sorting on - offload on right? So, are you just opposing to the case where sorting off + offload off is used? (i.e. the scheduled FIFO case) > > The whole point of TSN with hardware support is that you have: > > - Global network time > > and > > - Frequency adjustment of the system time base > > PTP is TAI based and the kernel exposes clock TAI directly through > hrtimers. You don't need dynamic clocks for that. > > You can even use clock MONOTONIC as it basically is just > > TAI - offset> > If the network card uses anything else than TAI or a time stamp with a > strict correlation to TAI for actual TX scheduling then the whole thing is > broken to begin with. Sure, I agree. Thanks, Jesus > > Thanks, > > tglx >
