Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

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

Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

Hi, On 01/18/2018 12:42 AM, Miroslav Lichvar wrote: > On Wed, Jan 17, 2018 at 03:06:12PM -0800, Jesus Sanchez-Palencia wrote: >> From: Richard Cochran >> >> This patch introduces SO_TXTIME. User space enables this option in >> order to pass a desired future transmit

Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

Hi, On 02/01/2018 01:27 AM, Miroslav Lichvar wrote: > On Wed, Jan 31, 2018 at 04:49:36PM -0800, Jesus Sanchez-Palencia wrote: >> On 01/18/2018 09:13 AM, Richard Cochran wrote: >>> Right, the clockid_t should be passed in through the CMSG along with >>> the time. >> >> While implementing this

Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

On Wed, Jan 31, 2018 at 04:49:36PM -0800, Jesus Sanchez-Palencia wrote: > On 01/18/2018 09:13 AM, Richard Cochran wrote: > > Right, the clockid_t should be passed in through the CMSG along with > > the time. > > While implementing this today it crossed my mind that why don't we have the >

Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

On Wed, Jan 31, 2018 at 04:49:36PM -0800, Jesus Sanchez-Palencia wrote: > While implementing this today it crossed my mind that why don't we have the > clockid_t set per socket (e.g. as an argument to SO_TXTIME) instead of per > packet? Sounds good to me. Thanks, Richard

Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

Hi, On 01/18/2018 09:13 AM, Richard Cochran wrote: > On Thu, Jan 18, 2018 at 09:42:27AM +0100, Miroslav Lichvar wrote: >> In the discussion about the v1 patchset, there was a question if the >> cmsg should include a clockid_t. Without that, how can an application >> prevent the packet from being

Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

On Wed, Jan 24, 2018 at 02:46:24PM -0800, Vinicius Costa Gomes wrote: > The only robust way that we could think of about keeping the the packets > in order for the device queue is re-ordering packets in the Qdisc. Right, but you cannot afford the overhead of the timerqueue when using HW offload,

Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

On Thu, Jan 25, 2018 at 10:12:25AM +0100, Miroslav Lichvar wrote: > Do I understand it correctly that no other interface is using > nanoseconds since 1970? We probably don't have to worry about year > 2262 yet, but wouldn't it be better to make it consistent with the > timestamping API using

Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

On Fri, Jan 19, 2018 at 06:09:15PM -0800, Richard Cochran wrote: > On Fri, Jan 19, 2018 at 04:15:46PM -0500, Willem de Bruijn wrote: > > > + if (cmsg->cmsg_len != CMSG_LEN(sizeof(ktime_t))) > > > + return -EINVAL; > > > > I don't see any existing reference to

Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

Hi Richard, Richard Cochran writes: > On Tue, Jan 23, 2018 at 01:22:37PM -0800, Vinicius Costa Gomes wrote: >> What I think would be the ideal scenario would be if the clockid >> parameter to the TBS Qdisc would not be necessary (if offload was >> enabled), but that's

Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

On Tue, Jan 23, 2018 at 01:22:37PM -0800, Vinicius Costa Gomes wrote: > What I think would be the ideal scenario would be if the clockid > parameter to the TBS Qdisc would not be necessary (if offload was > enabled), but that's not quite possible right now, because there's no > support for using

Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

Hi, Miroslav Lichvar writes: > On Wed, Jan 17, 2018 at 03:06:12PM -0800, Jesus Sanchez-Palencia wrote: >> From: Richard Cochran >> >> This patch introduces SO_TXTIME. User space enables this option in >> order to pass a desired future transmit

Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

On Thu, Jan 18, 2018 at 09:42:27AM +0100, Miroslav Lichvar wrote: > In the discussion about the v1 patchset, there was a question if the > cmsg should include a clockid_t. Without that, how can an application > prevent the packet from being sent using an incorrect clock, e.g. > the system clock

Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time.

On Wed, Jan 17, 2018 at 03:06:12PM -0800, Jesus Sanchez-Palencia wrote: > From: Richard Cochran > > This patch introduces SO_TXTIME. User space enables this option in > order to pass a desired future transmit time in a CMSG when calling > sendmsg(2). > > A new field is