netdev - Re: [PATCH net-next 00/14] gred: add offload 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] [day] [month] [year] [list]

Message-Id: <20181119.185406.416570201079064911.davem@davemloft.net>
Date:   Mon, 19 Nov 2018 18:54:06 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     jakub.kicinski@...ronome.com
Cc:     oss-drivers@...ronome.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 00/14] gred: add offload support

From: Jakub Kicinski <jakub.kicinski@...ronome.com>
Date: Mon, 19 Nov 2018 15:21:36 -0800

> This series adds support for GRED offload in the nfp driver.  So
> far we have only supported the RED Qdisc offload, but we need a
> way to differentiate traffic types e.g. based on DSCP marking.
> 
> It may seem like PRIO+RED is a good match for this job, however,
> (a) we don't need strict priority behaviour of PRIO, and (b) PRIO
> uses the legacy way of mapping ToS fields to bands, which is quite
> awkward and limitting.
> 
> The less commonly used GRED Qdisc is a better much for the scenario,
> it allows multiple sets of RED parameters and queue lengths to be
> maintained with a single FIFO queue.  This is exactly how nfp offload
> behaves.  We use a trivial u32 classifier to assign packets to virtual
> queues.
> 
> There is also the minor advantage that GRED can't have its child
> changed, therefore limitting ways in which the configuration of SW
> path can diverge from HW offload.
> 
> Last patch of the series adds support for (G)RED in non-ECN mode,
> where packets are dropped instead of marked.

Series applied, thanks Jakub.