Hi,
On 03/21/2018 09:18 AM, Thomas Gleixner wrote: > On Wed, 21 Mar 2018, Richard Cochran wrote: > >> On Wed, Mar 21, 2018 at 03:22:11PM +0100, Thomas Gleixner wrote: >>> Which clockid will be handed in from the application? The network adapter >>> time has no fixed clockid. The only way you can get to it is via a fd based >>> posix clock and that does not work at all because the qdisc setup might >>> have a different FD than the application which queues packets. >> >> Duh. That explains it. Please ignore my "why not?" Q in the other thread... > > :) > > So in that case you are either bound to rely on the application to use the > proper dynamic clock or if we need a sanity check, then you need a cookie > of some form which can be retrieved from the posix clock file descriptor > and handed in as 'clockid' together with clock_adapter = true. > > That's doable, but that needs a bit more trickery. A simple unique ID per > dynamic posix-clock would be trivial to add, but that would not give you > any form of verification whether this ID actually belongs to the network > adapter or not. > > So either you ignore the clockid and rely on the application not being > stupid when it says "clock_adpater = true" or you need some extra > complexity to build an association of a "clockid" to a network adapter. > > There is a connection already, via > > adapter->ptp_clock->devid > > which is MKDEV(major, index) which is accessible at least at the network > driver level, but probably not from networking core. So you'd need to drill > a few more holes by adding yet another callback to net_device_ops. > > I'm not sure if its worth the trouble. If the application hands in bogus > timestamps, packets go out at the wrong time or are dropped. That's true > whether it uses the proper clock or not. So nothing the kernel should > really worry about. +1 and that is the approach we've taken so far with the qdisc setting "CLOCKID_INVALID" to its internal clockid for the "raw" (non-assisted) hw offload case. thanks, Jesus > > For clock_system - REAL/MONO/TAI(sigh) - you surely need a sanity check, > but that is independent of the underlying network adapater even in the > qdisc assisted HW offload case. > > Thanks, > > tglx > > > > > >
