netdev - Re: [PATCH bpf-next v3 0/6] Introduce the BPF dispatcher

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] [day] [month] [year] [list]

Message-ID: <8736drgfxe.fsf@toke.dk>
Date:   Wed, 11 Dec 2019 14:17:17 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Björn Töpel <bjorn.topel@...il.com>
Cc:     Netdev <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        bpf <bpf@...r.kernel.org>,
        Magnus Karlsson <magnus.karlsson@...il.com>,
        "Karlsson\, Magnus" <magnus.karlsson@...el.com>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        Edward Cree <ecree@...arflare.com>,
        Toke Høiland-Jørgensen 
        <thoiland@...hat.com>, Andrii Nakryiko <andrii.nakryiko@...il.com>
Subject: Re: [PATCH bpf-next v3 0/6] Introduce the BPF dispatcher

Björn Töpel <bjorn.topel@...il.com> writes:

> On Mon, 9 Dec 2019 at 18:42, Björn Töpel <bjorn.topel@...il.com> wrote:
>>
> [...]
>> > You mentioned in the earlier version that this would impact the time it
>> > takes to attach an XDP program. Got any numbers for this?
>> >
>>
>> Ah, no, I forgot to measure that. I'll get back with that. So, when a
>> new program is entered or removed from dispatcher, it needs to be
>> re-jited, but more importantly -- a text poke is needed. I don't know
>> if this is a concern or not, but let's measure it.
>>
>
> Toke, I tried to measure the impact, but didn't really get anything
> useful out. :-(
>
> My concern was mainly that text-poking is a point of contention, and
> it messes with the icache. As for contention, we're already
> synchronized around the rtnl-lock. As for the icache-flush effects...
> well... I'm open to suggestions how to measure the impact in a useful
> way.

Hmm, how about:

Test 1:

- Run a test with a simple drop program (like you have been) on a
  physical interface (A), sampling the PPS with interval I.
- Load a new XDP program on interface B (which could just be a veth I
  guess?)
- Record the PPS delta in the sampling interval on which the program was
  loaded on interval B.

You could also record for how many intervals the throughput drops, but I
would guess you'd need a fairly short sampling interval to see anything
for this.

Test 2:

- Run an XDP_TX program that just reflects the packets.
- Have the traffic generator measure per-packet latency (from it's
  transmitted until the same packet comes back).
- As above, load a program on a different interface and look for a blip
  in the recorded latency.


Both of these tests could also be done with the program being replaced
being the one that processes packets on the physical interface (instead
of on another interface). That way you could also see if there's any
difference for that before/after patch...

-Toke