netip.Addr expose une méthode Unmap() qui renvoie l'adresse IPv4 contenue dans une adresse IPv6 représentant une IPv4 (IPv4-mapped IPv6 address). À partir de ::ffff:203.0.113.10 ou de ::ffff:cb00:710a, elle renvoie 203.0.113.10¹. Il n'existe pas de méthode Map() ou To6() pour l'opération inverse. Une telle méthode est triviale à écrire, mais les mainteneurs de Go l'ont refusée au motif que les utilisateurs devraient écrire netip.AddrFrom16(ip.As16()) et laisser le compilateur l'optimiser². Aujourd'hui, cette construction est huit fois plus lente qu'une méthode native. Comment apprendre au compilateur à l'optimiser ?

Les solutions possibles

Examinons trois façons d'implémenter cette conversion pour netip.Addr. Ma préférée consiste à l'ajouter à la bibliothèque standard de Go. Les mainteneurs de Go préfèrent une petite fonction utilitaire externe enchaînant netip.AddrFrom16() et netip.Addr.As16(), en espérant que le compilateur réussisse à l'optimiser. Le paquet unsafe ouvre une troisième voie, avec des performances identiques à la première solution.

Modifier la bibliothèque standard de Go

En interne, netip.Addr stocke les adresses IP sous forme d'une valeur de 128 bits accompagnée d'un champ supplémentaire z qui encode la famille et la zone :

type Addr struct {
    addr uint128
    z unique.Handle[addrDetail]
}

type addrDetail struct {
    isV6   bool   // false pour IPv4, true pour IPv6.
    zoneV6 string // != "" seulement si IsV6 est vrai.
}

var (
    z0    unique.Handle[addrDetail]
    z4    = unique.Make(addrDetail{})
    z6noz = unique.Make(addrDetail{isV6: true})
)

AddrFrom4() encode une adresse IPv4 sous la forme d'une adresse IPv6 représentant une IPv4 et assigne le singleton z4 au champ z :

// AddrFrom4 returns the address of the IPv4 address given by the bytes in addr.
func AddrFrom4(addr [4]byte) Addr {
    return Addr{
        addr: uint128{
            0,
            0xffff00000000 |
                uint64(addr[0])<<24 | uint64(addr[1])<<16 |
                uint64(addr[2])<<8 | uint64(addr[3])},
        z: z4,
    }
}

Unmap() transforme une adresse IPv6 représentant une IPv4 en adresse IPv4 en assignant le singleton z4 au champ :

func (ip Addr) Unmap() Addr {
    if ip.Is4In6() {
        ip.z = z4
    }
    return ip
}

Ajouter l'opération inverse dans la bibliothèque standard de Go est trivial : il suffit d'assigner au champ z le singleton z6noz quand l'adresse est une IPv4.

// To6 maps an IPv4 address to an IPv4-mapped IPv6 address. It returns an
// IPv6 address unmodified.
func (ip Addr) To6() Addr {
    if ip.Is4() {
        ip.z = z6noz
    }
    return ip
}

Avec une fonction utilitaire

Le champ z n'est pas accessible en dehors du paquet net/netip. À la place, nous écrivons une fonction utilitaire autour de la construction netip.AddrFrom16(ip.As16()) :

// AddrTo6 maps an IPv4 address to an IPv4-mapped IPv6 address. It returns an
// IPv6 address unmodified.
func AddrTo6(ip netip.Addr) netip.Addr {
    if ip.Is4() {
        ip = netip.AddrFrom16(ip.As16())
    }
    return ip
}

Avec le paquet unsafe

Une autre solution utilise le paquet unsafe pour modifier la structure Addr par l'intermédiaire d'une structure avec le même schéma mémoire⁴ :

// addrProxy a le même schéma mémoire que netip.Addr.
type addrProxy struct {
    addr [2]uint64      // netip.uint128
    z    unsafe.Pointer // unique.Handle[netip.addrDetail]
}

var (
    anyIPv6    = netip.IPv6Unspecified()
    netipZ6noz = (*addrProxy)(unsafe.Pointer(&anyIPv6)).z
)

// AddrTo6 maps an IPv4 address to an IPv4-mapped IPv6 address. It returns an
// IPv6 address unmodified.
func AddrTo6(ip netip.Addr) netip.Addr {
    if !ip.Is4() {
        return ip
    }
    (*addrProxy)(unsafe.Pointer(&ip)).z = netipZ6noz
    return ip
}

Performances

Sur mon ordinateur, avec Go 1.27.1, la solution intégrée à la bibliothèque standard coûte 0,88 ns par opération, alors que celle privilégiée par les mainteneurs de Go coûte 7,14 ns. La solution utilisant unsafe égale les performances de la première.

goos: linux
goarch: amd64
pkg: github.com/vincentbernat/go-netip-addrto6
cpu: AMD Ryzen 5 5600X 6-Core Processor
                   │     sec/op     │
AddrTo6/safe            7.137n ± 0%
AddrTo6/unsafe         0.8682n ± 2%
AddrTo6/builtin        0.8775n ± 2%

Code assembleur

Regardons le code assembleur que le compilateur génère pour chaque solution⁵. La solution intégrée à la bibliothèque standard ressemble à ceci⁶ :

// AX = input.addr.hi, BX = input.addr.lo, CX = input.z
 CMPQ  net/netip·z4(SB), CX     ; vérifier avec "z" s'il s'agit d'une adresse IPv4
 JNE   end                      ; sinon, s'arrêter ici
 MOVQ  net/netip·z6noz(SB), CX  ; CX = netip.z6noz
end:
 RET
// valeur de retour = Addr{hi: AX, lo: BX, z: CX}

Le langage assembleur de Go n'est pas une représentation directe du langage machine sous-jacent : il repose sur un jeu d'instructions semi-abstrait dérivé de l'assembleur de Plan 9. Il dispose de quatre pseudo-registres : FP (frame pointer ou pointeur de cadre pour les arguments des fonctions), PC (program counter ou compteur ordinal), SB (static base ou pointeur de base pour les symboles globaux) et SP (stack pointer ou pointeur de la pile). Il possède aussi des registres propres à l'architecture, comme AX, CX, DX, BX, SI, DI et R8 à R15. Les instructions qui stockent une donnée utilisent leur dernier argument comme destination. Les instructions peuvent porter un suffixe de taille explicite : MOVB déplace un octet, MOVW 16 bits, MOVL 32 bits et MOVQ 64 bits. Dans l'exemple ci-dessus, la première instruction compare la valeur de 64 bits z4 avec le registre CX.

La solution utilisant unsafe est presque identique :

// AX = input.addr.hi, BX = input.addr.lo, CX = input.z
 CMPQ  net/netip·z4(SB), CX  ; vérifier avec "z" s'il s'agit d'une adresse IPv4
 JNE   end                   ; sinon, s'arrêter ici
 MOVQ  netipZ6noz(SB), CX    ; CX = netip.z6noz
end:
 RET
// valeur de retour = Addr{hi: AX, lo: BX, z: CX}

La solution utilitaire comporte beaucoup plus d'instructions. Pour comprendre pourquoi, examinons le code de As16() et de AddrFrom16(). Elles sont assez courtes pour que le compilateur remplace leur appel par leur code.

func (ip Addr) As16() (a16 [16]byte) {
    byteorder.BEPutUint64(a16[:8], ip.addr.hi)
    byteorder.BEPutUint64(a16[8:], ip.addr.lo)
    return a16
}

func AddrFrom16(addr [16]byte) Addr {
    return Addr{
        addr: uint128{
            byteorder.BEUint64(addr[:8]),
            byteorder.BEUint64(addr[8:]),
        },
        z: z6noz,
    }
}

On devine déjà la construction qui sera à optimiser : le code stocke l'adresse IP dans un tableau, le copie, puis l'en extrait. Si nous développons le code Go à la main, nous obtenons :

func AddrTo6(input netip.Addr) netip.Addr {
    if !input.Is4() {
        return input
    }

    var a16 [16]byte
    byteorder.BEPutUint64(a16[:8], input.addr.hi)
    byteorder.BEPutUint64(a16[8:], input.addr.lo)

    addr := a16

    var output netip.Addr
    output.addr.hi = byteorder.BEUint64(addr[:8])
    output.addr.lo = byteorder.BEUint64(addr[8:])
    output.z = netip.z6noz
    return output
}

En tant qu'humains, nous pouvons mentalement obtenir la forme optimisée :

func AddrTo6(input netip.Addr) netip.Addr {
    if !input.Is4() {
        return input
    }
    var output netip.Addr
    output.addr.hi = input.addr.hi
    output.addr.lo = input.addr.lo
    output.z = netip.z6noz
    return output
}

Malheureusement, avec Go 1.26.8, le compilateur n'est pas assez malin pour en faire autant :

// AX = input.addr.hi, BX = input.addr.lo, CX = input.z
; Réserver de la place sur la pile (32 octets) :
;    0(SP) addr netip.uint128
;   16(SP) a16 [16]byte
 PUSHQ   BP
 MOVQ    SP, BP
 SUBQ    $32, SP

 CMPQ    net/netip·z4(SB), CX  ; vérifier avec "z" s'il s'agit d'une adresse IPv4
 JNE     end                   ; sinon, s'arrêter ici

; Empaquetage : byteorder.BEPutUint64(a16[:8], input.addr.hi)
;               byteorder.BEPutUint64(a16[8:], input.addr.lo)
 MOVBEQ  AX, net/netip·a16+16(SP)
 MOVBEQ  BX, net/netip·a16+24(SP)

; addr = a16, 16 octets d'un coup via le registre vectoriel X0
 MOVUPS  net/netip·a16+16(SP), X0
 MOVUPS  X0, net/netip·addr(SP)

; CX = netip.z6noz
 MOVQ    net/netip·z6noz(SB), CX
; Dépaquetage : output.addr.hi = byteorder.BEUint64(addr[:8])
;               output.addr.lo = byteorder.BEUint64(addr[8:])
 MOVBEQ  net/netip·addr(SP), AX
 MOVBEQ  net/netip·addr+8(SP), BX

end:
 ADDQ    $32, SP
 POPQ    BP
 RET
// valeur de retour = Addr{hi: AX, lo: BX, z: CX}

Le compilateur s'en sort honorablement avec la manipulation des octets : les huit écritures d'un octet provenant de BEPutUint64() sont remplacées par un unique MOVBEQ, qui copie un registre en inversant l'ordre de ses octets, et les huit lectures d'un octet de BEUint64() deviennent aussi un unique MOVBEQ dans l'autre sens⁷. Il reste trois groupes d'instructions : un empaquetage, une copie et un dépaquetage.

Bidouiller le compilateur

Le compilateur Go comporte plusieurs phases :

Analyse syntaxique

Le compilateur découpe le code source en lexèmes et l'analyse. Il construit un arbre syntaxique pour chaque fichier source.

Vérification des types

Le compilateur associe chaque identifiant à l'objet qu'il désigne, calcule les expressions constantes et infère le type de chaque expression.

Construction de l'IR

Le compilateur convertit l'arbre syntaxique et ses types dans une représentation intermédiaire (IR). Ce processus, appelé « noding », passe par un format de sérialisation nommé unified IR.

Middle end

Le compilateur effectue plusieurs passes d'optimisation sur l'IR, comme la dévirtualisation, le remplacement des appels de fonction par leurs contenus et l'analyse d'échappement.

Walk

Cette phase comporte deux étapes : une décomposition des instructions complexes en instructions plus simples et la transformation des constructions Go de haut niveau, comme switch ou les canaux, en instructions plus primitives ou en appels à des fonctions.

SSA générique

Le compilateur convertit l'IR en forme SSA (Static Single Assignment), une représentation intermédiaire de plus bas niveau adaptée aux optimisations et règles de réécriture indépendantes de l'architecture.

Génération du code machine

Le compilateur réécrit la forme SSA en variantes propres à l'architecture, alloue les registres et applique d'autres passes d'optimisation. Pour finir, l'assembleur transforme les instructions générées en code machine.

Le marteau

Ma première idée est de remplacer les occurrences de netip.AddrFrom16(ip.As16()) par netip.Addr{addr: ip.addr, z: netip.z6noz} le plus tôt possible, c'est-à-dire pendant le noding. Avant cela, la phase de vérification des types nous interdit d'accéder aux champs non exportés d'une structure.

Go 1.27 a introduit une option de débogage pratique pour afficher l'IR d'une fonction à plusieurs moments clés de la compilation :

$ GOTOOLCHAIN=go1.27.1 GOAMD64=v3 go build -a -gcflags="-d=astdump=AddrTo6Safe" .
Writing text ast output for AddrTo6Safe to AddrTo6Safe.ast
Writing html ast output for AddrTo6Safe to AddrTo6Safe.html
Writing html syntax output for AddrTo6Safe to AddrTo6Safe.syntax.html

Dans le fichier HTML, la première colonne montre l'IR telle qu'elle sort du noding :

DCLFUNC addrto6.AddrTo6Safe ABI:ABIInternal FUNC-func(netip.Addr) netip.Addr
DCLFUNC-Dcl
. NAME-addrto6.ip Class:PPARAM Offset:0 OnStack Used netip.Addr
. NAME-addrto6.~r0 Class:PPARAMOUT Offset:0 OnStack netip.Addr
DCLFUNC-body
. IF # ipv6_safe.go:11:2
. IF-Cond
. . CALLFUNC bool
. . CALLFUNC-Fun
. . . METHEXPR addrto6.Is4 FUNC-func(netip.Addr) bool
. . . . TYPE netip.Addr Class:PEXTERN Offset:0 type netip.Addr
. . CALLFUNC-Args
. . . NAME-addrto6.ip Class:PPARAM Offset:0 OnStack Used netip.Addr
. IF-Body
. . AS # ipv6_safe.go:12:6
. . . NAME-addrto6.ip Class:PPARAM Offset:0 OnStack Used netip.Addr
. . . CALLFUNC netip.Addr
. . . CALLFUNC-Fun
. . . . NAME-netip.AddrFrom16 Class:PFUNC Offset:0 Used FUNC-func([16]byte) netip.Addr
. . . CALLFUNC-Args
. . . . CALLFUNC ARRAY-[16]byte
. . . . CALLFUNC-Fun
. . . . . METHEXPR addrto6.As16 FUNC-func(netip.Addr) [16]byte
. . . . . . TYPE netip.Addr Class:PEXTERN Offset:0 type netip.Addr
. . . . CALLFUNC-Args
. . . . . NAME-addrto6.ip Class:PPARAM Offset:0 OnStack Used netip.Addr
. RETURN # ipv6_safe.go:14:2
. RETURN-Results
. . NAME-addrto6.ip Class:PPARAM Offset:0 OnStack Used netip.Addr

Dans le corps de l'instruction if, nous repérons l'appel à la méthode netip.Addr.As16() et celui à la fonction netip.AddrFrom16(). Notre objectif est de les remplacer par la construction littérale d'une structure :

IF-Body
. AS # ipv6_safe.go:12:6
. . NAME-addrto6.ip Class:PPARAM Offset:0 OnStack Used netip.Addr
. . STRUCTLIT netip.Addr
. . STRUCTLIT-List
. . . STRUCTKEY netip.addr
. . . . DOT netip.addr netip.uint128
. . . . . NAME-addrto6.ip Class:PPARAM Offset:0 OnStack Used netip.Addr
. . . STRUCTKEY netip.z
. . . . NAME-netip.z6noz Class:PEXTERN Offset:0 unique.Handle[net/netip.addrDetail]

Dans le fichier reader.go du noder, la méthode expr() construit l'arbre IR d'une expression. À la fin de la branche exprCall, nous ajoutons l'appel à une fonction rewriteAddrFrom16As16(). Elle prend en paramètre le nœud courant et renvoie la structure construite en cas de succès ou nil si la réécriture n'est pas possible. D'abord, nous vérifions que nous avons le motif attendu : un appel à la fonction netip.AddrFrom16() avec, pour unique argument, un appel à la méthode netip.Addr.As16() :

func rewriteAddrFrom16As16(n ir.Node) ir.Node {
    call, ok := n.(*ir.CallExpr)
    if !ok || call.Op() != ir.OCALLFUNC ||
        len(call.Args) != 1 || len(call.Init()) != 0 ||
        !isNetipFunc(call.Fun, "AddrFrom16") {
        return nil
    }
    inner, ok := call.Args[0].(*ir.CallExpr)
    if !ok || inner.Op() != ir.OCALLFUNC ||
        len(inner.Args) != 1 || len(inner.Init()) != 0 ||
        !isNetipFunc(inner.Fun, "Addr.As16") {
        return nil
    }
    x := inner.Args[0]
    // [...]
}

Ensuite, nous récupérons netip.z6noz :

z6noz, err := lookupVar(ir.StaticCalleeName(call.Fun).Sym().Pkg, "z6noz")
if err != nil {
    return nil
}

Et nous construisons littéralement la structure :

typ := call.Type()
pos := call.Pos()
var list []ir.Node
for i, f := range typ.Fields() {
    var value ir.Node
    switch f.Sym.Name {
    case "addr":
        value = typecheck.DotField(pos, x, i)
    case "z":
        value = z6noz
    default:
        return nil
    }
    list = append(list, ir.NewStructKeyExpr(pos, f, value))
}
lit := ir.NewCompLitExpr(pos, ir.OSTRUCTLIT, typ, list)
lit.SetTypecheck(1)
return lit

Jetez un œil à la modification complète⁸. Nous pouvons la tester avec les commandes suivantes :

$ cd src
$ ./make.bash
Building Go cmd/dist using /usr/lib/go-1.27. (go1.27.1 linux/amd64)
Building Go toolchain1 and bootstrap cmd/go (go_bootstrap) using /usr/lib/go-1.27.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 and commands using go_bootstrap and Go toolchain2.
Checking command staleness for linux/amd64.
---
Installed Go for linux/amd64 in /home/bernat/code/free/go
Installed commands in /home/bernat/code/free/go/bin
*** You need to add /home/bernat/code/free/go/bin to your PATH.
$ export PATH=$PWD/../bin:$PATH
$ go version
go version go1.28-devel_9834516e20 Sat Sep 12 08:23:11 2026 -0700 linux/amd64
$ go test net/netip/...
ok      net/netip   0.224s
$ cd ../../go-netip-addrto6
$ go test .
ok      github.com/vincentbernat/go-netip-addrto6   0.062s

Le code généré pour la fonction utilitaire est désormais le plus court possible !

// AX = input.addr.hi, BX = input.addr.lo, CX = input.z
 CMPQ    net/netip·z4(SB), CX     ; vérifier avec "z" s'il s'agit d'une adresse IPv4
 JNE     end                      ; sinon, s'arrêter ici
 MOVQ    net/netip·z6noz(SB), CX  ; CX = netip.z6noz
end:
 RET
// valeur de retour = Addr{hi: AX, lo: BX, z: CX}

Il est peu probable que les mainteneurs de Go acceptent cette amélioration. Elle dépend de la structure interne de net/netip.Addr. C'est une bidouille peu élégante dans le noder, dont le rôle est de traduire fidèlement l'AST vérifié en IR. Et elle est plus difficile à maintenir que l'ajout de la méthode To6().

Le tournevis

Le bon endroit pour une telle optimisation est la phase SSA générique. L'une des dernières passes indépendantes de l'architecture est memcombine. Avec l'option de débogage adéquate, le compilateur affiche la forme SSA après cette passe⁹ :

$ GOTOOLCHAIN=go1.26.8 GOAMD64=v3 \
> go build -a -gcflags='-d=ssa/memcombine/dump=AddrTo6Safe' .
$ head -5 AddrTo6Safe_01__memcombine.dump
AddrTo6Safe func(netip.Addr) netip.Addr
  b2:
    (?) v1 = InitMem <mem>
    (?) v2 = SP <uintptr>
    (?) v3 = SB <uintptr>

Le résultat de la passe memcombine suit la même structure que le code assembleur de AddrTo6Safe() examiné plus haut : deux écritures, une copie et deux lectures que nous aimerions éliminer.

; […]
  v502 = ArgIntReg <uint64> {ip+0} [0]              ; input.addr.hi
  v490 = ArgIntReg <uint64> {ip+8} [1]              ; input.addr.lo
  v466 = ArgIntReg <*netip.addrDetail> {ip+16} [2]  ; input.z
; […]
  v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
  v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v442 = Bswap64 <uint64> v490                      ; bswap(input.addr.lo)
  v542 = Bswap64 <uint64> v502                      ; bswap(input.addr.hi)
  v161 = Store <mem> {uint64} v22 v542 v23          ; a16[:8] = bswap(hi)
  v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)

  v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
  v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16

  v415 = OffPtr <*byte> [8] v285                    ; &addr[8]
  v416 = Load <uint64> v285 v286                    ; addr[:8]
  v299 = Bswap64 <uint64> v416                      ; output.addr.hi
  v174 = Load <uint64> v415 v286                    ; addr[8:]
  v39  = Bswap64 <uint64> v174                      ; output.addr.lo
; […]

Chaque ligne comporte un identifiant de valeur (v442), une opération avec son type (Bswap64 <uint64>) et ses arguments (v490)¹⁰. Les valeurs sont les briques de base de la forme SSA et ne sont définies qu'une seule fois. Les paramètres entiers sont entourés par des crochets ([8]) et les arguments auxiliaires sont indiqués par des accolades ({netip.addr}). Les opérations qui écrivent en mémoire produisent un nouvel état de la mémoire. Chaque opération mémoire reprend l'état courant en dernier argument, ce qui permet de les maintenir dans l'ordre.

Sur le papier

Concentrons-nous sur output.addr.lo, alias v39 :

  v490 = ArgIntReg <uint64> {ip+8} [1]              ; input.addr.lo
  v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
  v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v442 = Bswap64 <uint64> v490                      ; bswap(input.addr.lo)
  v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
  v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
  v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
  v415 = OffPtr <*byte> [8] v285                    ; &addr[8]
  v174 = Load <uint64> v415 v286                    ; addr[8:]
  v39  = Bswap64 <uint64> v174                      ; output.addr.lo

Pour simplifier ce code, nous pourrions appliquer trois règles de réécriture :

1. La première ajoute un raccourci pour une lecture à travers une copie : (Load (OffPtr [o] p) (Move p src mem)) => (Load (OffPtr [o] src) mem). Elle s'applique à v174 avec ses arguments v415 et v286 et crée une nouvelle valeur v600 :

     v490 = ArgIntReg <uint64> {ip+8} [1]              ; input.addr.lo
     v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
     v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
     v442 = Bswap64 <uint64> v490                      ; bswap(input.addr.lo)
     v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
     v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
     v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
     v415 = OffPtr <*byte> [8] v285                    ; &addr[8]
     v600 = OffPtr <*byte> [8] v22                     ; &a16[8]
     v174 = Load <uint64> v600 v282                    ; a16[8:]
     v39  = Bswap64 <uint64> v174                      ; output.addr.lo
   

2. La deuxième simplifie une lecture qui suit une écriture : (Load p (Store p x _)) => x. La lecture est transmise : la valeur écrite la remplace et il ne reste plus aucun accès mémoire. Elle s'applique à v174. Elle remarque que v600 et v173 désignent la même adresse et remplace v174 par une copie de v442 :

     v490 = ArgIntReg <uint64> {ip+8} [1]              ; input.addr.lo
     v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
     v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
     v442 = Bswap64 <uint64> v490                      ; bswap(input.addr.lo)
     v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
     v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
     v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
     v415 = OffPtr <*byte> [8] v285                    ; &addr[8]
     v600 = OffPtr <*byte> [8] v22                     ; &a16[8]
     v174 = Copy <uint64> v442                         ; bswap(input.addr.lo)
     v39  = Bswap64 <uint64> v174                      ; output.addr.lo
   

3. La dernière étape annule les deux inversions d'octets : (Bswap64 (Bswap64 x)) => x. v39 devient une copie de v490 :

     v490 = ArgIntReg <uint64> {ip+8} [1]              ; input.addr.lo
     v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
     v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
     v442 = Bswap64 <uint64> v490                      ; bswap(input.addr.lo)
     v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
     v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
     v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
     v415 = OffPtr <*byte> [8] v285                    ; &addr[8]
     v600 = OffPtr <*byte> [8] v22                     ; &a16[8]
     v174 = Copy <uint64> v442                         ; bswap(input.addr.lo)
     v39  = Copy <uint64> v490                         ; output.addr.lo = input.addr.lo
   

Si nous ignorons les valeurs inutiles pour calculer v39, il ne reste que cette forme SSA :

  v490 = ArgIntReg <uint64> {ip+8} [1]  ; input.addr.lo
  v39  = Copy <uint64> v490             ; output.addr.lo = input.addr.lo

Passons à output.addr.hi, alias v299 :

  v502 = ArgIntReg <uint64> {ip+0} [0]              ; input.addr.hi
  v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
  v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
  v542 = Bswap64 <uint64> v502                      ; bswap(input.addr.hi)
  v161 = Store <mem> {uint64} v22 v542 v23          ; a16[:8] = bswap(hi)
  v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
  v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
  v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
  v416 = Load <uint64> v285 v286                    ; addr[:8]
  v299 = Bswap64 <uint64> v416                      ; output.addr.hi

Pour l'éliminer, nous appliquons là aussi trois règles de réécriture :

1. La première raccourcit une lecture à travers une copie, mais sans appliquer un décalage : (Load p (Move p src mem)) => (Load src mem). Elle réécrit v416 pour utiliser les arguments de v286 :

     v502 = ArgIntReg <uint64> {ip+0} [0]              ; input.addr.hi
     v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
     v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
     v542 = Bswap64 <uint64> v502                      ; bswap(input.addr.hi)
     v161 = Store <mem> {uint64} v22 v542 v23          ; a16[:8] = bswap(hi)
     v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
     v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
     v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
     v416 = Load <uint64> v22 v282                     ; a16[:8]
     v299 = Bswap64 <uint64> v416                      ; output.addr.hi
   

2. La deuxième règle transmet une valeur écrite une étape plus tôt, en ignorant une écriture à une autre adresse quand il n'y a pas de chevauchement : (Load p (Store q _ (Store p x _))) => x. Elle s'applique à v416 : x est v542, p est v22 (&a16), q est v173 (&a16[8]), et p et q ne se chevauchent pas si on les considère comme des uint64.

     v502 = ArgIntReg <uint64> {ip+0} [0]              ; input.addr.hi
     v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
     v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
     v542 = Bswap64 <uint64> v502                      ; bswap(input.addr.hi)
     v161 = Store <mem> {uint64} v22 v542 v23          ; a16[:8] = bswap(hi)
     v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
     v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
     v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
     v416 = Copy <uint64> v542                         ; bswap(input.addr.hi)
     v299 = Bswap64 <uint64> v416                      ; output.addr.hi
   

3. La troisième règle annule deux inversions d'octets : (Bswap64 (Bswap64 x)) => x. v299 devient une copie de v502 :

     v502 = ArgIntReg <uint64> {ip+0} [0]              ; input.addr.hi
     v22 = LocalAddr <*[16]byte> {netip.a16} v2 v1     ; &a16
     v173 = OffPtr <*byte> [8] v22                     ; &a16[8]
     v542 = Bswap64 <uint64> v502                      ; bswap(input.addr.hi)
     v161 = Store <mem> {uint64} v22 v542 v23          ; a16[:8] = bswap(hi)
     v282 = Store <mem> {uint64} v173 v442 v161        ; a16[8:] = bswap(lo)
     v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
     v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
     v416 = Copy <uint64> v542                         ; bswap(input.addr.hi)
     v299 = Copy <uint64> v502                         ; output.addr.hi = input.addr.hi
   

Si nous retirons les valeurs inutiles pour calculer v299, nous obtenons la forme SSA suivante :

  v502 = ArgIntReg <uint64> {ip+0} [0] ; input.addr.hi
  v299 = Copy <uint64> v502            ; output.addr.hi = input.addr.hi

En pratique

La plupart de ces règles existent déjà dans generic.rules. Elles utilisent des conditions pour valider leur contexte : ssa.IsSamePtr() pour une même adresse, ssa.Disjoint() pour des adresses qui ne se chevauchent pas. La règle qui transmet une valeur écrite à une lecture existe déjà, avec trois variantes qui regardent à travers plusieurs autres écritures. Voici les deux dont nous avons besoin :

(Load <t1> p1 (Store {t2} p2 x _))
    && ssa.IsSamePtr(p1, p2)
    && copyCompatibleType(t1, x.Type)
    && t1.Size() == t2.Size()
    => x
(Load <t1> p1 (Store {t2} p2 _ (Store {t3} p3 x _)))
    && ssa.IsSamePtr(p1, p3)
    && copyCompatibleType(t1, x.Type)
    && t1.Size() == t3.Size()
    && ssa.Disjoint(p3, t3, p2, t2)
    => x

Go 1.27 a ajouté la règle de lecture à travers une copie dans CL 748200 pour corriger le ticket #77720 :

(Load <t1> op1:(OffPtr [o1] p1) move:(Move [n] p2 src mem))
    && o1 >= 0 && o1+t1.Size() <= n && ssa.IsSamePtr(p1, p2)
    && !ssa.IsVolatile(src)
    => @move.Block (Load <t1> (OffPtr <op1.Type> [o1] src) mem)

Il lui manque une variante sans application d'un décalage :

(Load <t1> p1 move:(Move [n] p2 src mem))
    && p1.Op != ssaop.OpOffPtr
    && t1.Size() <= n && ssa.IsSamePtr(p1, p2)
    && !ssa.IsVolatile(src)
    => @move.Block (Load <t1> (OffPtr <p1.Type> [0] src) mem)

Il n'existe pas de règle générique pour annuler deux inversions d'octets, mais la passe de traduction vers AMD64 comporte cette règle :

(BSWAP(Q|L) (BSWAP(Q|L) p)) => p

Après bascule sur la branche de développement de Go et ajout de la règle manquante, le code assembleur généré est pire qu'avec Go 1.26.8, même si notre règle supplémentaire améliore légèrement la situation à la fin :

// AX = input.addr.hi, BX = input.addr.lo, CX = input.z
; Réserver de la place sur la pile (16 octets) :
;    0(SP) a16 [16]byte
 PUSHQ   BP
 MOVQ    SP, BP
 SUBQ    $16, SP

 CMPQ    net/netip·z4(SB), CX       ; vérifier avec "z" s'il s'agit d'une adresse IPv4
 JNE     end                        ; sinon, s'arrêter ici

; Les quatre octets transmis : la moitié basse de input.addr.lo est découpée
; puis reconstituée dans les registres
 MOVQ    BX, DX                     ; DX = input.addr.lo
 SHRQ    $24, BX                    ; BX = input.addr.lo >> 24
 MOVQ    DX, SI                     ; SI = input.addr.lo
 SHRQ    $16, DX                    ; DX = input.addr.lo >> 16
 MOVQ    SI, DI                     ; DI = input.addr.lo, gardé pour l'empaquetage
 SHRQ    $8, SI                     ; SI = input.addr.lo >> 8
 MOVBLZX DIB, R8                    ; R8 = byte(input.addr.lo)
 MOVBLZX SIB, SI                    ; SI = byte(input.addr.lo >> 8)
 SHLQ    $8, SI
 ORQ     R8, SI                     ; SI = deux octets de poids faible de input.addr.lo
 MOVBLZX DL, DX                     ; DX = byte(input.addr.lo >> 16)
 SHLQ    $16, DX
 ORQ     SI, DX
 MOVBLZX BL, BX                     ; BX = byte(input.addr.lo >> 24)
 SHLQ    $24, BX
 ORQ     DX, BX                     ; BX = input.addr.lo & 0xffffffff

; Empaquetage : byteorder.BEPutUint64(a16[:8], input.addr.hi)
;               byteorder.BEPutUint64(a16[8:], input.addr.lo)
 MOVBEQ  AX, net/netip·a16(SP)
 MOVBEQ  DI, net/netip·a16+8(SP)

; Les quatre autres octets de input.addr.lo, lus un par un dans a16
 MOVBLZX net/netip·a16+11(SP), DX   ; a16[11]
 SHLQ    $32, DX
 ORQ     DX, BX
 MOVBLZX net/netip·a16+10(SP), DX   ; a16[10]
 SHLQ    $40, DX
 ORQ     DX, BX
 MOVBLZX net/netip·a16+9(SP), DX    ; a16[9]
 SHLQ    $48, DX
 ORQ     DX, BX
 MOVBLZX net/netip·a16+8(SP), DX    ; a16[8]
 SHLQ    $56, DX

; output.z = netip.z6noz
 MOVQ    net/netip·z6noz(SB), CX
; output.addr.hi = byteorder.BEUint64(a16[:8])
 MOVBEQ  net/netip·a16(SP), AX
; output.addr.lo assemblé à partir des étapes précédentes
 ORQ     DX, BX

end:
 LEAVEQ
 RET
// valeur de retour = Addr{hi: AX, lo: BX, z: CX}

C'est la règle de lecture à travers une copie, ajoutée dans Go 1.27, qui a introduit cette régression.

Dans le désordre

Ne baissons pas les bras ! En réalité, les règles de réécriture s'exécutent avant memcombine, notamment dans la passe late opt. À ce stade, le compilateur a remplacé les appels de BEPutUint64() et de BEUint64() par seize écritures et seize lectures d'un octet, conformément à leur code source :

func BEUint64(b []byte) uint64 {
    _ = b[7] // bounds check hint to compiler; see golang.org/issue/14808
    return uint64(b[7]) | uint64(b[6])<<8 | uint64(b[5])<<16 | uint64(b[4])<<24 |
        uint64(b[3])<<32 | uint64(b[2])<<40 | uint64(b[1])<<48 | uint64(b[0])<<56
}

Suivons deux octets de output.addr.lo : addr[15] et addr[11]. Voici une forme SSA simplifiée avant la passe late opt :

  v273 = Trunc64to8 <byte> v490                     ; byte(input.addr.lo)
  v226 = Trunc64to8 <byte> v225                     ; byte(input.addr.lo >> 32)
; […]
  v235 = Store <mem> {byte} v233 v226 v223          ; a16[11] = byte(lo >> 32)
  v247 = Store <mem> {byte} v245 v238 v235          ; a16[12] = …
  v259 = Store <mem> {byte} v257 v250 v247          ; a16[13] = …
  v271 = Store <mem> {byte} v269 v262 v259          ; a16[14] = …
  v282 = Store <mem> {byte} v280 v273 v271          ; a16[15] = byte(lo)
  v285 = LocalAddr <*[16]byte> {netip.addr} v2 v282 ; &addr
  v286 = Move <mem> {[16]byte} [16] v285 v22 v282   ; addr = a16
; […]
  v433 = OffPtr <*byte> [15] v285                   ; &addr[15]
  v435 = Load <byte> v433 v286                      ; addr[15]
  v479 = OffPtr <*byte> [11] v285                   ; &addr[11]
  v481 = Load <byte> v479 v286                      ; addr[11]

La première règle lit à travers la copie : (Load (OffPtr [o] p) (Move p src mem)) => (Load (OffPtr [o] src) mem). Elle s'applique aux deux lectures, qui lisent désormais a16 avec l'état de la mémoire précédant la copie :

  v600 = OffPtr <*byte> [15] v22 ; &a16[15]
  v435 = Load <byte> v600 v282   ; a16[15]
  v601 = OffPtr <*byte> [11] v22 ; &a16[11]
  v481 = Load <byte> v601 v282   ; a16[11]

La deuxième règle raccourcit une lecture qui suit une écriture : (Load p (Store p x _)) => x. Elle s'applique à v435, puisque v282 écrit a16[15]. Elle ne s'applique pas à v481 : v235 écrit a16[11] quatre écritures plus tôt dans la chaîne, alors que les variantes de cette règle ne remontent au maximum qu'à trois écritures.

  v435 = Copy <byte> v273        ; byte(input.addr.lo)
  v601 = OffPtr <*byte> [11] v22 ; &a16[11]
  v481 = Load <byte> v601 v282   ; a16[11]

Il en va de même pour les autres octets : la règle transmet les quatre derniers octets écrits, de a16[12] à a16[15]. Les douze autres lectures continuent de lire a16 au lieu de addr.

BEUint64() devient une chaîne de Or64, chacun plaçant un octet à sa place. memcombine est une passe écrite en Go, et non un ensemble de règles de réécriture. Elle part du dernier Or64 de la chaîne et collecte jusqu'à huit termes. Si chaque terme est la lecture d'un octet, étendue à 64 bits et décalée, et si les huit lectures portent sur des adresses consécutives à partir du même pointeur avec le même état de la mémoire, elle remplace toute la chaîne par une unique lecture de 64 bits et une inversion d'octets. Sinon, elle réessaie avec quatre termes, puis deux ainsi qu'à partir de chaque Or64 intermédiaire. Voici la boucle qui vérifie chaque terme dans une version simplifiée de combineLoads() :

for i := int64(0); i < n; i++ {
    v := a[i]
    shift := int64(0)
    if v.Op == shiftOp {
        v, shift = peelShift(v)
    }
    if v.Op != extOp {
        return false
    }
    load := v.Args[0]
    if load.Op != ssaop.OpLoad {
        return false
    }
    if load.Args[1] != mem {
        return false
    }
    p, off := splitPtr(load.Args[0])
    if p != base {
        return false
    }
    r[i] = LoadRecord{load: load, offset: off, shift: shift}
}

Pour output.addr.hi, les huit lectures portent sur a16 avec le même état de la mémoire, v282 :

  v13  = Load <byte> v22 v282               ; a16[0]
  v530 = Load <byte> v14 v282               ; a16[1]
  v488 = Load <byte> v504 v282              ; a16[2]
  v405 = Load <byte> v537 v282              ; a16[3]
  v385 = Load <byte> v397 v282              ; a16[4]
  v361 = Load <byte> v373 v282              ; a16[5]
  v196 = Load <byte> v63 v282               ; a16[6]
  v432 = Load <byte> v315 v282              ; a16[7]
  v319 = ZeroExt8to64 <uint64> v432         ; uint64(a16[7])
  v329 = ZeroExt8to64 <uint64> v196         ; uint64(a16[6])
  v330 = Lsh64x64 <uint64> [true] v329 v138 ; uint64(a16[6]) << 8
  v331 = Or64 <uint64> v319 v330            ; a16[7] | a16[6] << 8
; […] idem pour a16[5] à a16[1]
  v401 = ZeroExt8to64 <uint64> v13          ; uint64(a16[0])
  v402 = Lsh64x64 <uint64> [true] v401 v55  ; uint64(a16[0]) << 56
  v403 = Or64 <uint64> v402 v391            ; | a16[0] << 56 = output.addr.hi

memcombine les fusionne en une seule lecture et une inversion :

  v286 = Load <uint64> v22 v282   ; a16[:8]
  v285 = Bswap64 <uint64> v286    ; output.addr.hi

Pour output.addr.lo, voici la chaîne que voit memcombine après late opt :

  v436 = ZeroExt8to64 <uint64> v273 ; addr[15], transmis
  v448 = Or64 <uint64> v436 v447    ; | addr[14] << 8, transmis
  v460 = Or64 <uint64> v459 v448    ; | addr[13] << 16, transmis
  v472 = Or64 <uint64> v471 v460    ; | addr[12] << 24, transmis
  v484 = Or64 <uint64> v483 v472    ; | a16[11] << 32, lu
  v496 = Or64 <uint64> v495 v484    ; | a16[10] << 40, lu
  v508 = Or64 <uint64> v507 v496    ; | a16[9] << 48, lu
  v520 = Or64 <uint64> v519 v508    ; | a16[8] << 56, lu

À partir de v520, quatre des huit termes sont des octets transmis et non des lectures en mémoire : memcombine ne peut pas les combiner. Elle ne fusionne pas non plus les quatre lectures restantes, car elles reposent sur les octets transmis.

Remise en ordre

En résumé, les règles de réécriture s'exécutent trop tôt pour être efficaces. Il existe un contournement rapide : exécuter une première passe memcombine avant late opt. Après cette modification, le code généré pour la fonction utilitaire redevient le plus court possible :

// AX = input.addr.hi, BX = input.addr.lo, CX = input.z
 CMPQ    net/netip·z4(SB), CX     ; vérifier avec "z" s'il s'agit d'une adresse IPv4
 JNE     end                      ; sinon, s'arrêter ici
 MOVQ    net/netip·z6noz(SB), CX  ; CX = netip.z6noz
end:
 RET
// valeur de retour = Addr{hi: AX, lo: BX, z: CX}

Et les mesures de performance le confirment ! ✌️

goos: linux
goarch: amd64
pkg: github.com/vincentbernat/go-netip-addrto6
cpu: AMD Ryzen 5 5600X 6-Core Processor
                   │   Go 1.26.8    │             Our branch              │
                   │     sec/op     │    sec/op     vs base               │
AddrTo6/safe          6.5470n ±  0%   0.8944n ± 4%  -86.34% (p=0.002 n=6)
AddrTo6/unsafe        0.9071n ±  3%   0.8682n ± 1%   -4.28% (p=0.002 n=6)
AddrTo6/builtin       0.8871n ±  2%   0.8785n ± 1%        ~ (p=0.310 n=6)

Prochaine étape

Je pense que les mainteneurs de Go rejetteront cette modification à cause de la passe memcombine supplémentaire. À la place, je compte publier cet article et relancer le sujet à la suite du ticket #54365. Soit la complexité du problème et la régression de Go 1.27 convainquent les mainteneurs qu'il est plus simple et efficace d'ajouter une méthode To6(), soit ils me conseillent sur la marche à suivre. Dans tous les cas, creuser ce sujet m'a beaucoup appris sur le compilateur Go ! ⚙️

Pour associer des informations de routage, telles que les chemins d'AS ou les communautés BGP, aux flux, Akvorado peut importer des routes via le BGP Monitoring Protocol (BMP). Comme la table de routage Internet contient plus d'un million de routes, Akvorado doit gérer des dizaines de millions de routes¹. C'est un défi de longue date², mais je pense que ce problème est désormais résolu grâce au sharding de la RIB, une méthode qui découpe la base de routage en plusieurs parties afin de permettre les mises à jour concurrentes.

Implémentation précédente

Akvorado associe deux éléments pour construire sa RIB :

1. un arbre de préfixes et
2. une liste de routes attachée à chaque préfixe.

Dans le diagramme ci-dessus, la RIB stocke cinq préfixes IPv4 et deux préfixes IPv6. L'un d'eux, 2001:db8:1::/48, contient trois routes :

• depuis le pair 3, via 2001:db8::3:1, AS 65402, chemin d'AS 65402, communauté 65402:31 ;
• depuis le pair 4, via 2001:db8::4:1, mêmes ASN, chemin d'AS et communauté ;
• depuis le pair 5, via 2001:db8::5:1, AS 65402, chemin d'AS 65401 65402, communauté 65402:31.

La structure rib est définie en Go de la manière suivante :

type rib struct {
    tree          *bart.Table[prefixIndex]
    routes        map[routeKey]route
    nlris         *intern.Pool[nlri]
    nextHops      *intern.Pool[nextHop]
    rtas          *intern.Pool[routeAttributes]
    nextPrefixID  prefixIndex
    freePrefixIDs []prefixIndex
}

L'arbre de préfixes s'appuie sur le paquet bart, une adaptation de l'algorithme ART de Donald Knuth. Les benchmarks montrent qu'il surpasse les autres implémentations pour les recherches, les insertions et la consommation mémoire³. De plus, l'auteur est d'une grande aide.

Stocker les routes dans une table associative

La liste des routes de chaque préfixe n'est pas stockée directement dans l'arbre de préfixes : cela mettrait trop de pression sur le ramasse-miettes en allouant un tableau par préfixe.

À la place, la RIB attribue un identifiant de 32 bits unique à chaque préfixe, soit en prenant le dernier identifiant disponible dans le tableau freePrefixIDs, soit en utilisant la valeur nextPrefixID avant de l'incrémenter. Les routes sont ensuite stockées dans la table associative routes, qui s'appuie en Go sur une structure particulièrement optimisée. Pour récupérer les routes attachées à un préfixe, nous les cherchons un par un dans la table routes via une clef de 64 bits qui combine l'index de 32 bits du préfixe avec l'index de 32 bits représentant la position de la route dans la liste. Akvorado parcourt les routes de la première à la dernière pour trouver la meilleure⁴. Il sait qu'il n'y a plus de route lorsque la clé ne renvoie aucun résultat.

type prefixIndex uint32
type routeIndex uint32
type routeKey uint64

Canonisation des routes

Une route contient un identifiant de pair BGP, un NLRI partiel⁵, le prochain saut et les attributs.

type route struct {
    peer       uint32
    nlri       intern.Reference[nlri]
    nextHop    intern.Reference[nextHop]
    attributes intern.Reference[routeAttributes]
    prefixLen  uint8
}

type nlri struct {
    family bgp.Family
    path   uint32
    rd     RD
}
type nextHop netip.Addr
type routeAttributes struct {
    asn              uint32
    asPath           []uint32
    communities      []uint32
    largeCommunities []bgp.LargeCommunity
}

Pour économiser la mémoire et les allocations, les NLRI, les prochains sauts et les attributs de route sont canonisés : un entier de 32 bits remplace la valeur réelle. Ce mécanisme est antérieur au paquet unique introduit dans Go 1.23. Nous le conservons car ses compromis sont différents :

• il utilise un comptage de références explicite plutôt que des pointeurs faibles ;
• il fonctionne avec des valeurs non comparables implémentant les méthodes Hash() et Equal()⁶ ;
• il utilise des instances explicites pour la canonisation, ce qui se révèlera utile pour le sharding ;
• il offre de meilleures performances. Voir par exemple ce benchmark ;
• il consomme deux fois moins de mémoire grâce à des références 32 bits plutôt que des pointeurs ;
• mais il n'est pas utilisable de manière concurrente.

Qu'est-ce qui pose problème ?

Le verrou global en lecture/écriture est le goulot d'étranglement de cette implémentation. Mais pourquoi ? Plusieurs composants utilisent la RIB, chacun avec ses propres contraintes :

• Les consommateurs Kafka consultent la RIB pour enrichir les flux avec des informations de routage. Leur nombre est bornée par la somme des partitions Kafka⁸. Akvorado ajuste également ce nombre afin de garantir un export groupé efficace des flux vers ClickHouse. Sur notre installation, la quantité de consommateurs oscille entre 8 et 16. Comme nous voulons observer les données récentes le plus tôt possible, nous ne pouvons pas nous permettre que les consommateurs Kafka prennent trop de retard.

• Les routeurs surveillés envoient leurs routes via le protocole BMP. À la connexion, ils peuvent envoyer des millions de routes⁹. Après la synchronisation initiale, les mises à jour arrivent en continu et peuvent connaître des pics ponctuels. Le routeur détecte une station BMP bloquée lorsque sa fenêtre TCP est pleine. Dans ce cas, il réinitialise la session. Bien qu'Akvorado dispose d'un important tampon en entrée, il doit appliquer les routes reçues suffisamment vite pour ne pas être considéré comme bloqué.

• Quand un pair BGP distant tombe, Akvorado purge les routes associées en parcourant la RIB. Quand un routeur surveillé tombe, Akvorado patiente un peu, mais finit par purger toutes les routes associées.

En résumé : sur une installation chargée, la contention sur le verrou est forte autant pour les lecteurs que pour les écrivains, et aucun des deux ne peut prendre trop de retard.

Sharding de la RIB

Première étape

Pour supprimer le verrou global, la RIB est découpée en plusieurs « shards », chacun gérant un sous-ensemble des préfixes :

L'arbre de préfixes reste global et protégé par un unique verrou. Chaque partition dispose de son propre verrou en lecture/écriture, de sa table de routes et de ses blocs de canonisation pour stocker les NLRI, les prochains sauts et les attributs de route, ce qui n'aurait pas été possible avec le paquet unique de Go. Les index de préfixes sont eux aussi partitionnés : les 8 bits de poids fort correspondent à l'index de la partition et les 24 bits de poids faible à l'index local du préfixe.

Gerhard a confirmé que suite à ce changement à l'aveugle, le composant BMP a commencé à ronronner. 🎉

J'ai ensuite écrit un benchmark portant sur un demi-million de routes synthétiques mais plausibles¹⁰, réparties entre 0 et 8 écrivains qui modifient les routes aussi vite que possible, tandis que 1 à 16 lecteurs consultent en boucle un ensemble de 10 000 routes. J'ignore si ce benchmark est réaliste, mais il confirme les améliorations à la fois sur les latences en lecture et en écriture :

Il montre également qu'un grand nombre d'écrivains dégrade la latence en lecture.

Deuxième étape

L'unique verrou en lecture/écriture protégeant l'arbre de préfixes constitue la cible suivante. Le paquet bart propose des méthodes alternatives pour les mutations. Elles renvoient un arbre mis à jour via une copie partielle. Les lecteurs n'ont plus besoin du verrou global, qui ne sert plus qu'à synchroniser les écrivains. L'arbre de préfixes est encapsulé dans un pointeur atomique.

Sans verrou, un lecteur peut désormais récupérer un index de préfixe périmé en parcourant sa copie de l'arbre, lorsqu'un écrivain concurrent supprime la dernière route attachée à cet index et le recycle pour un autre préfixe. Pour éviter ce problème, nous combinons l'index de préfixe avec un numéro de génération que nous stockons dans l'arbre :

type generation uint32
type prefixRef struct {
    idx prefixIndex
    gen generation
}
type rib struct {
    mu     sync.Mutex
    tree   atomic.Pointer[bart.Table[prefixRef]]
    shards []*ribShard
}

Chaque partition stocke le numéro de génération de chaque index de préfixe local. Ce numéro est incrémenté quand l'index de préfixe associé est libéré. Lors de la recherche des routes attachées à un index de préfixe, le lecteur vérifie que le numéro de génération correspond. Sinon, il considère que l'index a été recyclé et que la liste de routes est vide¹¹. Le schéma précédent illustre ce cas pour l'index de préfixe 5, stocké avec un numéro de génération de 3, alors que la valeur actuelle dans le tableau []generations est 4. Le numéro de génération peut boucler, mais ce n'est pas un problème car les recherches sont rapides.

L'exécution du benchmark sur cette nouvelle implémentation montre les améliorations sur la latence en lecture ainsi qu'en écriture dès que le coût de la copie partielle de l'arbre de préfixes est amorti.

Parmi les nombreuses tentatives d'optimisation du composant BMP, le sharding de la RIB est l'une des plus satisfaisantes. Akvorado 2.2 implémente la première étape. La PR #2433, rédigée pendant l'écriture de ce billet, implémente la seconde et est sortie avec Akvorado 2.4. 🪓

Akvorado collecte des flux sFlow et IPFIX via UDP. Comme UDP ne retransmet pas les paquets perdus, il faut les traiter rapidement. Akvorado exécute plusieurs routines écoutant sur le même port. Le noyau devrait répartir équitablement les paquets reçus entre ces routines. Cependant, cela ne fonctionne pas comme prévu. Quelques routines présentent une perte de paquets importante :

$ curl -s 127.0.0.1:8080/api/v0/inlet/metrics \
> | sed -n s/akvorado_inlet_flow_input_udp_in_dropped//p
packets_total{listener="0.0.0.0:2055",worker="0"} 0
packets_total{listener="0.0.0.0:2055",worker="1"} 0
packets_total{listener="0.0.0.0:2055",worker="2"} 0
packets_total{listener="0.0.0.0:2055",worker="3"} 1.614933572278264e+15
packets_total{listener="0.0.0.0:2055",worker="4"} 0
packets_total{listener="0.0.0.0:2055",worker="5"} 0
packets_total{listener="0.0.0.0:2055",worker="6"} 9.59964121598348e+14
packets_total{listener="0.0.0.0:2055",worker="7"} 0

eBPF peut aider en implémentant un algorithme de répartition alternatif. 🐝

Options pour la répartition de charge

Il existe trois méthodes pour répartir les paquets UDP entre des routines :

1. Une routine reçoit les paquets et les distribue aux autres routines.
2. Toutes les routines partagent la même chaussette.
3. Chaque routine a sa propre chaussette, liée au même port, avec l'option SO_REUSEPORT.

Option SO_REUSEPORT

Tom Hebert a ajouté l'option SO_REUSEPORT dans Linux 3.9. La présentation de sa série de patchs explique pourquoi cette nouvelle option est meilleure que les deux existantes du point de vue des performances :

SO_REUSEPORT permet à plusieurs chaussettes d'être liées au même port. […] Les paquets reçus sont distribués aux multiples chaussettes liées au même port en utilisant un hachage du quadruplet de connexion.

Le cas d'usage pour SO_RESUSEPORT en TCP serait quelque chose comme un serveur web écoutant sur le port 80 fonctionnant avec plusieurs routines, où chaque routine pourrait avoir sa propre chaussette d'écoute. Cela pourrait être une alternative à d'autres modèles :

1. avoir une routine d'écoute qui distribue les connexions aux autres routines ;
2. accepter sur une seule chaussette depuis plusieurs routines.

Dans le premier cas, la routine d'écoute peut facilement devenir un goulot d'étranglement. Dans le second cas, la proportion de connexions acceptées par routine a tendance à être inégale sous une charge élevée. […] Nous avons vu la disproportion atteindre un ratio de 3:1 entre la routine acceptant le plus de connexions et celle qui en accepte le moins. Avec SO_REUSEPORT, la distribution est uniforme.

Le cas d'usage pour SO_REUSEPORT en UDP serait quelque chose comme un serveur DNS. Une alternative serait de recevoir sur la même chaussette depuis plusieurs routines. Comme dans le cas de TCP, la charge entre ces routines a tendance à être disproportionnée et nous observons également beaucoup de contention sur le verrou de la chaussette.

Akvorado utilise l'option SO_REUSEPORT pour distribuer les paquets entre les routines. Comme la distribution utilise un hachage du quadruplet de connexion, une seule routine gère tous les flux provenant d'un exporteur.

Option SO_ATTACH_REUSEPORT_EBPF

Dans Linux 4.5, Craig Gallek a ajouté l'option SO_ATTACH_REUSEPORT_EBPF pour permettre à un programme eBPF de sélectionner la chaussette UDP cible. Dans Linux 4.6, il l'a étendue pour prendre en charge TCP. La page de manuel socket(7) documente ce mécanisme¹ :

Le programme BPF doit renvoyer un index entre 0 et N-1 représentant la chaussette qui devrait recevoir le paquet (où N est le nombre de chaussettes dans le groupe). Si le programme BPF renvoie un index invalide, la sélection de chaussette se rabattra sur le mécanisme SO_REUSEPORT standard.

Dans Linux 4.19, Martin KaFai Lau a ajouté le type de programme BPF_PROG_TYPE_SK_REUSEPORT. Un tel programme eBPF sélectionne la chaussette à partir d'un tableau associatif. Cette nouvelle approche est plus flexible et permet par exemple un redémarrage sans impact en insérant les chaussettes d'une nouvelle instance.

Répartition de charge avec eBPF et Go

Modifier l'algorithme de répartition de charge pour un groupe de chaussettes nécessite deux étapes :

1. écrire et compiler un programme eBPF en C² ;
2. le charger et l'attacher en Go.

Programme eBPF en C

Un algorithme de répartition de charge simple consiste à choisir aléatoirement la chaussette de destination. Le noyau expose la fonction bpf_get_prandom_u32() pour obtenir un nombre pseudo-aléatoire.

volatile const __u32 num_sockets; // ❶

struct {
    __uint(type, BPF_MAP_TYPE_REUSEPORT_SOCKARRAY);
    __type(key, __u32);
    __type(value, __u64);
    __uint(max_entries, 256);
} socket_map SEC(".maps"); // ❷

SEC("sk_reuseport")
int reuseport_balance_prog(struct sk_reuseport_md *reuse_md)
{
    __u32 index = bpf_get_prandom_u32() % num_sockets; // ❸
    bpf_sk_select_reuseport(reuse_md, &socket_map, &index, 0); // ❹
    return SK_PASS; // ❺
}

char _license[] SEC("license") = "GPL";

En ❶, nous déclarons une constante volatile pour le nombre de chaussettes dans le groupe. Nous initialiserons cette constante avant de charger le programme eBPF dans le noyau. En ❷, nous définissons le tableau associatif de chaussettes. Nous le remplirons par la suite avec les descripteurs de fichiers. En ❸, nous sélectionnons aléatoirement l'index de la chaussette cible³. En ❹, nous invoquons la fonction bpf_sk_select_reuseport() pour enregistrer notre décision. Enfin, en ❺, nous acceptons le paquet.

Fichiers d'en-tête

Si vous compilez le source C avec clang, vous obtenez des erreurs dues à des entêtes manquantes. La méthode conseillée pour résoudre ce problème consiste à générer un fichier vmlinux.h avec bpftool :

$ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

Ensuite, incluez les entêtes suivantes⁴ :

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

Pour mon noyau 6.17, le fichier vmlinux.h généré est assez volumineux : 2,7 Mio. De plus, bpf/bpf_helpers.h est fourni avec libbpf. Cela ajoute une autre dépendance. Comme le programme eBPF est assez petit, je préfère mettre le strict minimum dans vmlinux.h en sélectionnant les définitions dont j'ai besoin.

Compilation

La bibliothèque eBPF pour Go fournit bpf2go, un outil pour compiler les programmes eBPF et générer un squelette de code. Nous créons un fichier gen.go avec le contenu suivant :

package main

//go:generate go tool bpf2go -tags linux reuseport reuseport_kern.c

Après avoir exécuté go generate ./..., nous pouvons inspecter les objets résultants avec readelf et llvm-objdump :

$ readelf -S reuseport_bpfeb.o
There are 14 section headers, starting at offset 0x840:
  [Nr] Name              Type             Address           Offset
[…]
  [ 3] sk_reuseport      PROGBITS         0000000000000000  00000040
  [ 6] .maps             PROGBITS         0000000000000000  000000c8
  [ 7] license           PROGBITS         0000000000000000  000000e8
[…]
$ llvm-objdump -S reuseport_bpfeb.o
reuseport_bpfeb.o:  file format elf64-bpf
Disassembly of section sk_reuseport:
0000000000000000 <reuseport_balance_prog>:
; {
       0:   bf 61 00 00 00 00 00 00     r6 = r1
;     __u32 index = bpf_get_prandom_u32() % num_sockets;
       1:   85 00 00 00 00 00 00 07     call 0x7
[…]

Utilisation depuis Go

Configurons 10 routines écoutant sur le même port⁵. Chaque chaussette active l'option SO_REUSEPORT avant de se mettre en écoute⁶ :

var (
    err error
    fds []uintptr
    conns []*net.UDPConn
)
workers := 10
listenAddr := "127.0.0.1:0"
listenConfig := net.ListenConfig{
    Control: func(_, _ string, c syscall.RawConn) error {
        c.Control(func(fd uintptr) {
            err = unix.SetsockoptInt(int(fd), unix.SOL_SOCKET, unix.SO_REUSEPORT, 1)
            fds = append(fds, fd)
        })
        return err
    },
}
for range workers {
    pconn, err := listenConfig.ListenPacket(t.Context(), "udp", listenAddr)
    if err != nil {
        t.Fatalf("ListenPacket() error:\n%+v", err)
    }
    udpConn := pconn.(*net.UDPConn)
    listenAddr = udpConn.LocalAddr().String()
    conns = append(conns, udpConn)
}

La deuxième étape consiste à charger le programme eBPF, initialiser la variable num_sockets, remplir le tableau de chaussettes et attacher le programme à la première chaussette⁷.

// Charge la collection eBPF.
spec, err := loadReuseport()
if err != nil {
    t.Fatalf("loadVariables() error:\n%+v", err)
}

// Initialise la variable globale "num_sockets" avec le nombre de descripteurs de fichiers.
if err := spec.Variables["num_sockets"].Set(uint32(len(fds))); err != nil {
    t.Fatalf("NumSockets.Set() error:\n%+v", err)
}

// Charge le programme et le tableau dans le noyau.
var objs reuseportObjects
if err := spec.LoadAndAssign(&objs, nil); err != nil {
    t.Fatalf("loadReuseportObjects() error:\n%+v", err)
}
t.Cleanup(func() { objs.Close() })

// Renseigne les descripteurs de fichiers dans le tableau de chaussettes.
for worker, fd := range fds {
    if err := objs.reuseportMaps.SocketMap.Put(uint32(worker), uint64(fd)); err != nil {
        t.Fatalf("SocketMap.Put() error:\n%+v", err)
    }
}

// Attache le programme eBPF à la première chaussette.
socketFD := int(fds[0])
progFD := objs.reuseportPrograms.ReuseportBalanceProg.FD()
if err := unix.SetsockoptInt(socketFD, unix.SOL_SOCKET, unix.SO_ATTACH_REUSEPORT_EBPF, progFD); err != nil {
    t.Fatalf("SetsockoptInt() error:\n%+v", err)
}

Nous sommes maintenant prêts à traiter les paquets. Chaque routine Go incrémente un compteur pour chaque paquet reçu⁸ :

var wg sync.WaitGroup
receivedPackets := make([]int, workers)
for worker := range workers {
    conn := conns[worker]
    packets := &receivedPackets[worker]
    wg.Go(func() {
        payload := make([]byte, 9000)
        for {
            if _, err := conn.Read(payload); err != nil {
                if errors.Is(err, net.ErrClosed) {
                    return
                }
                t.Logf("Read() error:\n%+v", err)
            }
            *packets++
        }
    })
}

Envoyons 1000 paquets :

sentPackets := 1000
conn, err := net.Dial("udp", conns[0].LocalAddr().String())
if err != nil {
    t.Fatalf("Dial() error:\n%+v", err)
}
defer conn.Close()
for range sentPackets {
    if _, err := conn.Write([]byte("hello world!")); err != nil {
        t.Fatalf("Write() error:\n%+v", err)
    }
}

Si nous affichons le contenu du tableau receivedPackets, nous pouvons vérifier que la répartition fonctionne comme prévu, chaque routine recevant environ 100 paquets :

=== RUN   TestUDPWorkerBalancing
    balancing_test.go:84: receivedPackets[0] = 107
    balancing_test.go:84: receivedPackets[1] = 92
    balancing_test.go:84: receivedPackets[2] = 99
    balancing_test.go:84: receivedPackets[3] = 105
    balancing_test.go:84: receivedPackets[4] = 107
    balancing_test.go:84: receivedPackets[5] = 96
    balancing_test.go:84: receivedPackets[6] = 102
    balancing_test.go:84: receivedPackets[7] = 105
    balancing_test.go:84: receivedPackets[8] = 99
    balancing_test.go:84: receivedPackets[9] = 88

    balancing_test.go:91: receivedPackets = 1000
    balancing_test.go:92: sentPackets     = 1000

Déploiement sans impact

Nous pouvons également utiliser SO_ATTACH_REUSEPORT_EBPF pour redémarrer une application sans impact. Une nouvelle instance de l'application prépare sa propre version du tableau de chaussettes et attache le programme eBPF à la première d'entre elles. Le noyau dirige alors les paquets entrants vers cette nouvelle instance. L'ancienne instance doit traiter les paquets déjà reçus avant de s'arrêter.

Pour vérifier que nous ne perdons aucun paquet, nous créons une routine Go pour envoyer autant de paquets que possible :

sentPackets := 0
notSentPackets := 0
done := make(chan bool)
conn, err := net.Dial("udp", conns1[0].LocalAddr().String())
if err != nil {
    t.Fatalf("Dial() error:\n%+v", err)
}
defer conn.Close()
go func() {
    for {
        if _, err := conn.Write([]byte("hello world!")); err != nil {
            notSentPackets++
        } else {
            sentPackets++
        }
        select {
        case <-done:
            return
        default:
        }
    }
}()

Ensuite, pendant que cette routine Go s'exécute, nous démarrons le deuxième ensemble de routines. Une fois configurées, elles commencent à recevoir des paquets. Si nous arrêtons proprement l'ensemble initial de routines, nous ne perdons aucun paquet⁹ !

=== RUN   TestGracefulRestart
    graceful_test.go:135: receivedPackets1[0] = 165
    graceful_test.go:135: receivedPackets1[1] = 195
    graceful_test.go:135: receivedPackets1[2] = 194
    graceful_test.go:135: receivedPackets1[3] = 190
    graceful_test.go:135: receivedPackets1[4] = 213
    graceful_test.go:135: receivedPackets1[5] = 187
    graceful_test.go:135: receivedPackets1[6] = 170
    graceful_test.go:135: receivedPackets1[7] = 190
    graceful_test.go:135: receivedPackets1[8] = 194
    graceful_test.go:135: receivedPackets1[9] = 155

    graceful_test.go:139: receivedPackets2[0] = 1631
    graceful_test.go:139: receivedPackets2[1] = 1582
    graceful_test.go:139: receivedPackets2[2] = 1594
    graceful_test.go:139: receivedPackets2[3] = 1611
    graceful_test.go:139: receivedPackets2[4] = 1571
    graceful_test.go:139: receivedPackets2[5] = 1660
    graceful_test.go:139: receivedPackets2[6] = 1587
    graceful_test.go:139: receivedPackets2[7] = 1605
    graceful_test.go:139: receivedPackets2[8] = 1631
    graceful_test.go:139: receivedPackets2[9] = 1689

    graceful_test.go:147: receivedPackets = 18014
    graceful_test.go:148: sentPackets     = 18014

Malheureusement, arrêter correctement une chaussette UDP n'est pas trivial en Go¹⁰. Auparavant, nous terminions les routines en fermant leurs chaussettes. Cependant, si nous les fermons trop tôt, l'application perd les paquets qui leur ont été attribués mais qui n'ont pas encore été traités. Avant de s'arrêter, une routine doit appeler conn.Read() jusqu'à ce qu'il n'y ait plus de paquets. Une solution consiste à définir une échéance pour conn.Read() et vérifier si nous devons arrêter la routine Go lorsque l'échéance est écoulée :

payload := make([]byte, 9000)
for {
    conn.SetReadDeadline(time.Now().Add(50 * time.Millisecond))
    if _, err := conn.Read(payload); err != nil {
        if errors.Is(err, os.ErrDeadlineExceeded) {
            select {
            case <-done:
                return
            default:
                continue
            }
        }
        t.Logf("Read() error:\n%+v", err)
    }
    *packets++
}

Avec TCP, cet aspect est plus simple : après avoir activé le paramètre noyau net.ipv4.tcp_migrate_req, le noyau migre automatiquement les connexions en attentes vers une chaussette aléatoire du même groupe. Alternativement, eBPF peut également contrôler cette migration. Les deux fonctionnalités sont disponibles depuis Linux 5.14.

Addendum

Après avoir implémenté cette stratégie dans Akvorado, toutes les routines perdent désormais des paquets ! 😱

$ curl -s 127.0.0.1:8080/api/v0/inlet/metrics \
> | sed -n s/akvorado_inlet_flow_input_udp_in_dropped//p
packets_total{listener="0.0.0.0:2055",worker="0"} 838673
packets_total{listener="0.0.0.0:2055",worker="1"} 843675
packets_total{listener="0.0.0.0:2055",worker="2"} 837922
packets_total{listener="0.0.0.0:2055",worker="3"} 841443
packets_total{listener="0.0.0.0:2055",worker="4"} 840668
packets_total{listener="0.0.0.0:2055",worker="5"} 850274
packets_total{listener="0.0.0.0:2055",worker="6"} 835488
packets_total{listener="0.0.0.0:2055",worker="7"} 834479

La raison majeure est que le module Kafka limite par défaut les lots à 32 messages. Cette limite est trop basse car les brokers ont une charge importante lors du traitement de chaque lot : ils doivent s'assurer de leur bonne persistance avant d'accuser réception. Augmenter la limite à 4096 messages corrige ce problème.

Bien que la répartition des flux entrants avec eBPF reste utile, elle n'a pas résolu le problème principal. Au moins, la distribution uniforme des paquets perdus a aidé à identifier le véritable goulot d'étranglement. 😅

La fonctionnalité embed de Go permet d'intégrer des ressources statiques dans un exécutable, mais elle les stocke non compressées. Cela gaspille de l'espace : une interface web avec de la documentation peut faire gonfler un binaire de plusieurs mégaoctets. Une proposition pour activer optionnellement la compression a été déclinée car il est difficile de gérer tous les cas d'usage. Une solution ? Mettre toutes les ressources dans une archive ZIP ! 🗜️

Code

La bibliothèque standard de Go inclut un module pour lire et écrire des archives ZIP. Il contient une fonction qui transforme une archive ZIP en une structure io/fs.FS. Cette dernière peut remplacer embed.FS dans la plupart des cas¹.

package embed

import (
  "archive/zip"
  "bytes"
  _ "embed"
  "fmt"
  "io/fs"
  "sync"
)

//go:embed data/embed.zip
var embeddedZip []byte

var dataOnce = sync.OnceValue(func() *zip.Reader {
  r, err := zip.NewReader(bytes.NewReader(embeddedZip), int64(len(embeddedZip)))
  if err != nil {
    panic(fmt.Sprintf("cannot read embedded archive: %s", err))
  }
  return r
})

func Data() fs.FS {
  return dataOnce()
}

Pour construire l'archive embed.zip, nous pouvons utiliser une règle dans un Makefile. Les fichiers à y placer sont spécifiés comme des dépendances pour s'assurer que les changements sont détectés. La variable automatique $@ est la cible de la règle, tandis que $^ est remplacée par la liste des dépendances, modifiées ou non.

common/embed/data/embed.zip: console/data/frontend console/data/docs
common/embed/data/embed.zip: orchestrator/clickhouse/data/protocols.csv
common/embed/data/embed.zip: orchestrator/clickhouse/data/icmp.csv
common/embed/data/embed.zip: orchestrator/clickhouse/data/asns.csv
common/embed/data/embed.zip:
    mkdir -p common/embed/data && zip --quiet --recurse-paths --filesync $@ $^

Gain d'espace

Akvorado, un collecteur de flux écrit en Go, embarque plusieurs ressources statiques :

• des fichiers CSV pour traduire les numéros de ports, les protocoles ou les numéros d'AS ;
• du HTML, CSS, JS et des images pour l'interface web ;
• la documentation.

L'intégration de ces ressources dans une archive ZIP a réduit la taille de l'exécutable de plus de 4 Mio :

$ unzip -p common/embed/data/embed.zip | wc -c | numfmt --to=iec
7.3M
$ ll common/embed/data/embed.zip
-rw-r--r-- 1 bernat users 2.9M Dec  7 17:17 common/embed/data/embed.zip

Perte de performance

Lire depuis une archive compressée n'est pas aussi rapide que lire un fichier à plat. Un benchmark simple montre que c'est plus de 4 fois plus lent. De plus, la lecture de l'archive alloue de la mémoire².

goos: linux
goarch: amd64
pkg: akvorado/common/embed
cpu: AMD Ryzen 5 5600X 6-Core Processor
BenchmarkData/compressed-12     2262   526553 ns/op   610 B/op   10 allocs/op
BenchmarkData/uncompressed-12   9482   123175 ns/op     0 B/op    0 allocs/op

Chaque accès à une ressource nécessite une étape de décompression, comme on peut le voir dans ce graphique :

Bien qu'une archive ZIP ait un index pour trouver rapidement le fichier demandé, se déplacer à l'intérieur d'un fichier compressé n'est actuellement pas possible³. Par conséquent, les fichiers retournés depuis une archive compressée n'implémentent pas les interfaces io.ReaderAt ou io.Seeker, contrairement aux fichiers directement embarqués. Cela empêche certaines fonctionnalités du serveur HTTP, comme servir des fichiers partiels ou détecter le type MIME.

Pour Akvorado, c'est un compromis acceptable pour économiser quelques mébioctets d'un exécutable de presque 100 Mio. La semaine prochaine, je continuerai cette aventure futile en expliquant comment j'ai empêché Go de désactiver l'élimination de code mort ! 🦥

Akvorado 2.0 est publié aujourd'hui ! Akvorado est un collecteur de flux réseau IPFIX et sFlow. Il enrichit les flux et les stocke dans une base de données ClickHouse. Les utilisateurs peuvent parcourir les données via une console web. Cette version introduit un changement architectural important et d'autres améliorations mineures. Regardons plus en détails ! 🤿

$ git diff --shortstat v1.11.5
 493 files changed, 25015 insertions(+), 21135 deletions(-)

Nouveau service « outlet »

Le changement majeur dans Akvorado 2.0 est la séparation du service inlet en deux parties : l'inlet et l'outlet. Auparavant, l'inlet gérait tout le traitement des flux : réception, décodage et enrichissement. Les flux étaient ensuite envoyés à Kafka pour stockage dans ClickHouse :

Les flux réseau atteignent le service inlet via des chaussettes UDP, un protocole non fiable. L'inlet doit les traiter assez rapidement pour éviter de perdre des paquets. Pour gérer un grand nombre de flux, l'inlet crée plusieurs ensembles de workers pour recevoir les flux, récupérer les métadonnées et assembler les flux enrichis pour Kafka. De nombreuses options de configuration existaient pour la montée en charge, ce qui augmentait la complexité pour les utilisateurs. Le code devait éviter tout blocage, rendant la chaîne de traitement complexe et parfois peu fiable, notamment le composant BMP¹. L'ajout de nouvelles fonctionnalités sans aggraver le problème devenait difficile².

Dans Akvorado 2.0, l'inlet reçoit les flux et les pousse vers Kafka sans les décoder. Le nouveau service outlet gère les tâches restantes :

Ce changement va au-delà d'un simple découpage³ : l'outlet lit maintenant les flux depuis Kafka et les pousse vers ClickHouse, deux tâches qu'Akvorado ne gérait pas auparavant. Les flux sont groupés par lots pour augmenter l'efficacité et réduire la charge sur ClickHouse en utilisant ch-go, un client Go bas niveau pour ClickHouse. Quand les lots sont trop petits, des insertions asynchrones sont utilisées (e20645). Le nombre de workers de l'outlet s'ajuste dynamiquement (e5a625) en fonction de la cible sur la taille des lots et de la latence (50 000 flux et 5 secondes par défaut).

Cette nouvelle architecture nous permet également de simplifier et optimiser le code. L'outlet récupère les métadonnées de façon synchrone (e20645). Le composant BMP devient plus simple en supprimant le multitâche coopératif (3b9486). Réutiliser le même objet RawFlow pour décoder les flux Protobuf depuis Kafka réduit la pression sur le ramasse-miettes (8b580f).

L'effet sur les performances globales d'Akvorado était quelque peu incertain, mais un utilisateur a indiqué gagner 35 % d'utilisation CPU en moins après migration depuis la version précédente, ainsi que la résolution du problème de longue date du composant BMP. 🥳

Autres changements

Cette nouvelle version inclut de nombreux changements divers. On y trouve par exemple la complétion pour les ports sources et destinations (f92d2e), et le redémarrage automatique de l'orchestrateur (0f72ff) lors de changements de configuration pour éviter un piège courant pour les nouveaux utilisateurs.

Concentrons-nous sur quelques domaines clés pour cette version : observabilité, documentation, CI, Docker, Go et JavaScript.

Observabilité

Akvorado expose des métriques pour fournir une visibilité sur la chaîne de traitement et aider à diagnostiquer les problèmes. Elles sont disponibles au format Prometheus, via par exemple /api/v0/inlet/metrics. Avec l'introduction de l'outlet, de nombreuses métriques ont été déplacées. Certaines ont également été renommées (4c0b15) pour correspondre aux bonnes pratiques Prometheus. Une métrique pour mesurer le décalage des consommateurs Kafka a été ajoutée (e3a778).

Si vous n'avez pas votre propre pile d'observabilité, la configuration Docker Compose fournie avec Akvorado en propose une. Vous pouvez l'activer avec les profils introduits à cette fin (529a8f).

Le profil prometheus fournit Prometheus pour stocker les métriques et Alloy pour les collecter (2b3c46, f81299 et 8eb7cd). Les métriques Redis et Kafka sont collectées via l'exporteur intégré à Alloy (560113). Les autres métriques sont exposées au format Prometheus et sont automatiquement récupérées par Alloy à l'aide d'annotations Docker. C'est similaire à ce qui est fait pour configurer Traefik. cAdvisor a également été ajouté (83d855) pour fournir des métriques liées aux conteneurs.

Le profil loki fournit Loki pour stocker les logs (45c684). Bien qu'Alloy puisse collecter et envoyer les logs vers Loki, ses capacités d'analyse sont limitées : je n'ai pas trouvé de moyen de préserver toutes les métadonnées associées aux logs structurés produits par de nombreuses applications, y compris Akvorado. Vector remplace Alloy (95e201) et propose un langage, VRL, pour transformer les logs. Malheureusement, il ne peut actuellement pas récupérer les logs Docker précédant son démarrage.

Enfin, le profil grafana fournit Grafana, mais les tableaux de bord fournis sont pour le moment cassés. Ce sera corrigé dans une prochaine version.

Documentation

La configuration Docker Compose fournie par Akvorado facilite la mise en route rapide. Cependant, Akvorado nécessite quelques étapes obligatoires pour être fonctionnel. Il est livré avec une documentation complète, y compris un chapitre sur le dépannage des problèmes. J'espérais que cette documentation réduirait la charge de support. Il est difficile de savoir si cela fonctionne. Les utilisateurs satisfaits rapportent rarement leurs succès, tandis qu'une poignée d'utilisateurs ouvrent des discussions pour demander de l'aide sans avoir vraiment lu la documentation.

Dans cette version, la documentation a été considérablement améliorée.

$ git diff --shortstat v1.11.5 -- console/data/docs
 10 files changed, 1873 insertions(+), 1203 deletions(-)

La documentation a été mise à jour (fc1028) pour correspondre à la nouvelle architecture d'Akvorado. La section de dépannage a été réécrite (17a272). Une documentation sur comment améliorer les performances de ClickHouse lors de la mise à niveau depuis des versions antérieures à 1.10.0 a été ajoutée (5f1e9a). Un LLM a relu l'ensemble (06e3f3). La documentation destinée aux développeurs a également été améliorée (548bbb, e41bae et 871fc5).

Du point de vue de l'utilisabilité, les sections de la table des matières peuvent maintenant se replier (c142e5). Les avertissements aident à attirer l'attention des utilisateurs sur les points importants (8ac894).

Intégration continue

Cette version inclut des efforts pour accélérer l'intégration continue sur GitHub. Les tests de couverture et de concurrence s'exécutent en parallèle (6af216 et fa9e48). L'image Docker se construit pendant les tests mais ne reçoit son étiquette qu'après leurs succès (8b0dce).

Les tests de bout en bout (883e19) s'assurent que la configuration Docker Compose fournie fonctionne comme attendu. Hurl exécute des tests sur diverses URL, notamment pour vérifier les métriques (42679b et 169fa9). Par exemple :

## Test inlet has received NetFlow flows
GET http://127.0.0.1:8080/prometheus/api/v1/query
[Query]
query: sum(akvorado_inlet_flow_input_udp_packets_total{job="akvorado-inlet",listener=":2055"})
HTTP 200
[Captures]
inlet_receivedflows: jsonpath "$.data.result[0].value[1]" toInt
[Asserts]
variable "inlet_receivedflows" > 10

## Test inlet has sent them to Kafka
GET http://127.0.0.1:8080/prometheus/api/v1/query
[Query]
query: sum(akvorado_inlet_kafka_sent_messages_total{job="akvorado-inlet"})
HTTP 200
[Captures]
inlet_sentflows: jsonpath "$.data.result[0].value[1]" toInt
[Asserts]
variable "inlet_sentflows" >= {{ inlet_receivedflows }}

Docker

Akvorado est fourni avec une configuration Docker Compose complète pour aider les utilisateurs à démarrer rapidement. Elle assure un déploiement cohérent, éliminant de nombreux problèmes liés à l'environnement et la configuration. Elle sert également de documentation.