> 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
> 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
> 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
> 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
> 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
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
