[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH net-next] xen-netback: improve guest-receive-side flow control




On 2013/11/29 0:27, Wei Liu wrote:
On Thu, Nov 28, 2013 at 04:05:52PM +0000, Paul Durrant wrote:
-----Original Message-----
From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
Sent: 28 November 2013 15:51
To: Paul Durrant
Cc: xen-devel@xxxxxxxxxxxxx; Wei Liu; Ian Campbell; David Vrabel
Subject: Re: [PATCH net-next] xen-netback: improve guest-receive-side flow
control

On Thu, Nov 28, 2013 at 01:11:12PM +0000, Paul Durrant wrote:
The flow control code relies on a double pass of tke skb, firstly to count
the number of ring slots needed to supply sufficient grant references, and
another to actually consume those references and build the grant copy
operations. It transpires that, in some scenarios, the initial count and the
number of references consumed differs and, after this happens a number
of
times, flow control is completely broken.

Can you describe it in more details? What kind of scenarios does this issue happen? I assume current xenvif_count_skb_slots() returns accurate value now.

The removal of xenvif_count_skb_slots() is OK because you're now
estimating minimum slots, but the actual number of slots consumed needs
to be acurate. Any reason you don't want to use xenvif_gop_skb()?

I can't. xenvif_gop_skb() pulls requests off the ring and if there aren't 
enough there it will crash'n'burn as far as I can tell. So, I need an upper 
bound on the number of slots before I call it.

I get what you mean. We can at least use some of the snippet in it
without pulling requests. See above.


I prefer accurate value since it would help to save more slots. But I am not sure what the flow control issue is, does using similar mechanism of xenvif_count_skb_slots here would cause this issue too?

Thanks
Annie

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.