> From: Michael S. Tsirkin <mst@xxxxxxxxxx> > Sent: Wednesday, August 10, 2022 12:05 PM > > On Wed, Aug 10, 2022 at 04:00:08PM +0000, Parav Pandit wrote: > > > > > From: Michael S. Tsirkin <mst@xxxxxxxxxx> > > > Sent: Wednesday, August 10, 2022 5:03 AM > > > > > > > > > > Should we make this depend on the vq reset ability maybe? > > > > > > > > The advantage of this is to keep TX working. Or we can use device > > > > reset as a fallback if there's no vq reset. > > > > > > > > Thanks > > > > > > Device reset is really annoying in that it loses all the state: > > > rx filters etc etc. > > > > The elegant solution is let driver tell the new mtu to the device. > > One way to do so is by using existing ctrl vq. > > That will need a new feature bit. > Yes. ctrl vq can tell what all configuration does it allow. :) Or you prefer feature bit? > > If merged buffer is done, and new mtu is > minimum posting size, no need > to undergo vq reset. > > If merged buffer is not done, and buffer posted are smaller than new mtu, > undergo vq reset optionally. > > This can be done with or without sending mtu to device. Yes, telling mtu to device helps device to optimize and adhere to the spec line " The device MUST NOT pass received packets that exceed mtu" in section 5.1.4.1. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
