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:49:00 +0800 Message-ID: <513C10BC.10105@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1362797836.8941.189.camel@hastur.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Wei Liu , "Palagummi, Siva" , Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" , msw@amazon.com, 'Steven Haigh' , Jacek Milewicz List-Id: xen-devel@lists.xenproject.org On 2013-3-9 10:57, Ian Campbell 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) Sorry, I have been working on some windows whql thing these days, so did not start it till now. I did do some patch for netfront before(Sander mentioned later), which did some segment for large skbs in netfront. This is different from what you mentioned. I assume we need to do some work in both netback and netfront. Thanks Annie > > 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? >> >>> 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