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
From: Edward Cree
Date: Fri, 13 Apr 2018 16:59:07 +0100
> On 13/04/18 16:03, David Miller wrote:
>> Whilst you may not be able to program the filter into the hardware
>> synchronously, you should be able to allocate the ID and get all of
>> the software state setup.
> That's what we were doing be
On 13/04/18 16:03, David Miller wrote:
> Whilst you may not be able to program the filter into the hardware
> synchronously, you should be able to allocate the ID and get all of
> the software state setup.
That's what we were doing before commit 3af0f34290f6 ("sfc: replace
asynchronous filter oper
From: Edward Cree
Date: Fri, 13 Apr 2018 15:52:25 +0100
> On 13/04/18 15:45, David Miller wrote:
>> I understand the constraints you are working under, but do realize
>> that the real root of the problems is that you are implementing what
>> is defined clearly as a synchronous operation as asynch
On 13/04/18 13:36, Edward Cree wrote:
> It turns out this may all be moot anyway: I figured out why I was seeing
> ARFS storms and it wasn't the configuration issue I originally blamed.
Hmm, correction, while the fix I mentioned in my previous email is needed,
it doesn't prevent the ARFS storms (
From: Edward Cree
Date: Fri, 13 Apr 2018 13:36:28 +0100
> It turns out this may all be moot anyway: I figured out why I was seeing
> ARFS storms and it wasn't the configuration issue I originally blamed.
> My current ndo_rx_flow_steer() implementation, efx_filter_rfs(), returns
> 0 for success,
It turns out this may all be moot anyway: I figured out why I was seeing
ARFS storms and it wasn't the configuration issue I originally blamed.
My current ndo_rx_flow_steer() implementation, efx_filter_rfs(), returns
0 for success, but the caller expects a filter ID to be returned (which
we can'
From: Edward Cree
Date: Thu, 12 Apr 2018 16:24:46 +0100
> This code is not handling expiration of old ARFS filters, it's inserting
> new ones.
Then simply make the work process a queue, and add entries to the queue
here if the work is already scheduled.
Is there a reason why that wouldn't work
On 12/04/18 16:11, David Miller wrote:
> 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 bac
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 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
11 matches
Mail list logo
