All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Niclas Hedam <nhed@itu.dk>
Cc: "stephen@networkplumber.org" <stephen@networkplumber.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Dave Taht <dave.taht@gmail.com>
Subject: Re: [PATCH v2] net: sched: Add support for packet bursting.
Date: Mon, 28 Jun 2021 14:21:20 +0200	[thread overview]
Message-ID: <87wnqeji2n.fsf@toke.dk> (raw)
In-Reply-To: <B28935AB-6078-4258-8E7C-14E11D1AD57F@itu.dk>

Niclas Hedam <nhed@itu.dk> writes:

>>> From 71843907bdb9cdc4e24358f0c16a8778f2762dc7 Mon Sep 17 00:00:00 2001
>>> From: Niclas Hedam <nhed@itu.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


  reply	other threads:[~2021-06-28 12:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28 11:25 [PATCH v2] net: sched: Add support for packet bursting Niclas Hedam
2021-06-28 11:44 ` Toke Høiland-Jørgensen
2021-06-28 11:57   ` Niclas Hedam
2021-06-28 12:21     ` Toke Høiland-Jørgensen [this message]
2021-06-28 13:24       ` Niclas Hedam
2021-06-29 14:35         ` Toke Høiland-Jørgensen
2021-06-29 15:26         ` Dave Taht
2021-06-28 12:08   ` [PATCH v3] " Niclas Hedam
2021-06-28 15:27     ` Eric Dumazet
2021-06-28 15:38       ` Niclas Hedam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wnqeji2n.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=dave.taht@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhed@itu.dk \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.