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