From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net-next 00/14] gred: add offload support Date: Mon, 19 Nov 2018 18:54:06 -0800 (PST) Message-ID: <20181119.185406.416570201079064911.davem@davemloft.net> References: <20181119232150.13038-1-jakub.kicinski@netronome.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: oss-drivers@netronome.com, netdev@vger.kernel.org To: jakub.kicinski@netronome.com Return-path: Received: from shards.monkeyblade.net ([23.128.96.9]:57202 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730134AbeKTNU5 (ORCPT ); Tue, 20 Nov 2018 08:20:57 -0500 In-Reply-To: <20181119232150.13038-1-jakub.kicinski@netronome.com> Sender: netdev-owner@vger.kernel.org List-ID: From: Jakub Kicinski 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.