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 ass
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 time in a CMSG when calling
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 toda
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
> clockid_
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
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
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, w
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 timesp
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 kt
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 not quite possible right no
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 th
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 time in a CMSG when calling
>> sendmsg(2).
>>
>>
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 whe
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 added to struct sockcm_co
14 matches
Mail list logo