On 7/17/2020 9:10 AM, Vladimir Oltean wrote: > These are some questions I had while trying to explain the behavior of > some drivers with respect to software timestamping. Answered with the > help of Richard Cochran. > > Signed-off-by: Vladimir Oltean <olteanv@xxxxxxxxx> > --- > Documentation/networking/timestamping.rst | 26 +++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > diff --git a/Documentation/networking/timestamping.rst b/Documentation/networking/timestamping.rst > index 4004c5d2771d..e01ec01179fe 100644 > --- a/Documentation/networking/timestamping.rst > +++ b/Documentation/networking/timestamping.rst > @@ -791,3 +791,29 @@ The correct solution to this problem is to implement the PHY timestamping > requirements in the MAC driver found broken, and submit as a bug fix patch to > netdev@xxxxxxxxxxxxxxx. See :ref:`Documentation/process/stable-kernel-rules.rst > <stable_kernel_rules>` for more details. > + > +3.4 Frequently asked questions > +------------------------------ > + > +Q: When should drivers set SKBTX_IN_PROGRESS? > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +When the interface they represent offers both ``SOF_TIMESTAMPING_TX_HARDWARE`` > +and ``SOF_TIMESTAMPING_TX_SOFTWARE``. > +Originally, the network stack could deliver either a hardware or a software > +time stamp, but not both. This flag prevents software timestamp delivery. > +This restriction was eventually lifted via the ``SOF_TIMESTAMPING_OPT_TX_SWHW`` > +option, but still the original behavior is preserved as the default. > + So, this implies that we set this only if both are supported? I thought the intention was to set this flag whenever we start a HW timestamp. > +Q: Should drivers that don't offer SOF_TIMESTAMPING_TX_SOFTWARE call skb_tx_timestamp()? > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +The ``skb_clone_tx_timestamp()`` function from its body helps with propagation > +of TX timestamps from PTP PHYs, and the required placement of this call is the > +same as for software TX timestamping. > +Additionally, since PTP is broken on ports with timestamping PHYs and unmet > +requirements, the consequence is that any driver which may be ever coupled to > +a timestamping-capable PHY in ``netdev->phydev`` should call at least > +``skb_clone_tx_timestamp()``. However, calling the higher-level > +``skb_tx_timestamp()`` instead achieves the same purpose, but also offers > +additional compliance to ``SOF_TIMESTAMPING_TX_SOFTWARE``. > This makes sense. Thanks, Jake
