[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 numberoftimes, 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |