linuxptp-users

[Linuxptp-users] using ptp4l on vlan interfaces

[Shawn B. <sha...@gm...>]

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

Re: [Linuxptp-users] using ptp4l on vlan interfaces

[Keller, J. E <jac...@in...>]

> -----Original Message-----
> From: Shawn Bohrer [mailto:sha...@gm...]
> Sent: Tuesday, December 10, 2013 10:48 AM
> To: lin...@li...
> 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
> 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?


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
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] using ptp4l on vlan interfaces

[Richard C. <ric...@gm...>]

On Tue, Dec 10, 2013 at 08:58:26PM +0000, Keller, Jacob E wrote:
> 
> 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

Re: [Linuxptp-users] using ptp4l on vlan interfaces

[Richard C. <ric...@gm...>]

On Tue, Dec 10, 2013 at 12:47:32PM -0600, Shawn Bohrer wrote:
> 
> 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

Re: [Linuxptp-users] using ptp4l on vlan interfaces

[Shawn B. <sha...@gm...>]

On Wed, Dec 11, 2013 at 08:29:43AM +0100, Richard Cochran wrote:
> On Tue, Dec 10, 2013 at 12:47:32PM -0600, Shawn Bohrer wrote:
> > 
> > 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.

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.

root@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: vlan807@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

Re: [Linuxptp-users] using ptp4l on vlan interfaces

[Richard C. <ric...@gm...>]

On Wed, Dec 11, 2013 at 03:42:09PM -0600, Shawn Bohrer wrote:
 
> 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.

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

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

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

Re: [Linuxptp-users] using ptp4l on vlan interfaces

[Shawn B. <sha...@gm...>]

On Fri, Dec 13, 2013 at 04:54:22PM +0100, Richard Cochran wrote:
> On Wed, Dec 11, 2013 at 03:42:09PM -0600, Shawn Bohrer wrote:
>  
> > 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.
> 
> 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.

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

Re: [Linuxptp-users] using ptp4l on vlan interfaces

[Keller, J. E <jac...@in...>]

On Tue, 2013-12-17 at 13:44 -0600, Shawn Bohrer wrote:
> > >  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:
> > 
> > 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

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.

Regards,
Jake

Re: [Linuxptp-users] using ptp4l on vlan interfaces

[Murali K. <m-k...@ti...>]

Keller, Jacob E <jacob.e.keller@...> writes:

All,

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

Murali

Re: [Linuxptp-users] using ptp4l on vlan interfaces

[Keller, J. E <jac...@in...>]

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

On Thu, 2016-05-05 at 19:46 +0000, Murali Karicheri wrote:
> Keller, Jacob E <jacob.e.keller@...> writes:
> 
> All,
> 
> Do you know the status of this fix for ptp over vlan issue?
> 
> Murali
> 

Re: [Linuxptp-users] using ptp4l on vlan interfaces

[Don Ho <don...@gm...>]

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 .

On Wed, Dec 02, 2015 at 03:34:57PM -0500, Don Ho wrote:
> 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 <ric...@gm...>
    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
<jac...@in...> wrote:
> 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
>
> On Thu, 2016-05-05 at 19:46 +0000, Murali Karicheri wrote:
>> Keller, Jacob E <jacob.e.keller@...> writes:
>>
>> 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
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users

Re: [Linuxptp-users] using ptp4l on vlan interfaces

[Murali K. <m-k...@ti...>]

Keller, Jacob E <jacob.e.keller@...> writes:

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

> 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
> 
> Regards,
> Jake
> 
> On Thu, 2016-05-05 at 19:46 +0000, Murali Karicheri wrote:
> > Keller, Jacob E <jacob.e.keller <at> ...> writes:
> > 
> > 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
>