Thanks for the valuable thoughts, Toke.

The patch started with me being tasked to try and mitigate timing attacks caused by network latencies.
I scouted over the current network stack and didn't find anything that fully matched my use-case.
While I now understand that you can actually leverage the slots functionality for this, I would still opt for a new interface and implementation.

I have not done any CPU benchmarks on the slots system, so I'm not approaching this from the practical performance side per se.
Instead, I argue for seperation with reference to the Seperation of Concern design principle. The slots functionality is not built/designed to cater security guarantees, and my patch is not built to cater duty cycles, etc.
If we opt to merge these two functionalities or discard mine, we have to implement some guarantee that the slots functionality won't become significantly slower or complex, which in my opinion is less maintainable than two similar systems. Also, this patch is very limited in lines of code, so maintaining it is pretty trivial.

I do agree, however, that we should define what would happen if you enable both systems at the same time.

@Dave: Any thoughts on this?

On 28 Jun 2021, at 14:21, Toke Høiland-Jørgensen [off-list ref] wrote:

Niclas Hedam [off-list ref] writes:

quoted

quoted

quoted

From 71843907bdb9cdc4e24358f0c16a8778f2762dc7 Mon Sep 17 00:00:00 2001
From: Niclas Hedam <redacted>
Date: Fri, 25 Jun 2021 13:37:18 +0200
Subject: [PATCH] net: sched: Add support for packet bursting.

Something went wrong with the formatting here.

I'll resubmit with fixed formatting. My bad.

quoted

quoted

This commit implements packet bursting in the NetEm scheduler.
This allows system administrators to hold back outgoing
packets and release them at a multiple of a time quantum.
This feature can be used to prevent timing attacks caused
by network latency.

How is this bursting feature different from the existing slot-based
mechanism?

It is similar, but the reason for separating it is the audience that they are catering.
The slots seems to be focused on networking constraints and duty cycles.
My contribution and mechanism is mitigating timing attacks. The
complexity of slots are mostly unwanted in this context as we want as
few CPU cycles as possible.

(Adding Dave who wrote the slots code)

But you're still duplicating functionality, then? This has a cost in
terms of maintainability and interactions (what happens if someone turns
on both slots and bursting, for instance)?

If the concern is CPU cost (got benchmarks to back that up?), why not
improve the existing mechanism so it can be used for your use case as
well?

-Toke