Re: Performance demonstration?
Tom Herbert <[email protected]> Sat, 27 Sep 2025 16:09:46 -0700
| Newsgroups | dev.linux.lists.xdp2 |
|---|---|
| Message-ID | <CALx6S36gHQ1VD-PMReyGQ1Ogiet_Z492ckjvOANS85om91Xckg@mail.gmail.com> |
On Sat, Sep 27, 2025 at 3:38=E2=80=AFPM dave seddon <[email protected]= om> wrote: > > Great! Definitely will definitely be interesting to hear what you discov= er. Uhg! Apparently perf is working for LInux 6.14! > > I guess in a folder like ./documentation/performance_tests/ the above > output could be captured with the date. Or maybe the performance > results could go into a different repo? > > In addition to measuring xdp2's raw processing performance, what might > be an impressive xdp2 demonstration would be: > 1. Identify some highly used hand built parsing code and measure the > performance. - I'm not sure what the best example would be, but maybe > you have some ideas where performance really matters? > 2. Then compare the performance of xdp2 generated code > > Maybe so potentials are: > - netfilter parsers > - OpenSSL ( ssl/record/ record layer parsing/processing, ssl/statem/ > state machine, handshake message parsing, or ssl/t1_lib.c TLS 1.x > message parsing, extensions ) > - PowerDNS ( dnsparser/ contains classes like DNSPacket, DNSName, > DNSRecordContent that implement parsing and serializing of DNS packets > and records ) > - OnnxRuntime flatbuffer parser. If you want to ride the AI buzz, > maybe pick a library like the OnnxRuntime which uses flatbuffers, and > if you can prove xdp2 is faster that would get a fair bit of attention > I guess the trick would be to choose protocols already implemented or > that are easy to implement > > > On Sat, Sep 27, 2025 at 3:06=E2=80=AFPM Tom Herbert <[email protected]>= wrote: > > > > Hi Dave, > > > > With the latest XDP2 code, we can run in test/parser to get > > performance. For Instance: > > > > ./test_parser -v -n 10000000 -i pcap,test-in.pcap -c xdp2 -o null > > Packet 1 (repeated 10000000): avg 82 ns/p 12 Mpps > > Packet 2 (repeated 10000000): avg 61 ns/p 16 Mpps > > Packet 3 (repeated 10000000): avg 56 ns/p 17 Mpps > > Packet 4 (repeated 10000000): avg 54 ns/p 18 Mpps > > Packet 5 (repeated 10000000): avg 54 ns/p 18 Mpps > > Packet 6 (repeated 10000000): avg 54 ns/p 18 Mpps > > Packet 7 (repeated 10000000): avg 54 ns/p 18 Mpps > > Packet 8 (repeated 10000000): avg 53 ns/p 18 Mpps > > Packet 9 (repeated 10000000): avg 53 ns/p 18 Mpps > > Packet 10 (repeated 10000000): avg 53 ns/p 18 Mpps > > Packet 11 (repeated 10000000): avg 55 ns/p 18 Mpps > > Total avg 57 ns/packet 17 Mpps > > > > /test_parser -v -n 10000000 -i pcap,test-in.pcap -c xdp2opt -o null > > Packet 1 (repeated 10000000): avg 48 ns/p 20 Mpps > > Packet 2 (repeated 10000000): avg 41 ns/p 24 Mpps > > Packet 3 (repeated 10000000): avg 40 ns/p 25 Mpps > > Packet 4 (repeated 10000000): avg 40 ns/p 25 Mpps > > Packet 5 (repeated 10000000): avg 40 ns/p 25 Mpps > > Packet 6 (repeated 10000000): avg 41 ns/p 24 Mpps > > Packet 7 (repeated 10000000): avg 42 ns/p 23 Mpps > > Packet 8 (repeated 10000000): avg 40 ns/p 25 Mpps > > Packet 9 (repeated 10000000): avg 41 ns/p 24 Mpps > > Packet 10 (repeated 10000000): avg 42 ns/p 23 Mpps > > Packet 11 (repeated 10000000): avg 42 ns/p 23 Mpps > > Total avg 42 ns/packet 23 Mpps > > > > > > > > The numbers are about 1/2 of what I see with the old PANDA code which > > is surprising. We need to profile to see what's happening... > > > > Tom > > > > > > On Tue, Sep 23, 2025 at 1:13=E2=80=AFPM Tom Herbert <[email protected]= m> wrote: > > > > > > On Tue, Sep 23, 2025 at 8:57=E2=80=AFAM dave seddon <dave.seddon.ca@g= mail.com> wrote: > > > > > > > > Hi Tom, > > > > > > > > I watched your FLOSS video > > > > ([https://hackaday.com/2025/09/17/floss-weekly-episode-847-this-is-= networking/](https://hackaday.com/2025/09/17/floss-weekly-episode-847-this-= is-networking/)) > > > > on xdp2, and I'm very interested in your claim that the code-genera= ted > > > > parser outperforms a hand-coded one. > > > > > > > > > > Hi Dave, > > > > > > It can be done via parser test. We compare flow dissector versus > > > optimized XDP2 parser. Haven't done it since the last rebase, so we'l= l > > > need to reproduce the numbers. On it. > > > > > > Tom > > > > > > > > > Tom > > > > > > > Could you provide an example to demonstrate this? This would be a > > > > great addition to the xdp2 README.md > > > > ([https://github.com/xdp2-dev/xdp2/blob/main/README.md](https://git= hub.com/xdp2-dev/xdp2/blob/main/README.md)). > > > > > > > > Demonstrating that xdp2 generates a faster parser than a widely use= d > > > > parser, like your protobuf example, would significantly boost its > > > > visibility. > > > > > > > > -- > > > > Regards, > > > > Dave Seddon > > > > +1 415 857 5102 > > > > > > > > -- > Regards, > Dave Seddon > +1 415 857 5102