To content | To menu | To search

Thursday 9 May 2019

Reducing that contention

The opening keynote at EuroBSDCon 2016 predicted the future 10 years of BSDs. Amongst all the funny previsions, gnn@FreeBSD said that by 2026 OpenBSD will have its first implementation of SMP. Almost 3 years after this talk, that sounds like a plausible forecast... Why? Where are we? What can we do? Let's dive into the issue!

Continue reading...

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...

Thursday 29 March 2018

Dumping your USB

One of the many new features of OpenBSD 6.3 is the possibility to dump USB traffic to userland via bpf(4). This can be done with tcpdump(8) by specifying a USB bus as interface:

# tcpdump -Xx -i usb0
tcpdump: listening on usb0, link-type USBPCAP
12:28:03.317945 bus 0 < addr 1: ep1 intr 2
  0000: 0400                                     ..

12:28:03.318018 bus 0 > addr 1: ep0 ctrl 8
  0000: 00a3 0000 0002 0004 00                   .........                     

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...