[PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[Vineeth Remanan Pillai]

From: Vineeth Remanan Pillai <vineethp@amazon.com>

During an OOM scenario, request slots could not be created as skb
allocation fails. So the netback cannot pass in packets and netfront
wrongly assumes that there is no more work to be done and it disables
polling. This causes Rx to stall.

The issue is with the retry logic which schedules the timer if the
created slots are less than NET_RX_SLOTS_MIN. The count of new request
slots to be pushed are calculated as a difference between new req_prod
and rsp_cons which could be more than the actual slots, if there are
unconsumed responses.

The fix is to calculate the count of newly created slots as the
difference between new req_prod and old req_prod.

Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
Changes in v2:
	- Removed the old implementation of enabling polling on
	  skb allocation error.
	- Corrected the refill timer logic to schedule when newly
	  created slots since last push is less than NET_RX_SLOTS_MIN.

  drivers/net/xen-netfront.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 40f26b6..2c7c29f 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -321,7 +321,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
  	queue->rx.req_prod_pvt = req_prod;
  
  	/* Not enough requests? Try again later. */
-	if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
+	if (req_prod - queue->rx.sring->req_prod < NET_RX_SLOTS_MIN) {
  		mod_timer(&queue->rx_refill_timer, jiffies + (HZ/10));
  		return;
  	}
-- 
2.7.4

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[David Miller]

From: Vineeth Remanan Pillai <vineethp@amazon.com>
Date: Thu, 19 Jan 2017 08:35:39 -0800

> From: Vineeth Remanan Pillai <vineethp@amazon.com>
> 
> During an OOM scenario, request slots could not be created as skb
> allocation fails. So the netback cannot pass in packets and netfront
> wrongly assumes that there is no more work to be done and it disables
> polling. This causes Rx to stall.
> 
> The issue is with the retry logic which schedules the timer if the
> created slots are less than NET_RX_SLOTS_MIN. The count of new request
> slots to be pushed are calculated as a difference between new req_prod
> and rsp_cons which could be more than the actual slots, if there are
> unconsumed responses.
> 
> The fix is to calculate the count of newly created slots as the
> difference between new req_prod and old req_prod.
> 
> Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
> Reviewed-by: Juergen Gross <jgross@suse.com>
> ---
> Changes in v2:
> 	- Removed the old implementation of enabling polling on
> 	  skb allocation error.
> 	- Corrected the refill timer logic to schedule when newly
> 	  created slots since last push is less than NET_RX_SLOTS_MIN.

Your postings aren't showing up on vger.kernel.org at all.

Are you getting a bounce message back?  I can only assume you are triggering
one of the various content filters we have.

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[Vineeth Remanan Pillai]

On 01/19/2017 09:11 AM, David Miller wrote:
> From: Vineeth Remanan Pillai <vineethp@amazon.com>
> Date: Thu, 19 Jan 2017 08:35:39 -0800
>
>> From: Vineeth Remanan Pillai <vineethp@amazon.com>
>>
>> During an OOM scenario, request slots could not be created as skb
>> allocation fails. So the netback cannot pass in packets and netfront
>> wrongly assumes that there is no more work to be done and it disables
>> polling. This causes Rx to stall.
>>
>> The issue is with the retry logic which schedules the timer if the
>> created slots are less than NET_RX_SLOTS_MIN. The count of new request
>> slots to be pushed are calculated as a difference between new req_prod
>> and rsp_cons which could be more than the actual slots, if there are
>> unconsumed responses.
>>
>> The fix is to calculate the count of newly created slots as the
>> difference between new req_prod and old req_prod.
>>
>> Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
>> Reviewed-by: Juergen Gross <jgross@suse.com>
>> ---
>> Changes in v2:
>> 	- Removed the old implementation of enabling polling on
>> 	  skb allocation error.
>> 	- Corrected the refill timer logic to schedule when newly
>> 	  created slots since last push is less than NET_RX_SLOTS_MIN.
> Your postings aren't showing up on vger.kernel.org at all.
>
> Are you getting a bounce message back?  I can only assume you are triggering
> one of the various content filters we have.
>
I haven't received any bounce messages till now. The mail showed up
in xen-devel after about 8 hours yesterday. Not sure what is happening
with vger.kernel.org. My initial patch showed up in all the mailing 
list. The
only difference is, I switched to a machine running a later version of git.

Should I try sending it once again?

Thanks

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[David Miller]

From: Vineeth Remanan Pillai <vineethp@amazon.com>
Date: Thu, 19 Jan 2017 09:17:09 -0800

> Should I try sending it once again?

No need, it just showed up.

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[David Miller]

From: Vineeth Remanan Pillai <vineethp@amazon.com>
Date: Thu, 19 Jan 2017 08:35:39 -0800

> From: Vineeth Remanan Pillai <vineethp@amazon.com>
> 
> During an OOM scenario, request slots could not be created as skb
> allocation fails. So the netback cannot pass in packets and netfront
> wrongly assumes that there is no more work to be done and it disables
> polling. This causes Rx to stall.
> 
> The issue is with the retry logic which schedules the timer if the
> created slots are less than NET_RX_SLOTS_MIN. The count of new request
> slots to be pushed are calculated as a difference between new req_prod
> and rsp_cons which could be more than the actual slots, if there are
> unconsumed responses.
> 
> The fix is to calculate the count of newly created slots as the
> difference between new req_prod and old req_prod.
> 
> Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
> Reviewed-by: Juergen Gross <jgross@suse.com>
> ---
> Changes in v2:
> 	- Removed the old implementation of enabling polling on
> 	  skb allocation error.
> 	- Corrected the refill timer logic to schedule when newly
> 	  created slots since last push is less than NET_RX_SLOTS_MIN.

Applied.

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[Boris Ostrovsky]

On 01/19/2017 11:35 AM, Vineeth Remanan Pillai wrote:
> From: Vineeth Remanan Pillai <vineethp@amazon.com>
>
> During an OOM scenario, request slots could not be created as skb
> allocation fails. So the netback cannot pass in packets and netfront
> wrongly assumes that there is no more work to be done and it disables
> polling. This causes Rx to stall.
>
> The issue is with the retry logic which schedules the timer if the
> created slots are less than NET_RX_SLOTS_MIN. The count of new request
> slots to be pushed are calculated as a difference between new req_prod
> and rsp_cons which could be more than the actual slots, if there are
> unconsumed responses.
>
> The fix is to calculate the count of newly created slots as the
> difference between new req_prod and old req_prod.
>
> Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
> Reviewed-by: Juergen Gross <jgross@suse.com>
> ---
> Changes in v2:
>     - Removed the old implementation of enabling polling on
>       skb allocation error.
>     - Corrected the refill timer logic to schedule when newly
>       created slots since last push is less than NET_RX_SLOTS_MIN.


There are couple of problems with this patch.
1. The 'if' clause now evaluates to true on pretty much every call to 
xennet_alloc_rx_buffers().
2. It tickles a latent bug during resume where the timer triggers before 
we re-connect. The trouble is that we now try to dereference 
queue->rx.sring which is NULL since we disconnect in netfront_resume(). 
(Curiously, I only observe it with 32-bit guests)

I'll send a patch later that will delete the timer since it looks like a 
bug to me in any case but the first problem seems to be more serious 
than the problem that this patch addresses.

-boris

>
>  drivers/net/xen-netfront.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 40f26b6..2c7c29f 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -321,7 +321,7 @@ static void xennet_alloc_rx_buffers(struct
> netfront_queue *queue)
>      queue->rx.req_prod_pvt = req_prod;
>
>      /* Not enough requests? Try again later. */
> -    if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
> +    if (req_prod - queue->rx.sring->req_prod < NET_RX_SLOTS_MIN) {
>          mod_timer(&queue->rx_refill_timer, jiffies + (HZ/10));
>          return;
>      }

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[Vineeth Remanan Pillai]

On 01/29/2017 03:09 PM, Boris Ostrovsky wrote:
>
> There are couple of problems with this patch.
> 1. The 'if' clause now evaluates to true on pretty much every call to 
> xennet_alloc_rx_buffers().
Thanks for catching this. In my testing I did not notice this - mostly 
because of the nature of the workload in my testing.

> 2. It tickles a latent bug during resume where the timer triggers 
> before we re-connect. The trouble is that we now try to dereference 
> queue->rx.sring which is NULL since we disconnect in 
> netfront_resume(). (Curiously, I only observe it with 32-bit guests)
I think we may hit this bug after removing the timer as well. We call 
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY soon after, which also dereference 
queue->rx.sring.

Thanks,
Vineeth

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[Boris Ostrovsky]

On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote:
>
>> 2. It tickles a latent bug during resume where the timer triggers
>> before we re-connect. The trouble is that we now try to dereference
>> queue->rx.sring which is NULL since we disconnect in
>> netfront_resume(). (Curiously, I only observe it with 32-bit guests)
> I think we may hit this bug after removing the timer as well. We call
> RING_PUSH_REQUESTS_AND_CHECK_NOTIFY soon after, which also dereference
> queue->rx.sring.


If the timer is deleted in xennet_disconnect_backend() then why would
anyone be pushing anything to the backend after that?

-boris

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[Vineeth Remanan Pillai]

On 01/30/2017 09:06 AM, Boris Ostrovsky wrote:
> On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote:
>
>>> 2. It tickles a latent bug during resume where the timer triggers
>>> before we re-connect. The trouble is that we now try to dereference
>>> queue->rx.sring which is NULL since we disconnect in
>>> netfront_resume(). (Curiously, I only observe it with 32-bit guests)
>> I think we may hit this bug after removing the timer as well. We call
>> RING_PUSH_REQUESTS_AND_CHECK_NOTIFY soon after, which also dereference
>> queue->rx.sring.
> If the timer is deleted in xennet_disconnect_backend() then why would
> anyone be pushing anything to the backend after that?
Sorry, I got the ordering wrong. Thanks for the clarification..

Thanks,
Vineeth

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[Vineeth Remanan Pillai]

On 01/30/2017 08:47 AM, Vineeth Remanan Pillai wrote:
>
> On 01/29/2017 03:09 PM, Boris Ostrovsky wrote:
>>
>> There are couple of problems with this patch.
>> 1. The 'if' clause now evaluates to true on pretty much every call to 
>> xennet_alloc_rx_buffers().
> Thanks for catching this. In my testing I did not notice this - mostly 
> because of the nature of the workload in my testing.
I am working on a patch to revert to the old behavior and solve the Rx 
stall issue by scheduling the timer if any of the following
conditions are true:
  - unconsumed requests + new requests < NET_RX_SLOTS_MIN (old behavior)
  - skb allocations fail

Will send out the patch by next week after I can do some testing.

Thanks,
Vineeth

Re: [PATCH] xen-netfront: Fix Rx stall during network stress and OOM

[Vineeth Remanan Pillai]

On 01/12/2017 12:17 PM, David Miller wrote:
> From: Vineeth Remanan Pillai <vineethp@amazon.com>
> Date: Wed, 11 Jan 2017 23:17:17 +0000
>
>> @@ -1054,7 +1059,11 @@ static int xennet_poll(struct napi_struct *napi, int budget)
>>   		napi_complete(napi);
>>   
>>   		RING_FINAL_CHECK_FOR_RESPONSES(&queue->rx, more_to_do);
>> -		if (more_to_do)
>> +
>> +		/* If there is more work to do or could not allocate
>> +		 * rx buffers, re-enable polling.
>> +		 */
>> +		if (more_to_do || err != 0)
>>   			napi_schedule(napi);
> Just polling endlessly in a loop retrying the SKB allocation over and over
> again until it succeeds is not very nice behavior.
>
> You already have that refill timer, so please use that to retry instead
> of wasting cpu cycles looping in NAPI poll.
Thanks Dave for the inputs.
On further look, I think I can fix it much simpler by correcting the 
test condition
for minimum slots for pushing requests. Existing test is like this:

<snip>
         /* Not enough requests? Try again later. */
        if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
                 mod_timer(&queue->rx_refill_timer, jiffies + (HZ/10));
                 return;
         }
</snip>

Actually the above check counts more than the newly created request slots
as it counts from rsp_cons. The actual count should be the difference 
between
new req_prod and old req_prod(in the queue). If skbs cannot be created, 
this
count remains small and hence we would schedule the timer. So the fix 
could be:

         /* Not enough requests? Try again later. */
-       if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
+       if (req_prod - queue->rx.sring->req_prod < NET_RX_SLOTS_MIN) {


I have done some initial testing to verify the fix. Will send out v2 
patch after couple
more round of testing.

Thanks,
Vineeth

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[Juergen Gross]

On 13/01/17 18:55, Remanan Pillai wrote:
> From: Vineeth Remanan Pillai <vineethp@amazon.com>
> 
> During an OOM scenario, request slots could not be created as skb
> allocation fails. So the netback cannot pass in packets and netfront
> wrongly assumes that there is no more work to be done and it disables
> polling. This causes Rx to stall.
> 
> The issue is with the retry logic which schedules the timer if the
> created slots are less than NET_RX_SLOTS_MIN. The count of new request
> slots to be pushed are calculated as a difference between new req_prod
> and rsp_cons which could be more than the actual slots, if there are
> unconsumed responses.
> 
> The fix is to calculate the count of newly created slots as the
> difference between new req_prod and old req_prod.
> 
> Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>

Reviewed-by: Juergen Gross <jgross@suse.com>


Thanks,

Juergen

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[Vineeth Remanan Pillai]

On 01/15/2017 10:24 PM, Juergen Gross wrote:
> On 13/01/17 18:55, Remanan Pillai wrote:
>> From: Vineeth Remanan Pillai <vineethp@amazon.com>
>>
>> During an OOM scenario, request slots could not be created as skb
>> allocation fails. So the netback cannot pass in packets and netfront
>> wrongly assumes that there is no more work to be done and it disables
>> polling. This causes Rx to stall.
>>
>> The issue is with the retry logic which schedules the timer if the
>> created slots are less than NET_RX_SLOTS_MIN. The count of new request
>> slots to be pushed are calculated as a difference between new req_prod
>> and rsp_cons which could be more than the actual slots, if there are
>> unconsumed responses.
>>
>> The fix is to calculate the count of newly created slots as the
>> difference between new req_prod and old req_prod.
>>
>> Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
> Reviewed-by: Juergen Gross <jgross@suse.com>
Thanks Juergen.

David,

Could you please pick up this change for net-next if there no more 
concerns..

Many Thanks,
Vineeth

>
>
> Thanks,
>
> Juergen
>

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[David Miller]

From: Vineeth Remanan Pillai <vineethp@amazon.com>
Date: Wed, 18 Jan 2017 09:02:17 -0800

> 
> On 01/15/2017 10:24 PM, Juergen Gross wrote:
>> On 13/01/17 18:55, Remanan Pillai wrote:
>>> From: Vineeth Remanan Pillai <vineethp@amazon.com>
>>>
>>> During an OOM scenario, request slots could not be created as skb
>>> allocation fails. So the netback cannot pass in packets and netfront
>>> wrongly assumes that there is no more work to be done and it disables
>>> polling. This causes Rx to stall.
>>>
>>> The issue is with the retry logic which schedules the timer if the
>>> created slots are less than NET_RX_SLOTS_MIN. The count of new request
>>> slots to be pushed are calculated as a difference between new req_prod
>>> and rsp_cons which could be more than the actual slots, if there are
>>> unconsumed responses.
>>>
>>> The fix is to calculate the count of newly created slots as the
>>> difference between new req_prod and old req_prod.
>>>
>>> Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
>> Reviewed-by: Juergen Gross <jgross@suse.com>
> Thanks Juergen.
> 
> David,
> 
> Could you please pick up this change for net-next if there no more
> concerns..

Why would I pick up "this change", if the author of the patch has
stated that he will resubmit the change implemented differently based
upon my feedback?

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[David Miller]

This v2 never made it into patchwork.  I don't know why, so please resend it to
netdev with the accumulated reviewed-by etc. tags added.

Thanks.

Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

[Vineeth Remanan Pillai]

On 01/18/2017 12:10 PM, David Miller wrote:
> This v2 never made it into patchwork.  I don't know why, so please resend it to
> netdev with the accumulated reviewed-by etc. tags added.
>
> Thanks.
Sorry about that. Will resend as a separate thread right away.

Thanks