[Linuxptp-users] using ptp4l on vlan interfaces

Discussion:

Shawn Bohrer

2013-12-10 18:47:32 UTC

Hello,

I'm currently a PTPd user but I'm interested in ptp4l especially if I
can take advantage of hardware timestamp support. First step was to
see if I could simply run ptp4l utilizing software timestamps and I
ran into a bit of a snag. We currently run ptpd on a vlan but
attempting to run ptp4l on a vlan interface results in the following:

# ptp4l -S -i vlan807 -s -l7 -m
interface 'vlan807' does not support requested timestamping mode.

I took a look at the code and can see this is because vlan interfaces
do not report that they support SOF_TIMESTAMPING_TX_SOFTWARE. The
underlying device interface eth4 however does claim to support
SOF_TIMESTAMPING_TX_SOFTWARE.

So I guess I have a couple of questions here regarding ptp4l and
vlans. The first big question is of course is it possible to run
ptp4l on a vlan? Assuming the actual device and driver support
hardware timestamps (or software TX) and provide a PHC is it possible
to access those through a vlan?

Thanks,
Shawn

Keller, Jacob E

2013-12-10 20:58:26 UTC

Permalink

-----Original Message-----
Sent: Tuesday, December 10, 2013 10:48 AM
Subject: [Linuxptp-users] using ptp4l on vlan interfaces
Hello,

Hi :)

I'm currently a PTPd user but I'm interested in ptp4l especially if I
can take advantage of hardware timestamp support. First step was to
see if I could simply run ptp4l utilizing software timestamps and I
ran into a bit of a snag. We currently run ptpd on a vlan but
# ptp4l -S -i vlan807 -s -l7 -m
interface 'vlan807' does not support requested timestamping mode.
I took a look at the code and can see this is because vlan interfaces
do not report that they support SOF_TIMESTAMPING_TX_SOFTWARE.
The
underlying device interface eth4 however does claim to support
SOF_TIMESTAMPING_TX_SOFTWARE.
So I guess I have a couple of questions here regarding ptp4l and
vlans. The first big question is of course is it possible to run
ptp4l on a vlan? Assuming the actual device and driver support
hardware timestamps (or software TX) and provide a PHC is it possible
to access those through a vlan?

I am not sure about vlans, but at least for VF drivers, I don't think any currently support PTP.. however I do believe Intel might be able to support hardware timestamps.

To support software timestamps I believe the vlan driver would just have to call the correct software timestamp callback, and advertise that it supports the TX_SOFTWARE timestamping in the ethtool call.

As for the other.. I think you would only be able to access these if you use direct attach of a virtual function.. Then the virtual function driver could setup its own PHC and timestamping as long as the hardware allowed VFs to enable those features.

Regards,
Jake

Thanks,
Shawn
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into
your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ost
g.clktrk
_______________________________________________
Linuxptp-users mailing list
https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Richard Cochran

2013-12-11 07:25:15 UTC

Permalink

Post by Keller, Jacob E
To support software timestamps I believe the vlan driver would just
have to call the correct software timestamp callback, and advertise
that it supports the TX_SOFTWARE timestamping in the ethtool call.

Right, although I haven't looked at the details, it sounds like
supporting SO_TIMESTAMPING over vlan will require kernel work.

Thanks,
Richard

Richard Cochran

2013-12-11 07:29:43 UTC

Permalink

Post by Shawn Bohrer
I took a look at the code and can see this is because vlan interfaces
do not report that they support SOF_TIMESTAMPING_TX_SOFTWARE. The
underlying device interface eth4 however does claim to support
SOF_TIMESTAMPING_TX_SOFTWARE.

Can you try hacking the code to omit the ethtool check?

If the time stamping actually works, and the only problem is the
ethtool reporting, then that would probably be an easy kernel fix.

Thanks,
Richard

Shawn Bohrer

2013-12-11 21:42:09 UTC

Permalink

Post by Richard Cochran

Can you try hacking the code to omit the ethtool check?
If the time stamping actually works, and the only problem is the
ethtool reporting, then that would probably be an easy kernel fix.

I left the message in but let it continue. It appears to work fine
with software timestamps, or at least I don't see any relevant errors
and it is adjusting the clock. I haven't looked into the "port 1:
delay timeout" messages yet.

***@berbox40:~/linuxptp# ./ptp4l -S -i vlan807 -s -l7 -m -f default.cfg
interface 'vlan807' does not support requested timestamping mode.
ptp4l[245.983]: PI servo: sync interval 1.000 kp 0.100 ki 0.001000
ptp4l[245.983]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[245.983]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[246.042]: port 1: setting asCapable
ptp4l[247.042]: port 1: new foreign master 0050c2.fffe.de95be-1
ptp4l[251.040]: selected best master clock 0050c2.fffe.de95be
ptp4l[251.040]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[252.174]: port 1: delay timeout
ptp4l[252.174]: path delay 55915 55915
ptp4l[252.174]: port 1: minimum delay request interval 2^3
ptp4l[252.308]: port 1: delay timeout
ptp4l[252.310]: path delay 74143 92372
ptp4l[253.038]: master offset 104525904 s0 freq +0 path delay 74143
ptp4l[254.038]: master offset 103983280 s0 freq +0 path delay 74143
ptp4l[255.038]: master offset 103440336 s0 freq +0 path delay 74143
ptp4l[256.037]: master offset 102900750 s0 freq +0 path delay 74143
ptp4l[257.037]: master offset 102356489 s0 freq +0 path delay 74143
ptp4l[258.036]: master offset 101812007 s0 freq +0 path delay 74143
ptp4l[259.036]: master offset 101270800 s0 freq +0 path delay 74143
ptp4l[260.035]: master offset 100726417 s0 freq +0 path delay 74143
ptp4l[261.035]: master offset 100183093 s0 freq +0 path delay 74143
ptp4l[262.034]: master offset 99642376 s0 freq +0 path delay 74143
ptp4l[263.034]: master offset 99097737 s0 freq +0 path delay 74143
ptp4l[264.033]: master offset 98554559 s0 freq +0 path delay 74143
ptp4l[265.033]: master offset 98013725 s0 freq +0 path delay 74143
ptp4l[266.032]: master offset 97468859 s0 freq +0 path delay 74143
ptp4l[267.032]: master offset 96928505 s0 freq +0 path delay 74143
ptp4l[267.886]: port 1: delay timeout
ptp4l[267.887]: path delay 92372 252146
ptp4l[268.031]: master offset 96367211 s0 freq +0 path delay 92372
ptp4l[269.031]: master offset 95822598 s1 freq -44222 path delay 92372
ptp4l[270.031]: master offset 440 s2 freq -44177 path delay 92372
ptp4l[270.031]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[270.688]: port 1: delay timeout
ptp4l[270.689]: path delay 74143 18259
ptp4l[271.031]: master offset 20279 s2 freq -42173 path delay 74143
ptp4l[272.031]: master offset 20349 s2 freq -42146 path delay 74143
ptp4l[273.031]: master offset 20117 s2 freq -42149 path delay 74143
ptp4l[273.675]: port 1: delay timeout
ptp4l[273.676]: path delay 55915 19779
ptp4l[274.031]: master offset 37265 s2 freq -40397 path delay 55915
ptp4l[275.031]: master offset 43916 s2 freq -39688 path delay 55915
ptp4l[276.031]: master offset 32209 s2 freq -40826 path delay 55915
ptp4l[276.428]: port 1: delay timeout
ptp4l[276.429]: path delay 37856 19798
ptp4l[277.031]: master offset 49835 s2 freq -39014 path delay 37856
ptp4l[278.032]: master offset 43080 s2 freq -39646 path delay 37856
ptp4l[279.031]: master offset 40082 s2 freq -39906 path delay 37856
ptp4l[280.031]: master offset 37553 s2 freq -40121 path delay 37856
ptp4l[281.031]: master offset 40731 s2 freq -39763 path delay 37856
ptp4l[282.031]: master offset 31761 s2 freq -40628 path delay 37856
ptp4l[283.031]: master offset 29417 s2 freq -40833 path delay 37856

My end goal though is to use hardware timestamps and that currently
does not work on the vlan interface simply because the SIOCSHWTSTAMP
ioctl fails. I'm not sure how it is done, but should ptp4l recognize
that it is a vlan interface and perform ioctl and ethtool queries
against the actual device interface? I know the 'ip' tool associates
vlan807 with eth4 so that mapping can be detected somehow:

$ ip addr show vlan807
10: ***@eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:02:c9:31:8b:21 brd ff:ff:ff:ff:ff:ff
inet 10.8.7.20/24 brd 10.8.7.255 scope global vlan807
valid_lft forever preferred_lft forever
inet6 fe80::2:c900:131:8b21/64 scope link
valid_lft forever preferred_lft forever

--
Shawn

Richard Cochran

2013-12-13 15:54:22 UTC

Permalink

Post by Shawn Bohrer
I left the message in but let it continue. It appears to work fine
with software timestamps, or at least I don't see any relevant errors
delay timeout" messages yet.

Those are harmless debug messages that say, "it is time to transmit
another delay request."

Post by Shawn Bohrer
My end goal though is to use hardware timestamps and that currently
does not work on the vlan interface simply because the SIOCSHWTSTAMP
ioctl fails.

For now, if you know the real inteface, you can set the ioctl by hand
using the hwstamp_ctl program. Then, just hack ptp4l to skip over the
ioctl, and it might work for you.

Post by Shawn Bohrer
I'm not sure how it is done, but should ptp4l recognize
that it is a vlan interface and perform ioctl and ethtool queries
against the actual device interface? I know the 'ip' tool associates

I think it would be nicer if the kernel did this for us automatically,
but I'll have to take this up on the netdev list.

Thanks,
Richard

Shawn Bohrer

2013-12-17 19:44:34 UTC

Permalink

Post by Richard Cochran

Post by Shawn Bohrer
I left the message in but let it continue. It appears to work fine
with software timestamps, or at least I don't see any relevant errors
delay timeout" messages yet.

Those are harmless debug messages that say, "it is time to transmit
another delay request."

Excellent ptp4l with software timestamps works just fine on the vlan
interface as long as you omit the ethtool check.

Post by Richard Cochran

Post by Shawn Bohrer
My end goal though is to use hardware timestamps and that currently
does not work on the vlan interface simply because the SIOCSHWTSTAMP
ioctl fails.

For now, if you know the real inteface, you can set the ioctl by hand
using the hwstamp_ctl program. Then, just hack ptp4l to skip over the
ioctl, and it might work for you.

I just finished testing ptp4l with hardware timestamps on the vlan as
well and that works as long as you both omit the ethtool check, and
omit the ioctl. You but then first use the hwstamp_ctl program to
setup the timestamps before you start ptp4l.

Post by Richard Cochran

I think it would be nicer if the kernel did this for us automatically,
but I'll have to take this up on the netdev list.

Cool, I agree that it seems like the kernel should at least pass only
the ethtool information from the actual device for a vlan interface.
What is your suggestion for the ioctl? Should the kernel
automatically perform that on the correct driver as well? Are you
going to raise this on netdev or should I?

Thanks,
Shawn

Keller, Jacob E

2013-12-17 19:55:42 UTC

Permalink

Post by Shawn Bohrer

Post by Richard Cochran

I think it would be nicer if the kernel did this for us automatically,
but I'll have to take this up on the netdev list.

I agree that the kernel could be extended to enable vlans. The trick
being what should be done if the vlan requests it, and the base driver
gets a direct request, which one should be honored? This could get a
little complicated...

When this goes to netdev, I would ilke to be Cc'ed on the discussion.

Regar

Murali Karicheri

2016-05-05 19:46:43 UTC

Permalink

Keller, Jacob E <***@...> writes:

All,

Do you know the status of this fix for ptp over vlan issue?

Murali

Keller, Jacob E

2016-05-05 20:13:55 UTC

Permalink

I don't see the original message you are replying to?

I suspect you mean a patch that fixes software timestamping over vlan
devices?

Regards,
Jake

Post by Murali Karicheri
All,
Do you know the status of this fix for ptp over vlan issue?
Murali

Murali Karicheri

2016-05-05 20:42:06 UTC

Permalink

Post by Keller, Jacob E
I don't see the original message you are replying to?

Couldn't post as the web interface I used complained about not pruning the
message. Here is the original thread

http://comments.gmane.org/gmane.comp.linux.ptp.user/635

Post by Keller, Jacob E
I suspect you mean a patch that fixes software timestamping over vlan
devices?

Yes. Has the patch made into the kernel? We are using hardware based
timestamping and this is needed

Murali

Post by Keller, Jacob E
Regards,
Jake

Post by Murali Karicheri
All,
Do you know the status of this fix for ptp over vlan issue?
Murali

------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

Don Ho

2016-05-05 20:42:32 UTC

Permalink

Please read the response part at the bottom of this email.
I did not have the latest kernel of v3.19. I have a working VLAN PTP
configured with the older way .

If you are interested in using ptp4l/phc2sys hardware timestamp on
vlan, the following instruction is working on my system.
Someone may ask why VLAN, why I can just have the interfaces on
different NIC cards. Sure you can. But if you want to reduce the
number of cables, NIC cards, and may be switches. VLAN is the
solution.
Many thanks to Shawn Bohrer for helping me to make this configuration work.

I am suprised that you need to change ptp4l in order to work with VLAN
interfaces. I thought that I had fixed this in the kernel:

commit 37dd9255b2f6201195946014600a8d857f846cf4
Author: Richard Cochran <***@gmail.com>
Date: Fri Nov 21 14:16:20 2014 +0100

vlan: Pass ethtool get_ts_info queries to real device.

Commit a6111d3c "vlan: Pass SIOC[SG]HWTSTAMP ioctls to real device"
intended to enable hardware time stamping on VLAN interfaces, but
passing SIOCSHWTSTAMP is only half of the story. This patch adds
the second half, by letting user space find out the time stamping
capabilities of the device backing a VLAN interface.

Commit 37dd9255 is in kernel v3.19, and commit a6111d3c is in v3.17.
What kernel version are you using?

Thanks,
Richard

On Thu, May 5, 2016 at 4:13 PM, Keller, Jacob E

I don't see the original message you are replying to?
I suspect you mean a patch that fixes software timestamping over vlan
devices?
Regards,
Jake

Post by Murali Karicheri
All,
Do you know the status of this fix for ptp over vlan issue?
Murali