[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [RFC PATCH] set tap mtu



On Tue, 2008-11-18 at 14:57 +0000, Daniel P. Berrange wrote:
> On Mon, Nov 17, 2008 at 06:39:45PM -0800, Chris Wright wrote:
> > Below is a simple PoC for setting a large MTU size on a tap device.
> > With this we are able to improve net i/o throughput substantially (~40%
> > improvement on TX and ~130% improvement on RX).  This is just RFC because
> > it's hardcoded to an MTU of 9000 for any tap device.  Thoughts on the
> > best way to add this kind of support?
> 
> Well if we want it to be configurable per guest then we'd add it
> to the XML, in the <target> device field, alongside the VIF
> name, eg
> 
>     <interface type='network'>
>         <source network='default'/>
>         <target dev='vnet7' mtu='9000'/>
>         <mac address="11:22:33:44:55:66"/>
>     </interface>

Yeah, I was just about to suggest that.

> libvirt can handle this stuff directly for QEMU and LXC drivers
> but for Xen, VIF setup is done by an /etc/xen/scripts/vif-bridge
> script. AFAIK, XenD has no config param for MTU, but there's
> no reason we can't write a patch for XenD to accept an MTU param
> and pass that through to vif-bridge.  If large MTUs are useful
> for Xen's  netback of course...
> 
> If we don't need this configurable, is there any downside to setting
> a MTU of 9000 for all TAP devices we create. I assume that PTMUD
> will ensure that the guest only sends packets <= 1500 if the physical
> NIC connected to the bridge doesn't have such a large MTU, or if the
> guest doesn't do PMTUD, then the bridge code will do fragementation
> as needed ?

My take on it is that it needs to be an opt in thing - if path MTU
discovery was sufficient to deal with all cases then we'd probably have
an mtu > 1500 everywhere ... Herbert?

Cheers,
Mark.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]