[Linuxptp-devel] Two ptp4l processes working on the same network interface

[Kamil Zaripov]

I have a setup where a local network has host with both IEEE 802.3 & UDP PTP 
slaves and linux host that should run as PTP master. I used to run two ptp4l 
processes (one with -2 argument and another one with -4 argument) on the master 
host, but my network card cannot simultaneously timestamp several outgoing 
packages. So sometimes they race with each other for tx timestamp resources and 
one of them get timeout waiting for tx timestamp.

I have asked what can I do with this issue in linuxptp-users@ mailing list and 
got an answer from Richard that you can launch one ptp4l process that serves 
both IEEE 802.3 and UDP PTP slaves.

The issue is ptp4l does not support out of the box creating two ports on the 
same network interfaces with different network_transport configuration values. 
I want to discuss how linuxptp code can be patched so user can do such thing?

I have a dirty solution where I add some suffix to the interface name in 
configuration file just to create several independent interfaces in configs, 
but It has several drawbacks. I think that there must be a better solution.

Cheers,
Zaripov Kamil.___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Add option to bind raw and UDP sockets to interface

[Kamil Zaripov]

> On 15 Mar 2023, at 01:55, Vladimir Oltean  wrote:
> 
> What will happen if the bridge floods the frame to 2 bridge ports, and
> both supports hardware TX timestamping? How many TX timestamps will be
> collected by the kernel, and more importantly, which ones? How many of
> those will be delivered to user space? Is ptp4l prepared to process more
> than one hardware TX timestamp per sent packet?

Yes, this is good question and now I see that this changes will not work in 
general case. We can drop this patch.

Regards,
Zaripov Kamil___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Add option to bind raw and UDP sockets to interface

[Kamil Zaripov]

> On 13 Mar 2023, at 20:35, Richard Cochran  wrote:
> 
> "It works for me" is not a strong argument.  This software stack must
> work for everyone.
> 

I agree that “It works for me” is not enough to merge this patch.

> Time stamping on top of a bridge interface won't
> fly in general, if I'm not mistaken.


Can you explain the problems you see with timestamping in the interface on top 
of a bridge?

From my point of view when you call setsockopt(.., SO_TIMESTAMP**, 
SOF_TIMESTAMPING_**_HARDWARE) it does not matter if any network card on your 
system support hw timestamping capabilities. At this point network card only 
record all socket option values to the socket structure: 
https://elixir.bootlin.com/linux/latest/source/net/core/sock.c#L895 
. Next 
during package send we check if socket have appropriate timestamping flags, and 
if so we copy this info to the sk_buff structure: 
https://elixir.bootlin.com/linux/latest/source/include/net/sock.h#L2768 
. At 
the end after package finally ready to be send in ndo_start_xmit 
https://elixir.bootlin.com/linux/latest/source/include/linux/netdevice.h#L1401 

 we either implement required times taping features or not. For example igb 
driver checks if tx_flags in skb_buf have timestamping request 
https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/intel/igb/igb_main.c#L6432
 

 and ask hardware to timestamp frame.

So I think that it doesn’t matter how complex your network configuration, only 
think that matters is which network card will actually handle frames.

But I’m neither linux kernel networking expert nor PTP expert. If I’m wrong 
please correct me.

Regards,
Zaripov Kamil___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Add option to bind raw and UDP sockets to interface

[Kamil Zaripov]

> On 12 Mar 2023, at 14:18, Erez  wrote:
> 
> Sounds cool, but requires multiple clocks on the network interface.
> Hardware or logic using a single hardware clock.
> I do know that some do work on this.
> Both in kernel and on application level.
> 
If we talk about ptp4l I think that two processes that synchronise their access 
to the timestamping capabilities can run simultaneously on the same “physical” 
network interface. And this patch designed change only ptp4l process behaviour. 
It it affects other tools I need to fix it.

> Usually VLAN in Linux are deployed by adding a network interface for the VLAN.
> How is this patch feat to the Linux deployment of VLANs.
> Nor do I see how this patch integrates with using multiple clocks.
> 
> Please enlighten us.
> 
> Erez

Actually I do not understand this question. Can you rephrase it?

Regards,
Zaripov Kamil.___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Add option to bind raw and UDP sockets to interface

[Kamil Zaripov]

> On 13 Mar 2023, at 03:56, Richard Cochran  wrote:
> 
> We don't support PTP on top of bridge interfaces, because the kernel
> does not support that, and it would be difficult to add.

Ok, but actually it is possible to do it using this patch and it works pretty 
good in my case (two VLAN’s on top of bridge which include Intel I210 interface 
with PTP capabilities) on the several hundreds machines for several years.

If you think that it is useless we drop this patch, no problem. If you think 
that implementation is bad we can discuss how can we make it better.

Regards
Zaripov Kamil.___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Re: [Linuxptp-devel] [PATCH] Add option to bind raw and UDP sockets to interface

[Kamil Zaripov]

> Um, unless I'm mistaken, this is unneeded, because you can specify a
> VLAN interface just like a normal interface.  In the kernel, the VLAN
> interface stacks on top of the physical one and passes the time
> stamping APIs through.


It seems that it is true if you create VLAN interface on top of “hardware” 
interface (the one that support PTP):

$ ethtool -T eth1
Time stamping parameters for eth1:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive  (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive  (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock(SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off   (HWTSTAMP_TX_OFF)
on(HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none  (HWTSTAMP_FILTER_NONE)
all   (HWTSTAMP_FILTER_ALL)

$ ip -j link show vlan1 | jq '.[] | .link’
“eth1"

$ ethtool -T vlan1
Time stamping parameters for vlan1:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive  (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive  (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock(SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off   (HWTSTAMP_TX_OFF)
on(HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none  (HWTSTAMP_FILTER_NONE)
all   (HWTSTAMP_FILTER_ALL)

However in a bit more complex network configuration when your VLAN interface is 
created on top of bridge that includes “hardware” interface your VLAN interface 
doesn’t support same timestamping capabilities as “hardware” interface, 
obviously:

$ ip -j link show vlan1 | jq '.[] | .link’
“br1”

$ ip -j link show eth1 | jq '.[] | .master'
"br1"

$ ethtool -T vlan1
Time stamping parameters for vlan1:
Capabilities:
software-receive  (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes: none
Hardware Receive Filter Modes: none

Regard,
Zaripov Kamil___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel