Re: [PATCH RFC net-next v8 04/13] net: Change the API of PHY default timestamp to MAC

[Andrew Lunn <andrew@lunn.ch>]

> > Could you give some examples? It seems odd to me, the application
> > wants a less accurate timestamp?
> >
> > Is it more about overheads? A MAC timestamp might be less costly than
> > a PHY timestamp?
> 
> It's a combination of both though I think primarily about line rate.
> This point is somewhat carried over from the previous discussions on
> this patch series in the last revision.

Sorry, i've not been keeping up with the discussion. That could also
mean whatever i say below is total nonsense!

> I assume the device in question
> here cannot timestamp at the PHY at a high rate.
> 
>   https://lore.kernel.org/netdev/20231120093723.4d88fb2a@kernel.org/
> 
> >
> > Or is the application not actually doing PTP, it does not care about
> > the time of the packet on the wire, but it is more about media access
> > control? Maybe the applications you are talking about are misusing the
> > PTP API for something its not intended?
> 
> So hardware timestamping is not a PTP specific API or application right?

Well, we have drivers/ptp. The IOCTL numbers are all PTP_XXXX. It
seems like the subsystem started life in order to support PTP. It is
not unusual for a subsystem to gain extra capabilities, and maybe PTP
timestamps can be used in a more general way than the PTP
protocol.

> It's purely a socket option that is not tied to PTP (unless I am missing
> something here).
> 
>   https://docs.kernel.org/networking/timestamping.html#timestamp-generation
> 
> So you could use this information for other applications like congestion
> control where you do not want to limit the line rate using the PHY
> timestamping mechanism.

I think the key API point here is, you need to separate PTP stamping
from other sorts of stamping. PTP stamping generally works better at
the lowest point. So PTP stamping could be PHY stamping. If the PHY
does not support PTP, or its implementation is poor, PTP stamping can
be performed at the MAC. There are plenty of MACs which support that.
So we need an API to configure where PTP stamping is performed.

I expect the socket option is more generic. It is more about, give me
a time stamp at a specific point in the stack. It is probably not
being used by PTP, it could be used for flow control, etc. We probably
need an API to configure that SOF_TIMESTAMPING_RX_HARDWARE actually
means. It could be the PHY time stamp, maybe the MAC timestamp. Same
for SOF_TIMESTAMPING_TX_HARDWARE, it could be the MAC, could be the
PHY. But whatever they mean, i expect they are separate PTP.

> In mlx5, we only steering PTP traffic to our PHY timestamping mechanism
> through a traffic matching logic.
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/drivers/net/ethernet/mellanox/mlx5/core/en/ptp.h?id=a6e0cb150c514efba4aaba4069927de43d80bb59#n71
> 
> This is because we do not want to PHY/port timestamp timing related
> applications such as congestion control. I think it makes sense for
> specialized timestamping applications to instead use the ethtool ioctl
> to reconfigure using the PHY timestamps if the device is capable of PHY
> timestamping. (So have the change be in userspace application tools like
> linuxptp where precise but low <relative> rate timestamp information is
> ideal).

I would expect linuxptp is only interested in the PTP timestamp. It
might be interested where the stamp is coming from, PHY or MAC, but it
probably does not care too much, it just assumes the time stamp is
good for PTP. But i would expect linuxptp has no interest in what the
generic socket options are doing.

    Andrew