[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180308164418.f3vmql2kluvattq6@localhost>
Date: Thu, 8 Mar 2018 08:44:18 -0800
From: Richard Cochran <richardcochran@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
Eric Dumazet <eric.dumazet@...il.com>,
Jesus Sanchez-Palencia <jesus.sanchez-palencia@...el.com>,
Network Development <netdev@...r.kernel.org>,
Jamal Hadi Salim <jhs@...atatu.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Jiří Pírko <jiri@...nulli.us>,
Vinicius Gomes <vinicius.gomes@...el.com>,
intel-wired-lan@...ts.osuosl.org, anna-maria@...utronix.de,
Henrik Austad <henrik@...tad.us>,
Thomas Gleixner <tglx@...utronix.de>,
John Stultz <john.stultz@...aro.org>,
Levi Pearson <levi.pearson@...man.com>,
Willem de Bruijn <willemb@...gle.com>,
Miroslav Lichvar <mlichvar@...hat.com>
Subject: Re: [RFC v3 net-next 08/18] net: SO_TXTIME: Add clockid and
drop_if_late params
On Wed, Mar 07, 2018 at 09:47:40AM -0800, Eric Dumazet wrote:
> I would love if skb->tstamp could be either 0 or expressed in
> ktime_get() base all the time.
>
> ( Even if we would have to convert this to other bases when/if needed)
We really do need variable clock IDs. Otherwise the HW offloading
case won't work. The desired transmit time must be expressed in terms
of the clock inside the MAC. This clock is not necessarily related to
the system time at all.
But in addition to the performance concerns, I think putting this into
a socket option is the more natural solution.
Thanks,
Richard
Powered by blists - more mailing lists