On Tue, Aug 09, 2022 at 09:49:03PM +0000, Parav Pandit wrote: > > From: Michael S. Tsirkin <[email protected]> > > Sent: Tuesday, August 9, 2022 5:38 PM > > [..] > > > > I think virtio-net driver doesn't differentiate MTU and MRU, in > > > > which case the receive buffer will be reduced to fit the 1500B > > > > payload size when mtu is lowered down to 1500 from 9000. > > > How? Driver reduced the mXu to 1500, say it is improved to post buffers of > > 1500 bytes. > > > > > > Device doesn't know about it because mtu in config space is RO field. > > > Device keep dropping 9K packets because buffers posted are 1500 bytes. > > > This is because device follows the spec " The device MUST NOT pass > > received packets that exceed mtu". > > > > > > The "mtu" here is the device config field, which is > > > > /* Default maximum transmit unit advice */ > > > > It is the field from struct virtio_net_config.mtu. right? > This is RO field for driver. > > > there is no guarantee device will not get a bigger packet. > Right. That is what I also hinted. > Hence, allocating buffers worth upto mtu is safer.
yes > When user overrides it, driver can be further optimized to honor such new > value on rx buffer posting. no, not without a feature bit promising device won't get wedged. > > And there is no guarantee such a packet will be dropped as opposed to > > wedging the device if userspace insists on adding smaller buffers. > > > If user space insists on small buffers, so be it. If previously things worked, the "so be it" is a regression and blaming users won't help us. > It only works when user exactly know what user is doing in the whole network. If you want to claim this you need a new feature bit. > When user prefers to override the device RO field, device is in the dark and > things work on best effort basis. Dropping packets is best effort. Getting stuck forever isn't, that's a quality of implementation issue. > This must be a reasonably advance user who has good knowledge of its network > topology etc. > > For such case, may be yes, driver should be further optimized. > _______________________________________________ Virtualization mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/virtualization
