From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel Date: Thu, 12 Apr 2018 11:11:32 -0400 (EDT) Message-ID: <20180412.111132.159310781108534969.davem@davemloft.net> References: <1713aaa9-2803-0d3b-127a-5240876da7b1@solarflare.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: linux-net-drivers@solarflare.com, netdev@vger.kernel.org To: ecree@solarflare.com Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:41634 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753680AbeDLPLh (ORCPT ); Thu, 12 Apr 2018 11:11:37 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: From: Edward Cree Date: Thu, 12 Apr 2018 15:02:50 +0100 > A misconfigured system (e.g. with all interrupts affinitised to all CPUs) > may produce a storm of ARFS steering events. With the existing sfc ARFS > implementation, that could create a backlog of workitems that grinds the > system to a halt. To prevent this, limit the number of workitems that > may be in flight for a given SFC device to 8 (EFX_RPS_MAX_IN_FLIGHT), and > return EBUSY from our ndo_rx_flow_steer method if the limit is reached. > Given this limit, also store the workitems in an array of slots within the > struct efx_nic, rather than dynamically allocating for each request. > > Signed-off-by: Edward Cree I don't think this behavior is all that great. If you really have to queue up these operations because they take a long time, I think it is better to enter a synchronous mode and sleep once you hit this in-flight limit of 8. Either that or make the expiration work smarter when it has lots of events to process.