[net-next,RFC,5/5] net-timestamp: tx timestamping default mode flag

From: Willem de Bruijn <willemb@google.com>

The number of timestamping points along the transmit path has grown,
as have the options. Preferred behavior is to request timestamps with
ID, without data (which enables batching) and for all supported
timestamp points. Define a short option that enables all these
defaults.

Signed-off-by: Willem de Bruijn <willemb@google.com>
---
 include/uapi/linux/net_tstamp.h | 8 ++++++++
 1 file changed, 8 insertions(+)

On Fri, Jan 09, 2015 at 12:31:59PM -0500, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
> 
> The number of timestamping points along the transmit path has grown,
> as have the options. Preferred behavior is to request timestamps with
> ID, without data (which enables batching) and for all supported
> timestamp points. Define a short option that enables all these
> defaults.

This "preferred behavior" is subjective, and it depends on the
application.  I am sure it reflects your own interest, but for people
doing PTP over UDP or raw, it is a bit misleading.

I would drop this default and just let applications define their own.

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

On Sun, Jan 11, 2015 at 3:32 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Fri, Jan 09, 2015 at 12:31:59PM -0500, Willem de Bruijn wrote:
>> From: Willem de Bruijn <willemb@google.com>
>>
>> The number of timestamping points along the transmit path has grown,
>> as have the options. Preferred behavior is to request timestamps with
>> ID, without data (which enables batching) and for all supported
>> timestamp points. Define a short option that enables all these
>> defaults.
>
> This "preferred behavior" is subjective, and it depends on the
> application.  I am sure it reflects your own interest, but for people
> doing PTP over UDP or raw, it is a bit misleading.
>
> I would drop this default and just let applications define their own.

Okay. I indeed hadn't considered that use-case.

Just so I understand: ptp has no use for the sw tstamps
that would be generated with this flag, but is otherwise
okay with enabling counters to order tx timestamps
(OPT_ID) and disabling payload (OPT_TSONLY)?

In the documentation, I would like to strongly suggest all
processes to enable these, even in absence of this default.
because that is more robust wrt the sysctl (if merged).

>
> Thanks,

Thanks for taking a look at the patches.

> Richard
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Sun, Jan 11, 2015 at 08:49:00PM -0500, Willem de Bruijn wrote:
> Just so I understand: ptp has no use for the sw tstamps
> that would be generated with this flag, but is otherwise
> okay with enabling counters to order tx timestamps
> (OPT_ID) and disabling payload (OPT_TSONLY)?

Yes.

> In the documentation, I would like to strongly suggest all
> processes to enable these, even in absence of this default.
> because that is more robust wrt the sysctl (if merged).

Sounds good.

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