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

[Vladimir Oltean]

On Tue, Mar 14, 2023 at 12:25:18PM -0700, Richard Cochran wrote:
> On Tue, Mar 14, 2023 at 12:38:06PM +0200, Kamil Zaripov wrote:
> > Can you explain the problems you see with timestamping in the interface on 
> > top of a bridge?
> 
> When a MAC joins a bridge, the MAC is no longer avaiable as a network
> interface.  This is how the bridge thing is implemented in Linux.

That is approximately true (by default), but with your permission, some
nuance might help.

The bridge driver has an rx_handler which steals all traffic from the
bridge ports, so it can be processed by sockets opened on the bridge
device itself.

The exception is link-local multicast traffic (this is why L2 PTP works
over sockets opened on bridge ports, or at least with gPTP it does,
where all traffic is in the reserved 01-80-c2-00-00-xx space), but it's
also possible to add netfilter rules to tell the bridge to stop stealing
other traffic flows, such that those remain visible to sockets opened on
the bridge ports rather than on the bridge itself.

I happened to have these commands sitting around in a drawer, tailored
particularly to running PTP over bridge ports. Some adjustments might be
necessary depending on distribution and kernel config options.

# PTP over L2
/sbin/ebtables --table broute --append BROUTING --protocol 0x88F7 --jump DROP

# PTP over IPv4
/sbin/ebtables --table broute --append BROUTING --protocol 0x0800 --ip-protocol 
udp --ip-destination-port 320 --jump DROP
/sbin/ebtables --table broute --append BROUTING --protocol 0x0800 --ip-protocol 
udp --ip-destination-port 319 --jump DROP

# PTP over IPv6
/sbin/ebtables --table broute --append BROUTING --protocol 0x86DD 
--ip6-protocol udp --ip6-destination-port 320 --jump DROP
/sbin/ebtables --table broute --append BROUTING --protocol 0x86DD 
--ip6-protocol udp --ip6-destination-port 319 --jump DROP


___
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

[Vladimir Oltean]

On Tue, Mar 14, 2023 at 12:38:06PM +0200, Kamil Zaripov wrote:
> > 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.

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?


___
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

[Erez]

On Tue, 14 Mar 2023 at 20:27, Richard Cochran 
wrote:

> On Tue, Mar 14, 2023 at 12:38:06PM +0200, Kamil Zaripov wrote:
> > Can you explain the problems you see with timestamping in the interface
> on top of a bridge?
>
> When a MAC joins a bridge, the MAC is no longer avaiable as a network
> interface.  This is how the bridge thing is implemented in Linux.
>

There are also other options for creating bridges, i.e. like using the dsa
driver.
But the overall result is the same.
With the dsa, you can only access the "host interface" not the external
ports.

Erez


> Thanks,
> Richard
>
>
> ___
> Linuxptp-devel mailing list
> Linuxptp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
>
___
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

[Richard Cochran]

On Tue, Mar 14, 2023 at 12:38:06PM +0200, Kamil Zaripov wrote:
> Can you explain the problems you see with timestamping in the interface on 
> top of a bridge?

When a MAC joins a bridge, the MAC is no longer avaiable as a network
interface.  This is how the bridge thing is implemented in Linux.

Thanks,
Richard


___
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

[Erez]

On Mon, 13 Mar 2023 at 12:12, Kamil Zaripov  wrote:

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

As Richard explains. We use Linux VLAN.
For example see "Create the VLAN device"
https://wiki.archlinux.org/title/VLAN

The vlan interface should point to the PHC associated with the network
interface.

The only problem is what happens if on top of a single network interface,
 you have several PTP networks, using VLANs.
I do not refer to a bridge, but to an end device of several VLANs in which
each VLANs use a separate PTP network. For this case you need multiple PHC.

I assume you do not plan that yet.
But once we do, we will need support to select a network interface and a
PHP.
But till then the Linux VLAN interface should be sufficient.

Do you have other plans?

As for Bridge.
I am content with Richard replys.
ptp4l is used as a PTP end device only.
That could also explain why Richard did not like the virtual ports idea,
 as it might require the ptp4l to work as a virtual bridge :-)

Erez


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

[Richard Cochran]

On Mon, Mar 13, 2023 at 12:25:28PM +0200, Kamil Zaripov wrote:
> 
> > 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.

"It works for me" is not a strong argument.  This software stack must
work for everyone.  Time stamping on top of a bridge interface won't
fly in general, if I'm not mistaken.

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

The implementation would need work, but first the use case must be
clarified.

Thanks,
Richard


___
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

[Richard Cochran]

On Fri, Mar 10, 2023 at 05:31:29PM +0200, Kamil Zaripov wrote:

> However in a bit more complex network configuration when your VLAN
> interface is created on top of bridge that includes “hardware”

We don't support PTP on top of bridge interfaces, because the kernel
does not support that, and it would be difficult to add.

> interface your VLAN interface doesn’t support same timestamping
> capabilities as “hardware” interface, obviously:

Thanks,
Richard


___
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

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

[Richard Cochran]

On Fri, Mar 10, 2023 at 01:00:51PM +0200, Zaripov Kamil wrote:
> This patch allows to set interface name in 'iface:bind' format where:
> - 'iface' is network interface that supports PTP
> - 'bind' is network interface to bind socket
> This feature can be useful if you have one physical network interface that
> serves two or more logical local networks separated with VLAN tags. If you
> have to serve PTP clients on both of this local networks you need to bind
> to different interfaces representing different VLANs.
> 
> Most part of this patch just adjusting code where we read configuration
> for interface so we can set different settings for 'eth0:vlan1' and
> 'eth0:vlan2', for example.

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.

Thanks,
Richard


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

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

[Zaripov Kamil]

This patch allows to set interface name in 'iface:bind' format where:
- 'iface' is network interface that supports PTP
- 'bind' is network interface to bind socket
This feature can be useful if you have one physical network interface that
serves two or more logical local networks separated with VLAN tags. If you
have to serve PTP clients on both of this local networks you need to bind
to different interfaces representing different VLANs.

Most part of this patch just adjusting code where we read configuration
for interface so we can set different settings for 'eth0:vlan1' and
'eth0:vlan2', for example.

Signed-off-by: Zaripov Kamil 
---
 .gitignore|  1 +
 clock.c   | 22 +--
 config.c  |  8 ++--
 interface.c   | 34 +++--
 interface.h   | 14 +++
 port.c| 95 ---
 port_private.h|  1 +
 raw.c | 12 --
 udp.c |  8 ++--
 udp6.c| 10 +++--
 unicast_client.c  |  4 +-
 unicast_service.c |  6 +--
 12 files changed, 134 insertions(+), 81 deletions(-)

diff --git a/.gitignore b/.gitignore
index 1e7d1ca..8d3e171 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@
 /snmp4lptp
 /timemaster
 /ts2phc
+/tz2alt
diff --git a/clock.c b/clock.c
index 75d7c40..b79fa68 100644
--- a/clock.c
+++ b/clock.c
@@ -1182,14 +1182,14 @@ struct clock *clock_create(enum clock_type type, struct 
config *config,
if (interface_tsinfo_valid(iface) &&
!interface_tsmodes_supported(iface, 
required_modes)) {
pr_err("interface '%s' does not support requested 
timestamping mode",
-   interface_name(iface));
+   interface_name_full(iface));
return NULL;
}
}
 
iface = STAILQ_FIRST(>interfaces);
 
-   conf_phc_index = config_get_int(config, interface_name(iface), 
"phc_index");
+   conf_phc_index = config_get_int(config, interface_name_full(iface), 
"phc_index");
 
/* determine PHC Clock index */
if (config_get_int(config, NULL, "free_running")) {
@@ -1232,38 +1232,38 @@ struct clock *clock_create(enum clock_type type, struct 
config *config,
 
uds_ifname = config_get_string(config, NULL, "uds_address");
c->uds_rw_if = interface_create(uds_ifname);
-   if (config_set_section_int(config, interface_name(c->uds_rw_if),
+   if (config_set_section_int(config, interface_name_full(c->uds_rw_if),
   "announceReceiptTimeout", 0)) {
return NULL;
}
-   if (config_set_section_int(config, interface_name(c->uds_rw_if),
+   if (config_set_section_int(config, interface_name_full(c->uds_rw_if),
"delay_mechanism", DM_AUTO)) {
return NULL;
}
-   if (config_set_section_int(config, interface_name(c->uds_rw_if),
+   if (config_set_section_int(config, interface_name_full(c->uds_rw_if),
"network_transport", TRANS_UDS)) {
return NULL;
}
-   if (config_set_section_int(config, interface_name(c->uds_rw_if),
+   if (config_set_section_int(config, interface_name_full(c->uds_rw_if),
   "delay_filter_length", 1)) {
return NULL;
}
 
uds_ifname = config_get_string(config, NULL, "uds_ro_address");
c->uds_ro_if = interface_create(uds_ifname);
-   if (config_set_section_int(config, interface_name(c->uds_ro_if),
+   if (config_set_section_int(config, interface_name_full(c->uds_ro_if),
   "announceReceiptTimeout", 0)) {
return NULL;
}
-   if (config_set_section_int(config, interface_name(c->uds_ro_if),
+   if (config_set_section_int(config, interface_name_full(c->uds_ro_if),
   "delay_mechanism", DM_AUTO)) {
return NULL;
}
-   if (config_set_section_int(config, interface_name(c->uds_ro_if),
+   if (config_set_section_int(config, interface_name_full(c->uds_ro_if),
   "network_transport", TRANS_UDS)) {
return NULL;
}
-   if (config_set_section_int(config, interface_name(c->uds_ro_if),
+   if (config_set_section_int(config, interface_name_full(c->uds_ro_if),
   "delay_filter_length", 1)) {
return NULL;
}
@@ -1414,7 +1414,7 @@ struct clock *clock_create(enum clock_type type, struct 
config *config,
/* Create the ports. */
STAILQ_FOREACH(iface, >interfaces, list) {
if (clock_add_port(c, phc_device, phc_index, timestamping, 
iface)) {
-   pr_err("failed to open port %s", interface_name(iface));
+