On Wed, 21 Mar 2018, Richard Cochran wrote:
@Intel: I removed intel-wired-lan@ as I have absolutely zero interest in
the moderation spam from that list. Can you please either get rid
of this moderation nonsense or stop CC'ing that list when posting
to lkml/netdev?
> On Wed, Mar 21, 2018 at 01:58:51PM +0100, Thomas Gleixner wrote:
> > Errm. No. There is no way to support fd based clocks or one of the CPU
> > time/process time based clocks for this.
>
> Why not?
>
> If the we have HW offloading, then the transmit time had better be
> expressed in terms of the MAC's internal clock. Otherwise we would
> need to translate between a kernel clock and the MAC clock, but that
> is expensive (eg over PCIe) and silly (because in a typical use case
> the MAC will already be synchronized to the network time).
Sure, but you CANNOT use a clockid for that because there is NONE.
The mac clock is exposed via a dynamic posix clock and can only be
referenced via a file descriptor.
The qdisc setup does fd = open(...) and hands that in as clockid. Later the
application does fd = open(...) and uses that as clockid for tagging the
messages.
What the heck guarantees that both the setup and the application will get
the same fd number?
Exactly nothing. So any attempt to use the filedescriptor number as clockid
is broken by definition.
Thanks,
tglx
