netdev - Re: [net-next 01/12] net/mlx5: E-Switch, add ingress rate support

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]

Message-ID: <b2c77010e96b5fdb6693e5cf0a46a2017f389b44.camel@mellanox.com>
Date:   Fri, 2 Aug 2019 19:22:21 +0000
From:   Saeed Mahameed <saeedm@...lanox.com>
To:     "alexei.starovoitov@...il.com" <alexei.starovoitov@...il.com>
CC:     Eli Cohen <eli@...lanox.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Paul Blakey <paulb@...lanox.com>
Subject: Re: [net-next 01/12] net/mlx5: E-Switch, add ingress rate support

On Fri, 2019-08-02 at 10:37 -0700, Alexei Starovoitov wrote:
> On Thu, Aug 1, 2019 at 6:30 PM Saeed Mahameed <saeedm@...lanox.com>
> wrote:
> > From: Eli Cohen <eli@...lanox.com>
> > 
> > Use the scheduling elements to implement ingress rate limiter on an
> > eswitch ports ingress traffic. Since the ingress of eswitch port is
> > the
> > egress of VF port, we control eswitch ingress by controlling VF
> > egress.
> 
> Looks like the patch is only passing args to firmware which is doing
> the magic.
> Can you please describe what is the algorithm there?
> Is it configurable?

Hi Alexei, 

I am not sure how much details you are looking for, but let me share
some of what i know:

From a previous submission for legacy mode sriov vf bw limit, where we 
introduced the FW configuration API and the legacy sriov use case: 
https://patchwork.kernel.org/patch/9404655/

So basically the algorithm is Deficit Weighted Round Robin (DWRR)
between the agents, we can control BW allocation/weight of each agent
(vf vport).

Quoting the commit message from the above link:

"The TSAR implements a Deficit Weighted Round Robin (DWRR) between the
agents. Each agent attached to the TSAR is assigned with a Weight. An
agent is awarded with transmission tokens according to its Weight, and
charged with transmission Tokens according to the amount of data it has
transmitted. Effectively, the Weight (relative to the other agents’
Weight) defines the percentage of the BW an agent will receive,
assuming it has enough data to sustain this BW.

This arbitration scheme is work-preserving, meaning that an agent not
using the entire BW it was allocated, hands over the excess BW, to be
redistributed among the other agents. Each agent will receive
additional BW according to its Weight."

Thanks,
Saeed.