On Tue, Feb 13, 2018 at 06:04:55PM +0100, Petr Kulhavy wrote:
> Let me develop this idea further. What about splitting the transportSpecific
> into the two nibbles, where lower nibble is as now and the upper nibble is a
> mask telling which bits to ignore on RX.

I think it would less confusing to simply have a new configuration
item.  It could be:

   transport_specific_ignore [0|1]

   When set, the transportSpecific field of incoming messages is
   ignored.

   (untested patch, below)

In my view, this would be enough.  I doubt we will get to the point of
needing individual bits ignored.

> One more thing to mention here. The different tools are still not aligned on
> the configuration. So while ptp4l takes the transportSpecific value from the
> config file, pmc from the command line, phc2sys doesn't have this option.
> Would this approach still work also with phc2sys?

The phc2sys program has enough command line options as is.  It would
be useful to add one last option, phc2sys -f [file].
 
> And does it make sense to require full match of transportSpecific on UDS?

It isn't needed, of course, but for the sake of consistency it makes
sense.  You can send management messages locally via UDS, and
depending on the value of 'boundary_hops' these are forwarded out the
network interfaces.  So we really want to treat UDS in the same way.

Thanks,
Richard

---
diff --git a/config.c b/config.c
index bbaf36e..4c30214 100644
--- a/config.c
+++ b/config.c
@@ -192,6 +192,7 @@ struct config_item config_tab[] = {
        PORT_ITEM_INT("freq_est_interval", 1, 0, INT_MAX),
        GLOB_ITEM_INT("gmCapable", 1, 0, 1),
        PORT_ITEM_INT("hybrid_e2e", 0, 0, 1),
+       PORT_ITEM_INT("ignore_transport_specific", 0, 0, 1),
        PORT_ITEM_INT("ingressLatency", 0, INT_MIN, INT_MAX),
        GLOB_ITEM_INT("kernel_leap", 1, 0, 1),
        PORT_ITEM_INT("logAnnounceInterval", 1, INT8_MIN, INT8_MAX),
diff --git a/port.c b/port.c
index d8e29d5..9bf2c39 100644
--- a/port.c
+++ b/port.c
@@ -125,6 +125,7 @@ struct port {
        int                 follow_up_info;
        int                 freq_est_interval;
        int                 hybrid_e2e;
+       int                 match_transport_specific;
        int                 min_neighbor_prop_delay;
        int                 path_trace_enabled;
        int                 rx_timestamp_offset;
@@ -641,7 +642,8 @@ static int port_ignore(struct port *p, struct ptp_message 
*m)
        if (path_trace_ignore(p, m)) {
                return 1;
        }
-       if (msg_transport_specific(m) != p->transportSpecific) {
+       if (p->match_transport_specific &&
+           msg_transport_specific(m) != p->transportSpecific) {
                return 1;
        }
        if (pid_eq(&m->header.sourcePortIdentity, &p->portIdentity)) {
@@ -1489,6 +1491,7 @@ static int port_initialize(struct port *p)
        p->syncReceiptTimeout      = config_get_int(cfg, p->name, 
"syncReceiptTimeout");
        p->transportSpecific       = config_get_int(cfg, p->name, 
"transportSpecific");
        p->transportSpecific     <<= 4;
+       p->match_transport_specific = !config_get_int(cfg, p->name, 
"ignore_transport_specific");
        p->logSyncInterval         = config_get_int(cfg, p->name, 
"logSyncInterval");
        p->logMinPdelayReqInterval = config_get_int(cfg, p->name, 
"logMinPdelayReqInterval");
        p->neighborPropDelayThresh = config_get_int(cfg, p->name, 
"neighborPropDelayThresh");

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Reply via email to