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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

> > - 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?
> 
> > 
> > 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@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel
> > 



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