On Fri, Jul 17, 2020 at 04:12:07PM -0700, Jacob Keller wrote: > > > 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. > It's only _required_ when SOF_TIMESTAMPING_TX_SOFTWARE is used, it seems. I had also thought of setting 'SKBTX_IN_PROGRESS' as good practice, but there are many situations where it can do more harm than good. > > +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 Thanks, -Vladimir
