Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver

On Fri, Feb 27, 2015 at 05:09:24PM +0000, Stathis Voukelatos wrote:

To summarize (and confirm my understanding) your suggestion is for the
sniffer to be configured to match PTP packets and (similarly to the
dp83640) return the Message Type and Sequence Id fields that will allow
them to be matched to an sk_buf that has been passed from the stack.
Then the sk_buf can be timestamped using the sniffer timestamp.

Yes.
 

The H/W does have the capability to do that. However, in order to
implement it there will be some architectural changes needed
in the kernel. This module cannot really pretend to be a PHY.
In the real world it sits between the MAC and the PHY.

Right.

Here is one idea.  Put a link to the TS device in the PHY's DT node.
Then, in phy_probe, check if the PHY's four methods, ts_info,
hwtstamp, rxtstamp, and txtstamp, are all null.  If so, check for a DT
link from the PHY's node to a TS device driver.  If found, then set
the four methods to call into the TS driver's callbacks.

Just off of the top of my head.

Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Richard,

On 27/02/15 18:14, Richard Cochran wrote:

quoted

The H/W does have the capability to do that. However, in order to
implement it there will be some architectural changes needed
in the kernel. This module cannot really pretend to be a PHY.
In the real world it sits between the MAC and the PHY.

Right.

Here is one idea.  Put a link to the TS device in the PHY's DT node.
Then, in phy_probe, check if the PHY's four methods, ts_info,
hwtstamp, rxtstamp, and txtstamp, are all null.  If so, check for a DT
link from the PHY's node to a TS device driver.  If found, then set
the four methods to call into the TS driver's callbacks.

Just off of the top of my head.

Thank you for your help and suggestions.

Although the PTP way appears to be the best from an architectural point
of view, we have some questions as whether it is suitable for the audio
use cases that this module is mainly intended for.
To use the PTP terminology in a large installation we would have a
potentially large number of clock domains.
It is not clear how to easily manage the creation and allocation of domains. In addition the clock will be pulled according to the audio
stream and it would be undesirable for other unrelated PTPv2 devices
on the network to join the clock domain and have their clocks synchronized to it.

The patch in its current form would allow a move to Linux using our
existing synchronization protocols (which are open-source). A move
to PTP is something to consider but will involve a fair amount of
redesign including upgrade of legacy products.

Thanks,
Richard

Thank you,
Stathis
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BTW I am getting doubles of your messages, both addressed to the
mailings lists, but only one also addressed to me.  You should just
send one copy, with everyone on CC.

Thanks,
Richard