[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wnqeji2n.fsf@toke.dk>
Date: Mon, 28 Jun 2021 14:21:20 +0200
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Niclas Hedam <nhed@....dk>
Cc: "stephen@...workplumber.org" <stephen@...workplumber.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Dave Taht <dave.taht@...il.com>
Subject: Re: [PATCH v2] net: sched: Add support for packet bursting.
Niclas Hedam <nhed@....dk> writes:
>>> From 71843907bdb9cdc4e24358f0c16a8778f2762dc7 Mon Sep 17 00:00:00 2001
>>> From: Niclas Hedam <nhed@....dk>
>>> 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.
>
>>>
>>> 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
Powered by blists - more mailing lists