Re: [Xen-devel] Is: SKB_MAX_LEN bites again. Was: Re: bug disabling guest interface

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

The negotiation stuff is pretty orthogonal to this and is more about the
MTU of GSO frames. In terms of priority this is a distant second to the
above.

Ian.


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