From mboxrd@z Thu Jan  1 00:00:00 1970
From: Edward Cree <ecree@solarflare.com>
Subject: Re: [PATCH net 2/2] sfc: limit ARFS workitems in flight per channel
Date: Fri, 13 Apr 2018 17:24:10 +0100
Message-ID: <b8d75e21-09ab-7e16-5ce1-5cb858a1203b@solarflare.com>
References: <c7a994ee-763c-1f94-2c1e-4348d7b4cc62@solarflare.com>
 <20180413.110359.1956367740053085545.davem@davemloft.net>
 <d56e5a40-48cc-d984-c5cd-e18fbc411ed3@solarflare.com>
 <20180413.121415.787716401343641542.davem@davemloft.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Cc: <linux-net-drivers@solarflare.com>, <netdev@vger.kernel.org>
To: David Miller <davem@davemloft.net>
Return-path: <netdev-owner@vger.kernel.org>
Received: from dispatch1-us1.ppe-hosted.com ([67.231.154.164]:33396 "EHLO
        dispatch1-us1.ppe-hosted.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1750928AbeDMQY1 (ORCPT
        <rfc822;netdev@vger.kernel.org>); Fri, 13 Apr 2018 12:24:27 -0400
In-Reply-To: <20180413.121415.787716401343641542.davem@davemloft.net>
Content-Language: en-GB
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On 13/04/18 17:14, David Miller wrote:
> Is the issue that you learn about the hardware reset asynchronously,
> and therefore cannot determine if filter insertion programming
> happened afterwards and thus is still in the chip?
Yes, pretty much.

> You must have a table of all the entries, so that you can reprogram
> the hardware should it reset.
Yes, we do have such a table; 'reprogram the hardware' happens in
 efx_ef10_filter_table_restore().

> Understood, thanks for explaining.
>
> Please respin your series with the updates you talked about and I'll
> apply it.
Will do, thanks.

-Ed