[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <03E840D17E263A48A5766AD576E0423A0129262C0A@exch-mbx-111.vmware.com>
Date: Fri, 24 Jun 2011 16:23:50 -0700
From: Scott Goldman <scottjg@...are.com>
To: Jesse Gross <jesse@...ira.com>
CC: David Miller <davem@...emloft.net>,
Shreyas Bhatewara <sbhatewara@...are.com>,
VMware PV-Drivers <pv-drivers@...are.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [Pv-drivers] [PATCH] vmxnet3: Enable GRO support.
> I ran some benchmarks and do see a slight performance drop with GRO
> when LRO is also on, so it seems reasonable to avoid it in that
> situation. I can resubmit with that change.
Cool, thanks.
> As an aside, in many cases the hypervisor actually has all of the
> information that is necessary to keep LRO on but does not provide it
> to the guest. For example, in the VM-to-VM case the MSS is provided
> by the sender as part of the TSO descriptor and if given to the
> receiver we could generate a GSO frame and avoid the need to do GRO in
> the first place. Do you know if it is possible to do this?
I think that sounds like a pretty good idea, but if I understand correctly, that change needs to go in the hypervisor, not just the driver. The device emulation backend needs to populate that MSS somewhere in the receive descriptor. I will file an internal bug about it, but just to set expectations, ESX 5.0 is about to be released, so realistically at the earliest, this change may not be publically available for another year.
-sjg
P.S. Ronghua, the vmxnet3 mastermind, works at Nicira now. If you see him, tell him I said hi.
Powered by blists - more mailing lists