From: Nicolas Schichan
Date: Tue, 3 Mar 2015 12:45:12 +0100
> In case there was some tx buffer reclaimed and not enough rx packets
> to consume the whole budget, napi_complete would not be called and
> interrupts would be kept disabled, effectively resulting in the
> network core never to call
From: Nicolas Schichan nschic...@freebox.fr
Date: Tue, 3 Mar 2015 12:45:12 +0100
In case there was some tx buffer reclaimed and not enough rx packets
to consume the whole budget, napi_complete would not be called and
interrupts would be kept disabled, effectively resulting in the
network
On 03.03.2015 18:42, Florian Fainelli wrote:
> On 03/03/15 05:53, Nicolas Schichan wrote:
>> On 03/03/2015 02:42 PM, Eric Dumazet wrote:
To avoid that, I would take priv->tx_lock only once, or add a limit on
the number of skbs that can be drained per round.
>>>
>>> Something like this
From: Nicolas Schichan
Date: Tue, 03 Mar 2015 12:18:29 +0100
> I took inspiration from the mv643xx_eth driver which seems to
> account the tx buffer reclaim in the work done in its poll callback.
It also should be fixed to not do so.
--
To unsubscribe from this list: send the line "unsubscribe
On 03/03/15 05:53, Nicolas Schichan wrote:
> On 03/03/2015 02:42 PM, Eric Dumazet wrote:
>>> To avoid that, I would take priv->tx_lock only once, or add a limit on
>>> the number of skbs that can be drained per round.
>>
>> Something like this (untested) patch
>
> I'm not against testing this
On Tue, 2015-03-03 at 08:09 -0800, Alexander Duyck wrote:
> This rmb() can probably be replaced with a dma_rmb() since it is just a
> coherent/coherent ordering you are concerned with based on the comment.
Right, but this patch would be a stable candidate, where dma_rmb() does
not exist yet.
On 03/03/2015 05:42 AM, Eric Dumazet wrote:
On Tue, 2015-03-03 at 05:29 -0800, Eric Dumazet wrote:
On Tue, 2015-03-03 at 12:45 +0100, Nicolas Schichan wrote:
In case there was some tx buffer reclaimed and not enough rx packets
to consume the whole budget, napi_complete would not be called and
On 03/03/2015 03:18 PM, Eric Dumazet wrote:
> On Tue, 2015-03-03 at 14:53 +0100, Nicolas Schichan wrote:
>> On 03/03/2015 02:42 PM, Eric Dumazet wrote:
To avoid that, I would take priv->tx_lock only once, or add a limit on
the number of skbs that can be drained per round.
>>>
>>>
On Tue, 2015-03-03 at 14:53 +0100, Nicolas Schichan wrote:
> On 03/03/2015 02:42 PM, Eric Dumazet wrote:
> >> To avoid that, I would take priv->tx_lock only once, or add a limit on
> >> the number of skbs that can be drained per round.
> >
> > Something like this (untested) patch
>
> I'm not
On 03/03/2015 02:42 PM, Eric Dumazet wrote:
>> To avoid that, I would take priv->tx_lock only once, or add a limit on
>> the number of skbs that can be drained per round.
>
> Something like this (untested) patch
I'm not against testing this patch, but we do not have any SMP capable bcm63xx
board
On Tue, 2015-03-03 at 05:29 -0800, Eric Dumazet wrote:
> On Tue, 2015-03-03 at 12:45 +0100, Nicolas Schichan wrote:
> > In case there was some tx buffer reclaimed and not enough rx packets
> > to consume the whole budget, napi_complete would not be called and
> > interrupts would be kept disabled,
On Tue, 2015-03-03 at 12:45 +0100, Nicolas Schichan wrote:
> In case there was some tx buffer reclaimed and not enough rx packets
> to consume the whole budget, napi_complete would not be called and
> interrupts would be kept disabled, effectively resulting in the
> network core never to call the
In case there was some tx buffer reclaimed and not enough rx packets
to consume the whole budget, napi_complete would not be called and
interrupts would be kept disabled, effectively resulting in the
network core never to call the poll callback again and no rx/tx
interrupts to be fired either.
On 03/03/2015 04:15 AM, David Miller wrote:
> First, no signoff, that is required for your patch.
Hello David,
I realized that I had forgotten the signoff-by line too late unfortunately.
> Secondly, we strongly recommend that TX buffer reclaim be not
> accounted at all in the poll budget.
>
On Tue, 2015-03-03 at 08:09 -0800, Alexander Duyck wrote:
This rmb() can probably be replaced with a dma_rmb() since it is just a
coherent/coherent ordering you are concerned with based on the comment.
Right, but this patch would be a stable candidate, where dma_rmb() does
not exist yet.
On 03/03/2015 05:42 AM, Eric Dumazet wrote:
On Tue, 2015-03-03 at 05:29 -0800, Eric Dumazet wrote:
On Tue, 2015-03-03 at 12:45 +0100, Nicolas Schichan wrote:
In case there was some tx buffer reclaimed and not enough rx packets
to consume the whole budget, napi_complete would not be called and
On Tue, 2015-03-03 at 12:45 +0100, Nicolas Schichan wrote:
In case there was some tx buffer reclaimed and not enough rx packets
to consume the whole budget, napi_complete would not be called and
interrupts would be kept disabled, effectively resulting in the
network core never to call the poll
On Tue, 2015-03-03 at 05:29 -0800, Eric Dumazet wrote:
On Tue, 2015-03-03 at 12:45 +0100, Nicolas Schichan wrote:
In case there was some tx buffer reclaimed and not enough rx packets
to consume the whole budget, napi_complete would not be called and
interrupts would be kept disabled,
From: Nicolas Schichan nschic...@freebox.fr
Date: Tue, 03 Mar 2015 12:18:29 +0100
I took inspiration from the mv643xx_eth driver which seems to
account the tx buffer reclaim in the work done in its poll callback.
It also should be fixed to not do so.
--
To unsubscribe from this list: send the
On 03.03.2015 18:42, Florian Fainelli wrote:
On 03/03/15 05:53, Nicolas Schichan wrote:
On 03/03/2015 02:42 PM, Eric Dumazet wrote:
To avoid that, I would take priv-tx_lock only once, or add a limit on
the number of skbs that can be drained per round.
Something like this (untested) patch
On 03/03/15 05:53, Nicolas Schichan wrote:
On 03/03/2015 02:42 PM, Eric Dumazet wrote:
To avoid that, I would take priv-tx_lock only once, or add a limit on
the number of skbs that can be drained per round.
Something like this (untested) patch
I'm not against testing this patch, but we do
On 03/03/2015 02:42 PM, Eric Dumazet wrote:
To avoid that, I would take priv-tx_lock only once, or add a limit on
the number of skbs that can be drained per round.
Something like this (untested) patch
I'm not against testing this patch, but we do not have any SMP capable bcm63xx
board here
On Tue, 2015-03-03 at 14:53 +0100, Nicolas Schichan wrote:
On 03/03/2015 02:42 PM, Eric Dumazet wrote:
To avoid that, I would take priv-tx_lock only once, or add a limit on
the number of skbs that can be drained per round.
Something like this (untested) patch
I'm not against testing
In case there was some tx buffer reclaimed and not enough rx packets
to consume the whole budget, napi_complete would not be called and
interrupts would be kept disabled, effectively resulting in the
network core never to call the poll callback again and no rx/tx
interrupts to be fired either.
On 03/03/2015 04:15 AM, David Miller wrote:
First, no signoff, that is required for your patch.
Hello David,
I realized that I had forgotten the signoff-by line too late unfortunately.
Secondly, we strongly recommend that TX buffer reclaim be not
accounted at all in the poll budget.
On 03/03/2015 03:18 PM, Eric Dumazet wrote:
On Tue, 2015-03-03 at 14:53 +0100, Nicolas Schichan wrote:
On 03/03/2015 02:42 PM, Eric Dumazet wrote:
To avoid that, I would take priv-tx_lock only once, or add a limit on
the number of skbs that can be drained per round.
Something like this
From: Nicolas Schichan
Date: Mon, 2 Mar 2015 18:28:10 +0100
> In case there was some tx buffer reclaimed and not enough rx packets
> to consume the whole budget, napi_complete would not be called and
> interrupts would be kept disabled, effectively resulting in the
> network core never to call
In case there was some tx buffer reclaimed and not enough rx packets
to consume the whole budget, napi_complete would not be called and
interrupts would be kept disabled, effectively resulting in the
network core never to call the poll callback again and no rx/tx
interrupts to be fired either.
From: Nicolas Schichan nschic...@freebox.fr
Date: Mon, 2 Mar 2015 18:28:10 +0100
In case there was some tx buffer reclaimed and not enough rx packets
to consume the whole budget, napi_complete would not be called and
interrupts would be kept disabled, effectively resulting in the
network
In case there was some tx buffer reclaimed and not enough rx packets
to consume the whole budget, napi_complete would not be called and
interrupts would be kept disabled, effectively resulting in the
network core never to call the poll callback again and no rx/tx
interrupts to be fired either.
30 matches
Mail list logo
