From mboxrd@z Thu Jan 1 00:00:00 1970 From: ANNIE LI Subject: Re: Is: SKB_MAX_LEN bites again. Was: Re: bug disabling guest interface Date: Sun, 10 Mar 2013 12:58:09 +0800 Message-ID: <513C12E1.60806@oracle.com> References: <5139A56D.30107@crc.id.au> <00bf01ce1c34$395a4f20$ac0eed60$@jacekowski.org> <20130308203636.GA5422@phenom.dumpdata.com> <1362797836.8941.189.camel@hastur.hellion.org.uk> <806367887.20130309135329@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <806367887.20130309135329@eikelenboom.it> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Sander Eikelenboom Cc: 'Steven Haigh' , Ian Campbell , "Palagummi, Siva" , Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" , msw@amazon.com, Wei Liu , Jacek Milewicz List-Id: xen-devel@lists.xenproject.org On 2013-3-9 20:53, Sander Eikelenboom wrote: > Saturday, March 9, 2013, 3:57:16 AM, you wrote: > >>>> - change MAX_SKB_FRAGS to 19 to accommodate all guests >> Changing MAX_SKB_FRAGS is *not* an option upstream. This might be a >> useful local hack but we need to drop the idea as a long term fix. >>> Ugh. The negotiations between host and guest is probably the best >>> choice. The issues you are going to hit are that you might need >>> to redo the skbs to match what the frontend's max is. >> IMHO the right fix is for netback to coalesce as it copies from the >> frontend if it needs to do so, it is copying anyway so it should be >> cheap enough. I thought we had discussed this and someone was working on >> implementing it. If not Annie then perhaps it was Matt or Siva (both now >> CC'd) >> If necessary netback could even allocate a larger order head in order to >> accommodate very large packets, but I don't expect that to be required >> to fix the immediate issue we are seeing (but gives flexibility) >> This should get us past the immediate issue of the upstream change from > 18->>16 frags thing. Longer term the negotiation will allow us to avoid >> future incompatible changes in guest and host network stacks, as well as >> allowing frontends on other OSes (in particular Windows) to havea better >> chance of to DTRT. >> >>> Annie, Wei, Ian - were there some RFC patches floating around >>> for this? > I think you refer to this thread ? > > http://lists.xen.org/archives/html/xen-devel/2013-01/msg00198.html > > And i see the annie's patch and my response haven't made the list because annie dropped xen-devel from the response. > I will forward them .. Hi Sander, This is a patch in which I tried to do some fix in netfront, the thread you mentioned is facing the same issue with this one. Thanks Annie > > -- > Sander > > > > > >>>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h >>>> index 821c7f4..82de0f5 100644 >>>> --- a/include/linux/skbuff.h >>>> +++ b/include/linux/skbuff.h >>>> @@ -143,8 +143,8 @@ struct sk_buff; >>>> * Since GRO uses frags we allocate at least 16 regardless of page >>>> * size. >>>> */ >>>> -#if (65536/PAGE_SIZE + 1)< 16 >>>> -#define MAX_SKB_FRAGS 16UL >>>> +#if (65536/PAGE_SIZE + 1)< 19 >>>> +#define MAX_SKB_FRAGS 19UL >>>> #else >>>> #define MAX_SKB_FRAGS (65536/PAGE_SIZE + 1) >>>> #endif >>>> >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xen.org >>>> http://lists.xen.org/xen-devel >>>> > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel