WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] netback: allow arbitrary mtu size until fronten

On Mon, 2011-02-07 at 09:49 +0000, Jan Beulich wrote:
> >>> On 07.02.11 at 10:11, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> > On Mon, 2011-02-07 at 09:03 +0000, Jan Beulich wrote:
> >> >>> On 06.02.11 at 14:42, Olaf Hering <olaf@xxxxxxxxx> wrote:
> >> > Allow arbitrary mtu size until the frontend is connected.  Once the
> >> > connection is established, adjust mtu by checking if the backend
> >> > supports the 'feature-sg'.  If the backend does support it, keep the
> >> > current mtu. Otherwise set it to the default value, which is 1500.
> >> > 
> >> > This helps the vif-bridge hotplug script to set the mtu size to 9000
> >> > while bringing up the guest.
> >> 
> >> Isn't this functionally the same as
> >> 
> > http://xenbits.xen.org/XCP/linux-2.6.32.pq.hg?file/043b76e4943c/xen-netback-A
> >  
> > llow-setting-of-large-MTU-before-rings.patch
> >> or its pv-ops parent 
> > https://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=commitdiff;h=bee2
> >  
> > eec2355c4bf4e149a426d5e30527162de566
> >> (in which case it would seem preferable to pull in that change)?
> >> 
> >> Ian, looking at that patch of yours again, the adjustment to
> >> netbk_set_sg() seems a little odd: Why is it necessary to
> >> reduce dev->mtu unconditionally (i.e. independent of the
> >> value of "data") here?
> > 
> > Hmm. I don't recall. Seems like a bug looking at it now...
> > 
> > Luckily for me it appears to have been correct by Paul in
> > d532fa93d4eeabbfc0176a6a9a93b0d6ade3f6c4
> 
> Indeed, to some part: How would dev->mtu grow again if sg
> got re-enabled after having been disabled?

Er, manual intervention?

For other features (e.g. gso, csum) I think we track the requested
configuration separately from the currently in force configuration.
Presumably we could do the same here if that's what we want.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel