From: Miroslav Lichvar <mlichvar@redhat.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.
Date: Tue, 13 Feb 2018 10:56:52 +0100 [thread overview]
Message-ID: <20180213095652.GA11459@localhost> (raw)
In-Reply-To: <d30c45f7-0091-3701-4ffe-3bc712f6436b@intel.com>
On Mon, Feb 12, 2018 at 02:39:06PM -0800, Jesus Sanchez-Palencia wrote:
> On 01/18/2018 12:42 AM, Miroslav Lichvar wrote:
> > Please keep in mind that the PHCs and the system clock don't have to
> > be synchronized to each other. If I understand the rest of the series
> > correctly, there is an assumption that the PHCs are keeping time in
> > TAI and CLOCK_TAI can be used as a fallback.
>
> Just to double-check, imagine that I've configured the qdisc for
> SW best-effort and with clockid CLOCK_REALTIME. When it receives a
> packet with the clockid of a /dev/ptpX, the qdisc should just drop that
> packet, right?
Yes, I think it should drop it. The kernel does not know the offset
between the two clocks (they don't even have to be synchronized), so
it cannot convert a PHC-based TX time to the system time.
--
Miroslav Lichvar
WARNING: multiple messages have this Message-ID (diff)
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
Cc: netdev@vger.kernel.org, john.stultz@linaro.org,
Richard Cochran <rcochran@linutronix.de>,
jiri@resnulli.us, ivan.briano@intel.com,
richardcochran@gmail.com, henrik@austad.us, jhs@mojatatu.com,
levi.pearson@harman.com, intel-wired-lan@lists.osuosl.org,
xiyou.wangcong@gmail.com, tglx@linutronix.de,
anna-maria@linutronix.de
Subject: Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.
Date: Tue, 13 Feb 2018 10:56:52 +0100 [thread overview]
Message-ID: <20180213095652.GA11459@localhost> (raw)
In-Reply-To: <d30c45f7-0091-3701-4ffe-3bc712f6436b@intel.com>
On Mon, Feb 12, 2018 at 02:39:06PM -0800, Jesus Sanchez-Palencia wrote:
> On 01/18/2018 12:42 AM, Miroslav Lichvar wrote:
> > Please keep in mind that the PHCs and the system clock don't have to
> > be synchronized to each other. If I understand the rest of the series
> > correctly, there is an assumption that the PHCs are keeping time in
> > TAI and CLOCK_TAI can be used as a fallback.
>
> Just to double-check, imagine that I've configured the qdisc for
> SW best-effort and with clockid CLOCK_REALTIME. When it receives a
> packet with the clockid of a /dev/ptpX, the qdisc should just drop that
> packet, right?
Yes, I think it should drop it. The kernel does not know the offset
between the two clocks (they don't even have to be synchronized), so
it cannot convert a PHC-based TX time to the system time.
--
Miroslav Lichvar
next prev parent reply other threads:[~2018-02-13 9:56 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-17 23:06 [Intel-wired-lan] [RFC v2 net-next 00/10] Time based packet transmission Jesus Sanchez-Palencia
2018-01-17 23:06 ` Jesus Sanchez-Palencia
2018-01-17 23:06 ` [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time Jesus Sanchez-Palencia
2018-01-17 23:06 ` Jesus Sanchez-Palencia
2018-01-18 8:42 ` [Intel-wired-lan] " Miroslav Lichvar
2018-01-18 8:42 ` Miroslav Lichvar
2018-01-18 17:13 ` Richard Cochran
2018-01-18 17:13 ` Richard Cochran
2018-02-01 0:49 ` Jesus Sanchez-Palencia
2018-02-01 0:49 ` Jesus Sanchez-Palencia
2018-02-01 4:16 ` Richard Cochran
2018-02-01 4:16 ` Richard Cochran
2018-02-01 9:27 ` Miroslav Lichvar
2018-02-01 9:27 ` Miroslav Lichvar
2018-02-01 20:55 ` Jesus Sanchez-Palencia
2018-02-01 20:55 ` Jesus Sanchez-Palencia
2018-01-23 21:22 ` Vinicius Costa Gomes
2018-01-23 21:22 ` Vinicius Costa Gomes
2018-01-24 3:04 ` Richard Cochran
2018-01-24 3:04 ` Richard Cochran
2018-01-24 22:46 ` Vinicius Costa Gomes
2018-01-24 22:46 ` Vinicius Costa Gomes
2018-01-26 2:12 ` Richard Cochran
2018-01-26 2:12 ` Richard Cochran
2018-02-12 22:39 ` Jesus Sanchez-Palencia
2018-02-12 22:39 ` Jesus Sanchez-Palencia
2018-02-13 9:56 ` Miroslav Lichvar [this message]
2018-02-13 9:56 ` Miroslav Lichvar
2018-01-18 17:11 ` Richard Cochran
2018-01-18 17:11 ` Richard Cochran
2018-01-23 18:12 ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-23 18:12 ` Jesus Sanchez-Palencia
2018-01-19 21:15 ` [Intel-wired-lan] " Willem de Bruijn
2018-01-19 21:15 ` Willem de Bruijn
2018-01-20 2:09 ` [Intel-wired-lan] " Richard Cochran
2018-01-20 2:09 ` Richard Cochran
2018-01-25 9:12 ` [Intel-wired-lan] " Miroslav Lichvar
2018-01-25 9:12 ` Miroslav Lichvar
2018-01-25 16:52 ` Richard Cochran
2018-01-25 16:52 ` Richard Cochran
2018-01-23 18:24 ` Jesus Sanchez-Palencia
2018-01-23 18:24 ` Jesus Sanchez-Palencia
2018-01-23 20:02 ` [Intel-wired-lan] " Willem de Bruijn
2018-01-23 20:02 ` Willem de Bruijn
2018-01-17 23:06 ` [Intel-wired-lan] [RFC v2 net-next 02/10] net: ipv4: raw: Hook into time based transmission Jesus Sanchez-Palencia
2018-01-17 23:06 ` Jesus Sanchez-Palencia
2018-01-18 0:28 ` [Intel-wired-lan] " Eric Dumazet
2018-01-18 0:28 ` Eric Dumazet
2018-01-17 23:06 ` [Intel-wired-lan] [RFC v2 net-next 03/10] net: ipv4: udp: " Jesus Sanchez-Palencia
2018-01-17 23:06 ` Jesus Sanchez-Palencia
2018-01-17 23:06 ` [Intel-wired-lan] [RFC v2 net-next 04/10] net: packet: " Jesus Sanchez-Palencia
2018-01-17 23:06 ` Jesus Sanchez-Palencia
2018-01-17 23:06 ` [Intel-wired-lan] [RFC v2 net-next 05/10] net/sched: Allow creating a Qdisc watchdog with other clocks Jesus Sanchez-Palencia
2018-01-17 23:06 ` Jesus Sanchez-Palencia
2018-01-17 23:06 ` [Intel-wired-lan] [RFC v2 net-next 06/10] net/sched: Introduce the TBS Qdisc Jesus Sanchez-Palencia
2018-01-17 23:06 ` Jesus Sanchez-Palencia
2018-01-18 13:35 ` [Intel-wired-lan] " Jamal Hadi Salim
2018-01-18 13:35 ` Jamal Hadi Salim
2018-01-18 13:44 ` [Intel-wired-lan] " Jamal Hadi Salim
2018-01-18 13:44 ` Jamal Hadi Salim
2018-01-23 21:45 ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-23 21:45 ` Jesus Sanchez-Palencia
2018-01-18 17:18 ` [Intel-wired-lan] " Richard Cochran
2018-01-18 17:18 ` Richard Cochran
2018-01-23 22:01 ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-23 22:01 ` Jesus Sanchez-Palencia
2018-01-19 21:18 ` [Intel-wired-lan] " Willem de Bruijn
2018-01-19 21:18 ` Willem de Bruijn
2018-01-17 23:06 ` [Intel-wired-lan] [RFC v2 net-next 07/10] igb: Refactor igb_configure_cbs() Jesus Sanchez-Palencia
2018-01-17 23:06 ` Jesus Sanchez-Palencia
2018-01-17 23:06 ` [Intel-wired-lan] [RFC v2 net-next 08/10] igb: Only change Tx arbitration when CBS is on Jesus Sanchez-Palencia
2018-01-17 23:06 ` Jesus Sanchez-Palencia
2018-01-17 23:06 ` [Intel-wired-lan] [RFC v2 net-next 09/10] igb: Refactor igb_offload_cbs() Jesus Sanchez-Palencia
2018-01-17 23:06 ` Jesus Sanchez-Palencia
2018-01-17 23:06 ` [Intel-wired-lan] [RFC v2 net-next 10/10] igb: Add support for TBS offload Jesus Sanchez-Palencia
2018-01-17 23:06 ` Jesus Sanchez-Palencia
2018-01-23 5:23 ` [Intel-wired-lan] [RFC v2 net-next 00/10] Time based packet transmission Richard Cochran
2018-01-23 5:23 ` Richard Cochran
2018-01-23 5:26 ` [Intel-wired-lan] " Richard Cochran
2018-01-23 5:26 ` Richard Cochran
2018-01-23 18:07 ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-23 18:07 ` Jesus Sanchez-Palencia
2018-01-24 1:43 ` [Intel-wired-lan] " Levi Pearson
2018-01-24 1:43 ` Levi Pearson
2018-01-27 0:04 ` [Intel-wired-lan] " Jesus Sanchez-Palencia
2018-01-27 0:04 ` Jesus Sanchez-Palencia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180213095652.GA11459@localhost \
--to=mlichvar@redhat.com \
--cc=intel-wired-lan@osuosl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.