Virtualization - Aug 2022 - [virtio-dev] [PATCH] virtio-net: use mtu size as buffer length for big packets

> From: Michael S. Tsirkin <mst at redhat.com>
> 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 at redhat.com>
> > > 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.

On Wed, Aug 10, 2022 at 04:22:41PM +0000, Parav Pandit
wrote:
> 
> > From: Michael S. Tsirkin <mst at redhat.com>
> > 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 at redhat.com>
> > > > 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?
We did feature bits for this in the past.
> > > 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.
Again, that line refers to \field{mtu} which is the max mtu supported,
irrespective to anything driver does.

-- 
MST