lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a2d8d888-16e1-243d-92c9-56ba3a3e1b18@gmail.com>
Date:   Mon, 16 Dec 2019 11:33:01 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Martin Lau <kafai@...com>, Eric Dumazet <eric.dumazet@...il.com>
Cc:     "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@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH bpf-next 09/13] bpf: Add BPF_FUNC_jiffies



On 12/16/19 11:14 AM, Martin Lau wrote:
> On Fri, Dec 13, 2019 at 05:59:54PM -0800, Eric Dumazet wrote:
>>
>>
>> On 12/13/19 4:47 PM, Martin KaFai Lau wrote:
>>> This patch adds a helper to handle jiffies.  Some of the
>>> tcp_sock's timing is stored in jiffies.  Although things
>>> could be deduced by CONFIG_HZ, having an easy way to get
>>> jiffies will make the later bpf-tcp-cc implementation easier.
>>>
>>
>> ...
>>
>>> +
>>> +BPF_CALL_2(bpf_jiffies, u64, in, u64, flags)
>>> +{
>>> +	if (!flags)
>>> +		return get_jiffies_64();
>>> +
>>> +	if (flags & BPF_F_NS_TO_JIFFIES) {
>>> +		return nsecs_to_jiffies(in);
>>> +	} else if (flags & BPF_F_JIFFIES_TO_NS) {
>>> +		if (!in)
>>> +			in = get_jiffies_64();
>>> +		return jiffies_to_nsecs(in);
>>> +	}
>>> +
>>> +	return 0;
>>> +}
>>
>> This looks a bit convoluted :)
>>
>> Note that we could possibly change net/ipv4/tcp_cubic.c to no longer use jiffies at all.
>>
>> We have in tp->tcp_mstamp an accurate timestamp (in usec) that can be converted to ms.
> Thanks for the feedbacks!
> 
> I have a few questions that need some helps.
> 
> Does it mean tp->tcp_mstamp can be used as the "now" in cubic?

TCP makes sure to update tp->tcp_mstamp at least once when handling
a particular packet. We did that to avoid calling possibly expensive
kernel time service (Some platforms do not have fast TSC) 

> or tcp_clock_ns() should still be called in cubic, e.g. to replace
> bictcp_clock() and tcp_jiffies32?

Yeah, there is this lsndtime and tcp_jiffies32 thing, but maybe
we can find a way to fetch jiffies32 without having to call a bpf helper ?

> 
> BPF currently has a helper calling ktime_get_mono_fast_ns() which looks
> different from tcp_clock_ns().

That's maybe because of NMI requirements. 

TCP in the other hand is in process or BH context.

But it should not matter, cubic could should not have to call them.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ