[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQL9xKcdCyR+-8irH07Ws7iKHjrE4XNb4OA7BkpBrkkEuA@mail.gmail.com>
Date: Sun, 23 May 2021 08:58:33 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
Lorenz Bauer <lmb@...udflare.com>,
Network Development <netdev@...r.kernel.org>,
bpf <bpf@...r.kernel.org>, Kernel Team <kernel-team@...com>
Subject: Re: [RFC PATCH bpf-next] bpf: Introduce bpf_timer
On Sun, May 23, 2021 at 4:48 AM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> Still wrapping my head around this, but one thing immediately sprang to
> mind:
>
> > + * long bpf_timer_mod(struct bpf_timer *timer, u64 msecs)
> > + * Description
> > + * Set the timer expiration N msecs from the current time.
> > + * Return
> > + * zero
>
> Could we make this use nanoseconds (and wire it up to hrtimers) instead?
> I would like to eventually be able to use this for pacing out network
> packets, and msec precision is way too coarse for that...
msecs are used to avoid exposing jiffies to bpf prog, since msec_to_jiffies
isn't trivial to do in the bpf prog unlike the kernel.
hrtimer would be great to support as well.
It could be implemented via flags (which are currently zero only)
but probably not as a full replacement for jiffies based timers.
Like array vs hash. bpf_timer can support both.
Powered by blists - more mailing lists