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

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

On Wed, Aug 10, 2022 at 12:58:58PM -0400, Michael S. Tsirkin
wrote:
> 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.
BTW with any such ctrl vq interface we need to think how cases such as
increasing and decreasing MTU work.  The normal behaviour for linux
drivers is to limit this to when the link is down.  Which reminds me, we
do not have a command to bring link down, either.
> -- 
> MST

> From: Michael S. Tsirkin <mst at redhat.com>
> Sent: Wednesday, August 10, 2022 12:59 PM
> 
> 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.
> 
Ok. Will try to draft the update for future.

Gavin should repost the patch to address comments unrelated to this future bit
anyway.
Right?
> > > > 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