Re: Is: SKB_MAX_LEN bites again. Was: Re: bug disabling guest interface

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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.

What I am saying is that if we get the negotiation protcol figured out
properly we can provide a per-guest value that the system admin
can over-write to say: "I know that this guest uses _this_ size".