[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+FuTScWkYn0Ur+aSuz1cREbQJO0fB6powOm8PFxze4v8JwBaw@mail.gmail.com>
Date: Wed, 9 Dec 2020 09:48:53 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Erez Geva <erez.geva.ext@...mens.com>
Cc: Network Development <netdev@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-arch@...r.kernel.org,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
Arnd Bergmann <arnd@...db.de>,
Cong Wang <xiyou.wangcong@...il.com>,
"David S . Miller" <davem@...emloft.net>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Jakub Kicinski <kuba@...nel.org>,
Jamal Hadi Salim <jhs@...atatu.com>,
Jiri Pirko <jiri@...nulli.us>,
Alexei Starovoitov <ast@...nel.org>,
Colin Ian King <colin.king@...onical.com>,
Daniel Borkmann <daniel@...earbox.net>,
Eric Dumazet <edumazet@...gle.com>,
Eyal Birger <eyal.birger@...il.com>,
"Gustavo A . R . Silva" <gustavoars@...nel.org>,
Jakub Sitnicki <jakub@...udflare.com>,
John Ogness <john.ogness@...utronix.de>,
Jon Rosen <jrosen@...co.com>,
Kees Cook <keescook@...omium.org>,
Mao Wenan <maowenan@...wei.com>,
Marc Kleine-Budde <mkl@...gutronix.de>,
Martin KaFai Lau <kafai@...com>,
Matthieu Baerts <matthieu.baerts@...sares.net>,
Andrei Vagin <avagin@...il.com>,
Dmitry Safonov <0x7f454c46@...il.com>,
"Eric W . Biederman" <ebiederm@...ssion.com>,
Ingo Molnar <mingo@...nel.org>,
John Stultz <john.stultz@...aro.org>,
Miaohe Lin <linmiaohe@...wei.com>,
Michal Kubecek <mkubecek@...e.cz>,
Or Cohen <orcohen@...oaltonetworks.com>,
Oleg Nesterov <oleg@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Richard Cochran <richardcochran@...il.com>,
Stefan Schmidt <stefan@...enfreihafen.org>,
Xie He <xie.he.0141@...il.com>,
Stephen Boyd <sboyd@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Vladis Dronov <vdronov@...hat.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Frederic Weisbecker <frederic@...nel.org>,
Vinicius Costa Gomes <vinicius.gomes@...el.com>,
Vedang Patel <vedang.patel@...el.com>,
Ines Molzahn <ines.molzahn@...mens.com>,
Simon Sudler <simon.sudler@...mens.com>,
Andreas Meisinger <andreas.meisinger@...mens.com>,
Andreas Bucher <andreas.bucher@...mens.com>,
Henning Schild <henning.schild@...mens.com>,
Jan Kiszka <jan.kiszka@...mens.com>,
Andreas Zirkler <andreas.zirkler@...mens.com>,
Ermin Sakic <ermin.sakic@...mens.com>,
An Ninh Nguyen <anninh.nguyen@...mens.com>,
Michael Saenger <michael.saenger@...mens.com>,
Bernd Maehringer <bernd.maehringer@...mens.com>,
Gisela Greinert <gisela.greinert@...mens.com>,
Erez Geva <ErezGeva2@...il.com>
Subject: Re: [PATCH 1/3] Add TX sending hardware timestamp.
On Wed, Dec 9, 2020 at 9:37 AM Erez Geva <erez.geva.ext@...mens.com> wrote:
>
> Configure and send TX sending hardware timestamp from
> user space application to the socket layer,
> to provide to the TC ETC Qdisc, and pass it to
> the interface network driver.
>
> - New flag for the SO_TXTIME socket option.
> - New access auxiliary data header to pass the
> TX sending hardware timestamp.
> - Add the hardware timestamp to the socket cookie.
> - Copy the TX sending hardware timestamp to the socket cookie.
>
> Signed-off-by: Erez Geva <erez.geva.ext@...mens.com>
Hardware offload of pacing is definitely useful.
I don't think this needs a new separate h/w variant of SO_TXTIME.
Indeed, we want pacing offload to work for existing applications.
It only requires that pacing qdiscs, both sch_etf and sch_fq,
optionally skip queuing in their .enqueue callback and instead allow
the skb to pass to the device driver as is, with skb->tstamp set. Only
to devices that advertise support for h/w pacing offload.
Powered by blists - more mailing lists