"Michael S. Tsirkin" <m...@redhat.com> writes: > On Wed, Nov 30, 2016 at 01:16:59PM +0100, Maxime Coquelin wrote: >> >> >> On 11/30/2016 12:23 PM, Jason Wang wrote: >> > >> > >> > On 2016年11月30日 18:10, Maxime Coquelin wrote: >> > > This series implements Virtio spec update from Aaron Conole which >> > > defines a way for the host to expose its max MTU to the guest. >> > > >> > > This third version re-desings how MTU value is provided to QEMU. >> > > Now, host_mtu parameter is added to provide QEMU with the MTU value, >> > > and the backend, if supported, gets notified of the MTU value when the >> > > MTU feature neogotiation succeeds. >> > > >> > > Only user backend currently supports MTU notification. A new protocol >> > > feature has been implemented for sending MTU value to the backend. >> > > Aaron, Kevin, Flavio, do you confirm this works for OVS if DPDK vhost lib >> > > adds needed API to get the MTU value? >> > > >> > > For kernel backend, it is expected the management tool also configures >> > > the tap/macvtap interface with same MTU value. >> > > Daniel, I would be interrested about your feedback on this implementation >> > > from management tool point of view. >> > >> > I believe we want management tool to configure both kernel and user >> > backends. >> >> Yes, I think you are right. >> >> The vhost-user protocol feature would in this case be used to ensure >> consistency. >> >> Does that make sense, or we should just drop VHOST_USER_SET_MTU? >> >> Thanks, >> Maxime > > > It doesn't hurt to have a feature and if set send mtu to backend, > to verify that it can support that mtu. > But we don't need to require that feature, if not supported > we can just assume mtu is correct.
Sorry for late reply - I agree, this is fine.
