Re: Performance demonstration?

Great!  Definitely will definitely be interesting to hear what you discover=
.

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]> w=
rote:
>
> 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]>=
 wrote:
> >
> > On Tue, Sep 23, 2025 at 8:57=E2=80=AFAM dave seddon <dave.seddon.ca@gma=
il.com> wrote:
> > >
> > > Hi Tom,
> > >
> > > I watched your FLOSS video
> > > ([https://hackaday.com/2025/09/17/floss-weekly-episode-847-this-is-ne=
tworking/](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-generate=
d
> > > 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'll
> > 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://githu=
b.com/xdp2-dev/xdp2/blob/main/README.md)).
> > >
> > > Demonstrating that xdp2 generates a faster parser than a widely used
> > > parser, like your protobuf example, would significantly boost its
> > > visibility.
> > >
> > > --
> > > Regards,
> > > Dave Seddon
> > > +1 415 857 5102
> > >



--
Regards,
Dave Seddon
+1 415 857 5102