To content | To menu | To search


Entries feed

Monday 18 February 2019

Faster vlan(4) forwarding?

Two years ago we observed that vlan(4) performances suffered from the locks added to the queueing API. At that time, the use of SRP was also pointed out as a possible responsible for the regression. Since dlg@ recently reworked if_enqueue() to allow pseudo-drivers to bypass the use of queues, and their associated locks, let's dive into vlan(4) performances again.

Continue reading...

Monday 21 August 2017

Faster forwarding

Since a couple of months processing incoming IP packets on OpenBSD no longer requires the KERNEL_LOCK(). The first consequence is an improved latency of the system but apparently it also made packet forwarding 20% faster.

At least that's what Hrvoje Popovski measured by the time of the commit, and more recently on his Xeon box (E5-2643 v2 @ 3.50GHz, 3500.44 MHz). When he performed some tests for the vlan(4) regression, he measured on his machine a throughput of 1.42Mpps. Last week, with a -current kernel he measured a throughput of 1.75Mpps.

Yes, it is a bit more than 20%. Yes, the stack is still mostly single-threaded.

Monday 13 February 2017

What happened to my vlan?

A long term goal of the effort I'm driving to unlock OpenBSD's Network Stack is obviously to increase performances. So I'd understand that you find confusing when some of our changes introduce performance regressions.

It is just really hard to do incremental changes without introducing temporary regressions. But as much as security is a process, improving performance is also a process. Recently markus@ told me that vlan(4) performances dropped in last releases. He had some ideas why but he couldn't provide evidences. So what really happened?

Continue reading...

Friday 13 January 2017

A story of if_get(9)

During the l2k15 hackathon, we enjoyed putting a lot of if_get(9) all over the network stack. Then more recently we started removing them. I even briefly explained why we should try to avoid using this API. All of this can be confusing, so let me tell you a story. A story of garbage collection inside the kernel.

Continue reading...

Friday 17 June 2016

ART single thread performances

ART has been the default routing table backend in OpenBSD for some months now. That means that OpenBSD 6.0 will no longer consult the 4.3 BSD reduced radix tree to perform route lookups.

The principal motivation for adopting a new tree implementation can be explained in three letters: SMP.

I'll describe in a different context why and how ART is a good fit in our revamp of OpenBSD network stack. For the moment, let's have a look at the single-thread performances of this algorithm in OpenBSD -current.

Continue reading...