From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Haigh Subject: Re: Is: SKB_MAX_LEN bites again. Was: Re: bug disabling guest interface Date: Wed, 13 Mar 2013 02:05:14 +1100 Message-ID: <513F442A.3030307@crc.id.au> References: <5139A56D.30107@crc.id.au> <00bf01ce1c34$395a4f20$ac0eed60$@jacekowski.org> <20130308203636.GA5422@phenom.dumpdata.com> <000301ce1c49$a3f759d0$ebe60d70$@jacekowski.org> <20130312144904.GE17901@phenom.dumpdata.com> <1363100173.32410.3.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1363100173.32410.3.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 03/13/2013 01:56 AM, Ian Campbell wrote: > On Tue, 2013-03-12 at 14:49 +0000, Konrad Rzeszutek Wilk wrote: >> On Fri, Mar 08, 2013 at 11:09:56PM +0100, Jacek Milewicz wrote: >>>>>> Is there any further information on a possible fix for this? >>> Thoughts? >>>>>> Ideas? As it seems to be hitting multiple sites, I'd like to get it >>>>> fixed asap... >>>>> >>>>> There are 3 ways I can see this fixed: >>>>> - update guests so all have same MAX_SKB_FRAGS (that includes windows >>>>> drivers (windows drivers use 19 for MAX_SKB_FRAGS)) -add some sort of >>>>> negotiation between host and guest >>>>> - change MAX_SKB_FRAGS to 19 to accommodate all guests >>>>> >>>>> Unfortunately first one requires changes to the guest and most don't >>>>> have that luxury. So the only way I see it could be fixed without >>>>> breaking compatibility even more is >>>> >>>> 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. >>>> >>>> Annie, Wei, Ian - were there some RFC patches floating around for this? >>>> >>> >>> As much as I agree that negotiation is the best option in long term. It >>> relies on people upgrading their kernels - and this is not the case (only >>> people running kernels from before 2011-12-23 are affected by this bug >>> (I'm not sure about other platforms)). >>> And in a lot of cases (VPS providers) there is no easy way to upgrade >>> guest kernels. >> >> Sure. The other option in the xen-netback might be a configurable option >> to let net-back know that it is running with older guests which expect >> 18 size MAX_SKB_FRAGS. That way we have the negotiation part, the code to >> deal with backend MAX_SKB_FRAGS != frontend MAX_SKB_FRAGS and the value that >> the system admin provides. > > I think this is over complicating things. netback can and should be > modified to be able to cope with guests using frags == 18 (or larger) > even if it only itself supports frags == 16 by coalescing things in the > obvious way. This works for all guest supplied frames up to 64K in size, > regardless of the number of slots they use to represent that 64K. On this, while we just hacked this in the kernel source to increase MAX_SKB_FRAGS to 19, I believe Jacek Milewicz tested 18 to work fine on linux guests, but it seems Windows guests would still fail unless it was increased to 19. -- Steven Haigh Email: netwiz@crc.id.au Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299