router: afpacket udp underlay #4763

jiceathome · 2025-05-05T15:20:36Z

the afpudpip underlay is interchangeable with the udpip underlay but uses af_packet sockets instead of udp sockets. The only expected difference is performance.

Summary:

Add new underlay implementation that uses raw sockets:

Implements point-to-point and open-ended UDP "connections"
Implements IPv4, IPv6, ARP, and NDP

Add support for the router to select between interchangeable underlays.
Move egress packet buffer disposition and metering to underlay (to support
asynchronous transmission after ARP/NDP resolution).

Other things there were required as a consequence or to enable debugging:

Added the capabilities cap_bpf, cap_net_admin and cap_net_raw to everything
that executes the router and have the rpm/deb installers do likewise.
Make the latency-sensitive tests a little more lenient because our CI system
runs on AWS which sacrifices network latency.
Enable the setup-run-teardown mode of operations for the router benchmark.
Add a debug-run (brief) mode to the router_benchmark.
Added a latency mesurement to the router benchmark.
Made the traffic generator of the router benchmark faster.
Improve the bpf filtering in private/underlay to include IP addresses in the
filtering keys and to manage both a kernel side and a socket-side filter.
(The kernel-side lets the kernel have only what the socket-side does not
take).
Added some sysctl when starting supervisor-based configurations to enable
the sending of raw packets through the loopback interface.
Made the braccept runner able to respond to ARP/NDP and to filter redundant
traffic.

In passing:

At long last addressed the docker-compose warning about the deprecated
version field.
Removed a useless ~1second delay after the last ping send in scion ping.
Added a v4 only default-like config for end2end tests.
Update goheader lint config to allow choice of license text or SPDX line.

Fixes: #4732

jiceathome · 2025-05-05T15:20:43Z

This change is

Doesn't work yet.

Added another filter. Needed to ensure that the kernel does not do any processing on the packets received by the raw socket. Expensive stuff would otherwise result (e.g. icmp responses).

Also ditched the PacketSource and Packets() channel. It's too buggy even for us in tests (crashes after closing the afp). Added draining for afp once filter is set. Else we get stray packets, which confuses the test. Did the same in the afp undelay.

…nderlay.

…ardown).

Comments, debug stmt and useless error return.

Now passes the benchmark.

Not quite sure what difference it makes, but it sure isn't an sh_test.

In passing added some facility for short debug runs.

This is a feable attempt at making it at least slightly faster than the router.

We used to require more than 3% packet drop. We are now content with 3% or more.

Had to rearrange the code a tiny bit. In passing, attempting to add the needed capabilities to the router in integration tests besides the router benchmark.

In passing. Fixed another missing space in router_multi test script.

In passing, further simplified the process of making debug runs of the router benchmark.

The underlay shouldn't be producing any garbage any more. Src addresses get stored at the head of the packet buffer.

jiceathome

Reviewable status: 87 of 100 files reviewed, 1 unresolved discussion (waiting on @jeltevanbommel, @JordiSubira, @marcfrei, @oncilla, and @romshark)

router/dataplane.go line 534 at r5 (raw file):

Previously, jeltevanbommel (jelte) wrote…

Just checked, I did extend the link config with more fields, and then had a struct SendingOptions that was passed in to the underlays. That struct then had a bunch of withXYZ functions to build the options, for which the linkinfo data, amongst others, was used. Something similar could work here, but in any case, as long as there are arbitrary options that can be passed in, it's okay. What about having a composable Options struct, containing an IPOptions, that you create with the link.LocalAddr and link.Remote.Addr, and then later on e.g., an MPLSOptions could be added? Then you're not directly passing in the LinkInfo, but you can still arbitrarily extend it?

I am reluctant to add any kind of complex configuration. I am very concerned that we if try to define something like that is a structured way we will end-up complexifying it for every single new underlay that anyone comes up with. I think this is a compelling case for under-specification. Each underlay can have whatever configuration it wants; as long as it is willing to parse the string. So, I added an "options" field. If that proves insufficient, or inadequate once you are actively trying to add a new underlay, then you have my heartfelt blessing to change it.

Implemented it very minimally, though: one arbitrary options string.

tzaeschke

LGTM, with the big caveat that I don´t really speak go and I know nothing about AF sockets. In short, the PR as such looks good to me, but I can't really judge technical correctness.

tzaeschke · 2025-09-08T08:40:28Z

MODULE.bazel.lock

Is this file intentionally in the repository?

Yeah. For now that's the least bad solution. It's supposed to be in the repo to ensure the locking, but on the other hand it is updated automatically. It's all silly and nobody at bazel seems to know what the right thing to do is.

tzaeschke · 2025-09-08T08:51:44Z

acceptance/router_benchmark/brload/main.go

 	metricsBegin := begin.Unix()

 	numPkt := 0
+out:


Isn't there a better way than using goto? On first sight it is unclear to me whether this loop will always terminate...
Is this normal "style" in go? Disclaimer: I am really not very good at reading go, I have written maybe 200 lines go in my life...

It's not a bare goto; it is a label to dissambiguate a break statement. Two loops are nested and we need to break out of both.

tzaeschke · 2025-09-08T08:52:44Z

acceptance/router_benchmark/brload/main.go

 		case outcome = <-listenerChan:
 			if outcome == 0 {
-				log.Error("Listener never saw a valid packet being forwarded")
+				log.Error("listener never saw a valid packet being forwarded")


Use uppercase "Listener"?

for some reason, the dominant go convention is to never write errors as full sentences.

tzaeschke · 2025-09-08T08:53:47Z

acceptance/router_benchmark/brload/mmsg.go

+
+	// If we're going to send, we need to make sure we're not receiving our own stuff. The default
+	// behaviour is less than clear. The loopback doesn't work with veth, but likely does with
+	// else.


What is "else"? Sentence?

tzaeschke · 2025-09-08T08:56:41Z

acceptance/router_benchmark/brload/mmsg.go

+	for {
+		// This will hog a core (as far as the Go scheduler is concerned) for the duration of the
+		// call as the Go run-time has no idea that this is a blocking write. This is perfectly fine
+		// for our use case. This can be made non-blocking if that helps sending faster.


This sounds like making it non-blocking requires a code change. Why is the an if-clause below that deals with the non-blocking state? Am I mixing things up?

No you're not mixing things up. The if clause below is only useful if non-blocking is used. Otherwise, it does nothing and costs almost nothing. After experimenting with many, many variations, I found it convenient that I could switch to non-blocking mode by just changing the flag, but as of now, non-blocking brings no improvement.

tzaeschke · 2025-09-08T11:28:51Z

router/underlayproviders/afpacketudpip/mmsg.go

@@ -0,0 +1,114 @@
+// Copyright 2025 SCION Association


use SPDX header?

tzaeschke · 2025-09-08T11:29:19Z

router/underlayproviders/afpacketudpip/neighbors.go

@@ -0,0 +1,401 @@
+// Copyright 2025 SCION Association


use SPDX header?

tzaeschke · 2025-09-08T11:29:43Z

router/underlayproviders/afpacketudpip/neighbors.go

+	"github.com/scionproto/scion/router"
+)
+
+// ARP cache parameters. The longuish TTL is because I suspect that linux rate limits responses,


tzaeschke · 2025-09-08T11:32:23Z

router/underlayproviders/afpacketudpip/ptplink.go

@@ -0,0 +1,527 @@
+// Copyright 2025 SCION Association


use SPDX header?

tzaeschke · 2025-09-08T11:34:42Z

router/underlayproviders/afpacketudpip/udpconnection.go

@@ -0,0 +1,470 @@
+// Copyright 2025 SCION Association


use SPDX header?

Among which: added lint check for *either* license text or SPDX line in headers. Use the latter in all new files.

jiceathome · 2025-10-03T10:45:38Z

acceptance/router_benchmark/test.py

+# MAX_CPUS: the total number of cpus that the test will try to harness. The standard for this
+# test is 5: 2 for brload and 3 for the router. Any different number invalidates the performance
+# index (which will be reported as 0).
+MAX_CPUS = 5


Yeah, cpu is the term used by the data source: lscpu. What we are selecting is [v]cpus, not cores.

jiceathome · 2025-10-03T10:45:48Z

acceptance/router_benchmark/test.py

-    # _run(). As a result, running setup, run, at teardown separately is not possible for
-    # this test. May be it would be possible to reconstruct the map without actually setup the
-    # interfaces, assuming brload isn't being changed in-between.
+    # _run(). As a result, running setup, run, at teardown separately is difficult.


Indeed. FWIW, it is done. Updated.

jiceathome · 2025-10-03T10:46:00Z

acceptance/router_benchmark/brload/main.go

 	metricsBegin := begin.Unix()

 	numPkt := 0
+out:


It's not a bare goto; it is a label to dissambiguate a break statement. Two loops are nested and we need to break out of both.

jiceathome · 2025-10-03T10:46:07Z

acceptance/router_benchmark/brload/main.go

 		case outcome = <-listenerChan:
 			if outcome == 0 {
-				log.Error("Listener never saw a valid packet being forwarded")
+				log.Error("listener never saw a valid packet being forwarded")


for some reason, the dominant go convention is to never write errors as full sentences.

jiceathome · 2025-10-03T10:46:15Z

acceptance/router_benchmark/brload/mmsg.go

+
+	// If we're going to send, we need to make sure we're not receiving our own stuff. The default
+	// behaviour is less than clear. The loopback doesn't work with veth, but likely does with
+	// else.


jiceathome · 2025-10-03T10:46:21Z

acceptance/router_benchmark/brload/mmsg.go

+	for {
+		// This will hog a core (as far as the Go scheduler is concerned) for the duration of the
+		// call as the Go run-time has no idea that this is a blocking write. This is perfectly fine
+		// for our use case. This can be made non-blocking if that helps sending faster.


No you're not mixing things up. The if clause below is only useful if non-blocking is used. Otherwise, it does nothing and costs almost nothing. After experimenting with many, many variations, I found it convenient that I could switch to non-blocking mode by just changing the flag, but as of now, non-blocking brings no improvement.

jiceathome · 2025-10-03T10:46:28Z

private/underlay/ebpf/kfilter.c

+  __uint(max_entries, 64);
+} k_map_flt SEC(".maps");
+
+// The traffic that goes to the AF_PACKET socket, must not get to the regular kernel networking


jiceathome · 2025-10-03T10:46:36Z

private/underlay/ebpf/kfilter.c

+
+// The traffic that goes to the AF_PACKET socket, must not get to the regular kernel networking
+// stack; else it will expand resources processing it, generating ICMP responses AND sending them!
+// That is the purpose of this program.


jiceathome

Reviewable status: 71 of 101 files reviewed, 25 unresolved discussions (waiting on @jeltevanbommel, @JordiSubira, @marcfrei, @oncilla, @romshark, and @tzaeschke)

jiceathome · 2025-10-03T10:46:43Z

MODULE.bazel.lock

Yeah. For now that's the least bad solution. It's supposed to be in the repo to ensure the locking, but on the other hand it is updated automatically. It's all silly and nobody at bazel seems to know what the right thing to do is.

jiceathome · 2025-10-03T10:46:43Z

router/dataplane.go

+// BufHead returns a slice of bytes of the requested size borrowed from the head of the packet.
+// buffer. This space can be used safely by an underlay to store data on ingest and retrieve on
+// egress; should the same underlay perform both operations. The data is protected against
+// overwrites provided that n is included in the underlay's headroom requirements.


jiceathome · 2025-10-03T10:46:43Z

router/dataplane.go

 	dstIsLocal := (p.scionLayer.DstIA == p.d.localIA)
 	if p.ingressFromLink == 0 {
-		// Outbound
+		// In via internal or sibling (may only be outbound)


jiceathome · 2025-10-03T10:46:44Z

router/dataplane.go

 		// Note: SCMP error messages triggered by the sibling router may use paths that
 		// don't start with the first hop.
 		if p.path.IsFirstHop() && !srcIsLocal {
+			// How did it get here?


jiceathome · 2025-10-03T10:46:44Z

router/dataplane.go

-	}
-	return err
+	// We do not care if some BFD packets get bounced under high load. If it becomes a problem,
+	// the solution is do use BFD's demand-mode. To be considered in a future refactoring.


jiceathome · 2025-10-03T10:46:49Z

router/underlayproviders/afpacketudpip/neighbors.go

+	"github.com/scionproto/scion/router"
+)
+
+// ARP cache parameters. The longuish TTL is because I suspect that linux rate limits responses,


jiceathome · 2025-10-03T10:46:49Z

router/underlayproviders/afpacketudpip/ptplink.go

@@ -0,0 +1,527 @@
+// Copyright 2025 SCION Association


jiceathome · 2025-10-03T10:46:50Z

router/underlayproviders/afpacketudpip/udpconnection.go

@@ -0,0 +1,470 @@
+// Copyright 2025 SCION Association


jiceathome · 2025-10-03T10:46:50Z

private/underlay/ebpf/kfilter_lint.go

 import "github.com/cilium/ebpf"

-func loadPortfilter() (*ebpf.CollectionSpec, error) {
+func loadKfilter() (*ebpf.CollectionSpec, error) {


I tried and make the heading comments more explicit.

jiceathome · 2025-10-03T10:46:51Z

private/underlay/ebpf/sockfilter.c

+// traffic that we do want also gets to the kernel networking stack. Another
+// filter (kfilter.c) has to drop it.
+//
+// This is far from ideal because I have yet to find a way to dispatch traffic


Well... I think that this is as good as it gets unless we use an XDP socket, which is the focus of a subsequent development. I just wanted to address the possible objection and explain why it is not horrible either.

jiceathome

Reviewable status: 71 of 101 files reviewed, 25 unresolved discussions (waiting on @jeltevanbommel, @JordiSubira, @marcfrei, @oncilla, @romshark, and @tzaeschke)

jiceathome · 2025-10-03T10:46:54Z

MODULE.bazel.lock

Yeah. For now that's the least bad solution. It's supposed to be in the repo to ensure the locking, but on the other hand it is updated automatically. It's all silly and nobody at bazel seems to know what the right thing to do is.

jiceathome · 2025-10-03T10:46:55Z

router/dataplane.go

+// BufHead returns a slice of bytes of the requested size borrowed from the head of the packet.
+// buffer. This space can be used safely by an underlay to store data on ingest and retrieve on
+// egress; should the same underlay perform both operations. The data is protected against
+// overwrites provided that n is included in the underlay's headroom requirements.


jiceathome · 2025-10-03T10:46:55Z

router/dataplane.go

 	dstIsLocal := (p.scionLayer.DstIA == p.d.localIA)
 	if p.ingressFromLink == 0 {
-		// Outbound
+		// In via internal or sibling (may only be outbound)


jiceathome · 2025-10-03T10:46:55Z

router/dataplane.go

 		// Note: SCMP error messages triggered by the sibling router may use paths that
 		// don't start with the first hop.
 		if p.path.IsFirstHop() && !srcIsLocal {
+			// How did it get here?


jiceathome · 2025-10-03T10:46:56Z

router/dataplane.go

-	}
-	return err
+	// We do not care if some BFD packets get bounced under high load. If it becomes a problem,
+	// the solution is do use BFD's demand-mode. To be considered in a future refactoring.


jiceathome · 2025-10-03T10:46:59Z

router/underlayproviders/afpacketudpip/neighbors.go

+	"github.com/scionproto/scion/router"
+)
+
+// ARP cache parameters. The longuish TTL is because I suspect that linux rate limits responses,


jiceathome · 2025-10-03T10:46:59Z

router/underlayproviders/afpacketudpip/ptplink.go

@@ -0,0 +1,527 @@
+// Copyright 2025 SCION Association


jiceathome · 2025-10-03T10:46:59Z

router/underlayproviders/afpacketudpip/udpconnection.go

@@ -0,0 +1,470 @@
+// Copyright 2025 SCION Association


jiceathome · 2025-10-03T10:47:00Z

private/underlay/ebpf/kfilter_lint.go

 import "github.com/cilium/ebpf"

-func loadPortfilter() (*ebpf.CollectionSpec, error) {
+func loadKfilter() (*ebpf.CollectionSpec, error) {


I tried and make the heading comments more explicit.

jiceathome · 2025-10-03T10:47:00Z

private/underlay/ebpf/sockfilter.c

+// traffic that we do want also gets to the kernel networking stack. Another
+// filter (kfilter.c) has to drop it.
+//
+// This is far from ideal because I have yet to find a way to dispatch traffic


Well... I think that this is as good as it gets unless we use an XDP socket, which is the focus of a subsequent development. I just wanted to address the possible objection and explain why it is not horrible either.

katyatitkova · 2025-11-04T12:41:39Z

@tzaeschke @marcfrei @oncilla @JordiSubira @jeltevanbommel Any objections against merging?

tzaeschke · 2025-11-04T13:27:19Z

No objections, but I lack the technical understanding for this PR.

marcfrei · 2025-11-04T13:43:08Z

One of the goals of this PR was to "provide better (to some extent) performance for the udp/ip underlay with relatively low effort". Unfortunately, this turned out to require more effort than initially anticipated with a lot of changes (100 files, +4460 −616 lines). And as far as I know, we don't have benchmarks that show substantially better performance than the UDP/IP underlay. Given the scope of the changes, the question then is, whether we really want to take on the additional maintenance burden going forward. I'm hesitant, what do you think?

katyatitkova · 2025-11-04T14:19:36Z

And as far as I know, we don't have benchmarks that show substantially better performance than the UDP/IP underlay.

I wasn't deeply involved into benchmarking, but I hope I remember correctly. There were benchmarks that JC and Roman ran on our existing benchmarking machine and on AWS (I think with this code as well, not the master version - but I'm not sure), and the conclusion was that we're hitting the kernel's single-threaded limits on packets per second. So the way to improve it is to use kernel bypass techniques. Our existing setup is suboptimal for benchmarking, and we already have new hardware, just didn't have time to fully assemble it yet. Roman will continue with it when he's back from vacation. So let's see what the benchmarks will show then...

jiceathome · 2025-11-04T18:28:26Z

The benchmark that we use everyday does show a substantial improvement: about 50%. From ~10Gb/s to ~15Gb/s. What is not substantially improved is the benchmark we don’t run everyday, which is the same test but on non-virtual hardware. So, indeed, not everything we wanted, but some necessary bottleneck removal. Regarding the value of the work done towards the final objective (i.e. complete XDP support): 90%. That is: 90% of this PR would be needed for a full XDP underlay. Given an XDP underlay implementation, you could throw away the afp_packet underlay (thereby lessening the maintenance burden), but the new underlay would still inherit a lot of code from the afp one (all raw packet construction, ARP, V6 neighbor discovery, etc) and you would still need all the structural changes to enable underlay-specific addressing and multiple underlay configuration.I suggest speaking with Jelte to better undertand the value of some of these changes.So, I think it is actually wiser to retain this PR as a stepping stone, rather than continuing towards XDP without that checkpoint, which would lead to an even larger and more aging PR. My 2 Rappen.J-COn 4 Nov 2025, at 14:43, Marc Frei ***@***.***> wrote:marcfrei left a comment (scionproto/scion#4763) One of the goals of this PR was to "provide better (to some extent) performance for the udp/ip underlay with relatively low effort". Unfortunately, this turned out to require more effort than initially anticipated with a lot of changes (100 files, +4460 −616 lines). And as far as I know, we don't have benchmarks that show substantially better performance than the UDP/IP underlay. Given the scope of the changes, the question then is, whether we really want to take on the additional maintenance burden going forward. I'm hesitant, what do you think? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

marcfrei · 2025-11-05T07:36:48Z

Thanks for the clarification, J-C! Having this PR as a stepping stone towards an XDP underlay is perfectly fine with me if the delta is indeed only about 10% and Roman is able to leverage all this work. In the ideal case we would then end up with just the existing UDP/IP underlay and a second XDP-based underlay that replaces af_packet, derived from this PR?

jiceathome · 2025-11-05T08:57:59Z

Yeah, that would be the way to go. I don’t think there’d be much gain from keeping all 3. I don’t have the hardware to carry out the xdp development (and you’d want someone full-time on it anyway) but I’ll remain available to answer any questions regarding the underlays.J-COn 5 Nov 2025, at 09:49, Marc Frei ***@***.***> wrote:marcfrei left a comment (scionproto/scion#4763) Thanks for the clarification, J-C! Having this PR as a stepping stone towards an XDP underlay is perfectly fine with me if the delta is indeed only about 10% and Roman is able to leverage all this work. In the ideal case we would then end up with just the existing UDP/IP underlay and a second XDP-based underlay that replaces af_packet, derived from this PR? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

marcfrei · 2025-11-05T10:16:55Z

doc/manuals/common.rst

+         "protocol": "<udpip|other_underlay_protocol>"
         "local": "<ip|hostname>:<port>", # or just ":<port>"
-         "remote": "<ip|hostname:port>",
+         "remote": "<ip|hostname>:<port>",
+         "options": "<options>", # optional, defined by protocol


This would specify the inter-AS underlay protocol for the given interface/link, right? How is the intra-AS underlay protocol specified?

The change is also orthogonal to the af_packet implementation for the "udip" underlay. So maybe split it off into a separate PR?

marcfrei · 2025-11-05T10:22:35Z

doc/manuals/router.rst


+   .. object:: preferred_underlays
+
+      .. option:: udpip = <string>, default = "afpacket"


Keep "inet" as the default for now.

marcfrei · 2025-11-05T10:23:17Z

doc/manuals/router.rst

+         In the absence of ``preferred_underlays``, "afpacket" is preferred; falling back to
+         "inet".


marcfrei · 2025-11-05T10:38:12Z

router/config/config.go

 		cfg.BFD.RequiredMinRxInterval = util.DurWrap{Duration: 200 * time.Millisecond}
 	}
+	if cfg.PreferredUnderlays == nil {
+		cfg.PreferredUnderlays = map[string]string{"udpip": "afpacket"}


"inet", see above.

marcfrei · 2025-11-05T11:39:52Z

router/dataplane.go

+// overwrites provided that the value of n is counted in the underlay's headroom requirements.
+//
+// n is the size of the slice to be borrowed from the head of the packet buffer.
+func (p *Packet) BuffHead(n int) []byte {


'BufHead' in the doc string vs. 'BuffHead' in the method definition. I'd prefer 'HeadBytes'.

marcfrei · 2025-11-05T11:56:05Z

router/underlayproviders/udpip/udpip.go

 	}
 	// if port is outside the configured port range we send to the fixed port.
-	if port < l.dispatchStart && port > l.dispatchEnd {
+	if port < l.dispatchStart || port > l.dispatchEnd {


marcfrei · 2025-11-05T12:16:19Z

router/underlay.go

 	Resolve(p *Packet, dst addr.Host, port uint16) error
 	// Send queues the packet for sending over this link; discarding if the queue is full.
-	Send(p *Packet) bool
+	Send(p *Packet)


I was looking at the PacketPool management and it's quite subtle. On start, each underlay gets its own copy of a PacketPool struct, but all copies share the same underlying channel, making the pool actually shared. I think it would be more explicit and easier to understand if we passed a pointer to a PacketPool struct to the Underlay.Start method.

marcfrei · 2025-11-05T12:17:15Z

scion/ping/ping.go

Separate PR?

marcfrei · 2025-11-05T14:29:23Z

router/underlayproviders/afpacketudpip/dbg.go

Keep the functions in this file package private to reduce the overall API surface.

Checkpointing.

429e89f

jiceathome and others added 7 commits May 5, 2025 17:20

Merge branch 'master' into router_raw_socket2

bad6172

Checkpointing.

05bf0b7

Checkpoint.

0e75647

Checkpoint. Presumably code-complete for IPv4. Need to add IPv6 support.

532bbc1

Doesn't work yet.

Checkpoint.

a7f808f

Added another filter. Needed to ensure that the kernel does not do any processing on the packets received by the raw socket. Expensive stuff would otherwise result (e.g. icmp responses).

Removed leftover printks.

1a7216e

jiceathome changed the title ~~Checkpointing.~~ router: afpacket udp underlay (WIP) May 9, 2025

jiceathome and others added 20 commits May 9, 2025 18:31

Give required capability in the router's container. Enable afpacket u…

e6f1520

…nderlay.

Merge branch 'master' into router_raw_socket2

bb0c07e

Restored ability to run router_benchmark in three steps (setup/run/te…

515522a

…ardown).

Minor cleanup

7fd83d9

Comments, debug stmt and useless error return.

Fix assorted trivial bugs.

99dc941

Now passes the benchmark.

Lintify etc.

05a1cc7

Clarify role of the Priority() method of the Underlay interface.

b2834e7

Trigger new build from scratch

14ef830

Delete dummy comment

2665de6

Merge branch 'master' into router_raw_socket2

1e779ba

Make test portfiter test a native_test.

7d70a22

Not quite sure what difference it makes, but it sure isn't an sh_test.

Lintify etc.

1f344c3

Attempt to work around new buildkite issue of unsifficient disk cleanup.

bc49771

Fix bug in WithHeader. Was making all output packets 8K long.

a6f85b2

In passing added some facility for short debug runs.

Increase the router benchmark's packet blaster's batch size.

37dfdbc

This is a feable attempt at making it at least slightly faster than the router.

For now be less demanding interms of router saturation.

3f4da2e

We used to require more than 3% packet drop. We are now content with 3% or more.

Add ipv6 support to the afpudpip underlay.

2b5e781

Had to rearrange the code a tiny bit. In passing, attempting to add the needed capabilities to the router in integration tests besides the router benchmark.

Missing space.

ef87482

Cleanup. Split the afp underlay in 4.

4cdefda

In passing. Fixed another missing space in router_multi test script.

Added ARP support.

efea026

In passing, further simplified the process of making debug runs of the router benchmark.

jiceathome and others added 3 commits July 31, 2025 18:11

Clear the UDP checksum *before* sending the first packet.

8d632c1

Remove the need to allocate src addresses in the afpacket underlay.

b433b38

The underlay shouldn't be producing any garbage any more. Src addresses get stored at the head of the packet buffer.

Merge branch 'master' into router_raw_socket2

2587025

jiceathome commented Aug 23, 2025

View reviewed changes

Implement reviewers suggestion of additional link options.

b4cacff

Implemented it very minimally, though: one arbitrary options string.

tzaeschke reviewed Sep 8, 2025

View reviewed changes

Address reviewer's comments.

ed4096f

Among which: added lint check for *either* license text or SPDX line in headers. Use the latter in all new files.

jiceathome commented Oct 3, 2025

View reviewed changes

jiceathome and others added 2 commits October 3, 2025 12:50

Merge branch 'master' into router_raw_socket2

cc838cb

Merge branch 'master' into router_raw_socket2

a9ec125

katyatitkova self-requested a review November 4, 2025 12:11

katyatitkova approved these changes Nov 4, 2025

View reviewed changes

marcfrei reviewed Nov 5, 2025

View reviewed changes

router/underlayproviders/afpacketudpip/dbg.go

Copy link

Contributor

marcfrei Nov 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep the functions in this file package private to reduce the overall API surface.


		.. object:: preferred_underlays

		.. option:: udpip = <string>, default = "afpacket"

		In the absence of ``preferred_underlays``, "afpacket" is preferred; falling back to
		"inet".

router: afpacket udp underlay #4763

Are you sure you want to change the base?

router: afpacket udp underlay #4763

Uh oh!

Conversation

jiceathome commented May 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jiceathome commented May 5, 2025

Uh oh!

jiceathome left a comment

Choose a reason for hiding this comment

Uh oh!

tzaeschke left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jiceathome commented May 5, 2025 •

edited

Loading