lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 21 Mar 2018 17:30:23 -0300
From:   Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Randy Dunlap <rdunlap@...radead.org>,
        Tal Gilboa <talgi@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Tariq Toukan <tariqt@...lanox.com>
Subject: Re: [PATCH net-next V2] Documentation/networking: Add net DIM
 documentation

On Wed, Mar 21, 2018 at 12:44:29PM -0700, Florian Fainelli wrote:
> On 03/21/2018 12:37 PM, Randy Dunlap wrote:
> > On 03/21/2018 11:33 AM, Tal Gilboa wrote:
> >> Net DIM is a generic algorithm, purposed for dynamically
> >> optimizing network devices interrupt moderation. This
> >> document describes how it works and how to use it.
> >>
> >> Signed-off-by: Tal Gilboa <talgi@...lanox.com>
> >> ---
> >>  Documentation/networking/net_dim.txt | 174 +++++++++++++++++++++++++++++++++++
> >>  1 file changed, 174 insertions(+)
> >>  create mode 100644 Documentation/networking/net_dim.txt
> >>
> >> diff --git a/Documentation/networking/net_dim.txt b/Documentation/networking/net_dim.txt
> >> new file mode 100644
> >> index 0000000..9cb31c5
> >> --- /dev/null
> >> +++ b/Documentation/networking/net_dim.txt
> >> @@ -0,0 +1,174 @@
> >> +Net DIM - Generic Network Dynamic Interrupt Moderation
> >> +======================================================
> >> +
> >> +Author:
> >> +	Tal Gilboa <talgi@...lanox.com>
> >> +
> >> +
> >> +Contents
> >> +=========
> >> +
> >> +- Assumptions
> >> +- Introduction
> >> +- The Net DIM Algorithm
> >> +- Registering a Network Device to DIM
> >> +- Example
> >> +
> >> +Part 0: Assumptions
> >> +======================
> >> +
> >> +This document assumes the reader has basic knowledge in network drivers
> >> +and in general interrupt moderation.
> >> +
> >> +
> >> +Part I: Introduction
> >> +======================
> >> +
> >> +Dynamic Interrupt Moderation (DIM) (in networking) refers to changing the
> >> +interrupt moderation configuration of a channel in order to optimize packet
> >> +processing. The mechanism includes an algorithm which decides if and how to
> >> +change moderation parameters for a channel, usually by performing an analysis on
> >> +runtime data sampled from the system. Net DIM is such a mechanism. In each
> >> +iteration of the algorithm, it analyses a given sample of the data, compares it
> >> +to the previous sample and if required, it can decide to change some of the
> >> +interrupt moderation configuration fields. The data sample is composed of data
> >> +bandwidth, the number of packets and the number of events. The time between
> >> +samples is also measured. Net DIM compares the current and the previous data and
> >> +returns an adjusted interrupt moderation configuration object. In some cases,
> >> +the algorithm might decide not to change anything. The configuration fields are
> >> +the minimum duration (microseconds) allowed between events and the maximum
> >> +number of wanted packets per event. The Net DIM algorithm ascribes importance to
> >> +increase bandwidth over reducing interrupt rate.
> >> +
> >> +
> >> +Part II: The Net DIM Algorithm
> >> +===============================
> >> +
> >> +Each iteration of the Net DIM algorithm follows these steps:
> >> +1. Calculates new data sample.
> >> +2. Compares it to previous sample.
> >> +3. Makes a decision - suggests interrupt moderation configuration fields.
> >> +4. Applies a schedule work function, which applies suggested configuration.
> >> +
> >> +The first two steps are straightforward, both the new and the previous data are
> >> +supplied by the driver registered to Net DIM. The previous data is the new data
> >> +supplied to the previous iteration. The comparison step checks the difference
> >> +between the new and previous data and decides on the result of the last step.
> >> +A step would result as "better" if bandwidth increases and as "worse" if
> >> +bandwidth reduces. If there is no change in bandwidth, the packet rate is
> >> +compared in a similar fashion - increase == "better" and decrease == "worse".
> >> +In case there is no change in the packet rate as well, the interrupt rate is
> >> +compared. Here the algorithm tries to optimize for lower interrupt rate so an
> >> +increase in the interrupt rate is considered "worse" and a decrease is
> >> +considered "better". Step #2 has an optimization for avoiding false results: it
> >> +only considers a difference between samples as valid if it is greater than a
> >> +certain percentage. Also, since Net DIM does not measure anything by itself, it
> >> +assumes the data provided by the driver is valid.
> >> +
> >> +Step #3 decides on the suggested configuration based on the result from step #2
> >> +and the internal state of the algorithm. The states reflect the "direction" of
> >> +the algorithm: is it going left (reducing moderation), right (increasing
> >> +moderation) or standing still. Another optimization is that if a decision
> >> +to stay still is made multiple times, the interval between iterations of the
> >> +algorithm would increase in order to reduce calculation overhead. Also, after
> >> +"parking" on one of the most left or most right decisions, the algorithm may
> >> +decide to verify this decision by taking a step in the other direction. This is
> >> +done in order to avoid getting stuck in a "deep sleep" scenario. Once a
> >> +decision is made, an interrupt moderation configuration is selected from
> >> +the predefined profiles.
> > 
> > I think a short description of the predefined profiles could help.
> 
> Agreed it would help if the different modes
> (NET_DIM_CQ_PERIOD_MODE_START_FROM_EQE,
> NET_DIM_CQ_PERIOD_MODE_START_FROM_CQE) were expanded a bit further. The

Speaking of these, I just had to edit the email and adjust the
alignment to notice the single letter difference between both out of
36 chars.

NET_DIM_CQ_PERIOD_MODE_START_FROM_EQE
NET_DIM_CQ_PERIOD_MODE_START_FROM_CQE

Would be nice if the readability could be improved somehow.

> whole term QE sounds very much Ethernet converged adapter to me...
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ