[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48fa41ef-c777-360a-279d-c71d0a5b6c47@gmail.com>
Date: Tue, 17 Dec 2019 13:04:03 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Martin Lau <kafai@...com>, Jakub Sitnicki <jakub@...udflare.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
Neal Cardwell <ncardwell@...gle.com>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
David Miller <davem@...emloft.net>,
Kernel Team <Kernel-team@...com>,
Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH bpf-next 09/13] bpf: Add BPF_FUNC_jiffies
> Andrii's extern variable work (already landed) allows a bpf_prog
> to read CONFIG_HZ as a global variable. It is the path that I am
> pursuing now for jiffies/nsecs conversion without relying on
> a helper.
I am traveling today, but plan sending a patch series for cubic,
switching to usec resolution to solve its inability to properly
detect ack trains in the datacenter.
But still it will use jiffies32 in some spots,
as you mentioned already because of tp->lsndtime.
This means bpf could also stick to tp->tcp_mstamp
extract :
-static inline u32 bictcp_clock(void)
+static inline u32 bictcp_clock_us(const struct sock *sk)
{
-#if HZ < 1000
- return ktime_to_ms(ktime_get_real());
-#else
- return jiffies_to_msecs(jiffies);
-#endif
+ return tcp_sk(sk)->tcp_mstamp;
}
Powered by blists - more mailing lists