similar to: [PATCH] virtio_net: set default mtu to 1500 when 'Device maximum MTU' bigger than 1500

On Sat, May 06, 2023 at 04:56:35PM +0800, Hao Chen wrote: > > > ? 2023/5/6 10:50, Xuan Zhuo ??: > > On Sat, 6 May 2023 10:15:29 +0800, Hao Chen <chenh at yusur.tech> wrote: > > > When VIRTIO_NET_F_MTU(3) Device maximum MTU reporting is supported. > > > If offered by the device, device advises driver about the value of its > > > maximum MTU. If

On Sat, 6 May 2023 10:15:29 +0800, Hao Chen <chenh at yusur.tech> wrote: > When VIRTIO_NET_F_MTU(3) Device maximum MTU reporting is supported. > If offered by the device, device advises driver about the value of its > maximum MTU. If negotiated, the driver uses mtu as the maximum > MTU value. But there the driver also uses it as default mtu, > some devices may have a maximum

On 6 May 2023 09:56:35 BST, Hao Chen <chenh at yusur.tech> wrote: >In the current code, if the maximum MTU supported by the virtio net hardware is 9000, the default MTU of the virtio net driver will also be set to 9000. When sending packets through "ping -s 5000", if the peer router does not support negotiating a path MTU through ICMP packets, the packets will be discarded.

On Tue, Oct 18, 2016 at 10:33:32PM -0400, Jarod Wilson wrote: > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index fad84f3..4885a42 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c > @@ -1419,17 +1419,6 @@ static const struct ethtool_ops virtnet_ethtool_ops = { > .set_settings = virtnet_set_settings, > }; > > -#define

On Wed, Oct 19, 2016 at 04:59:46PM +0300, Michael S. Tsirkin wrote: > On Tue, Oct 18, 2016 at 10:33:32PM -0400, Jarod Wilson wrote: > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > > index fad84f3..4885a42 100644 > > --- a/drivers/net/virtio_net.c > > +++ b/drivers/net/virtio_net.c > > @@ -1419,17 +1419,6 @@ static const struct ethtool_ops

On Wed, Oct 19, 2016 at 04:59:46PM +0300, Michael S. Tsirkin wrote: > On Tue, Oct 18, 2016 at 10:33:32PM -0400, Jarod Wilson wrote: > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > > index fad84f3..4885a42 100644 > > --- a/drivers/net/virtio_net.c > > +++ b/drivers/net/virtio_net.c > > @@ -1419,17 +1419,6 @@ static const struct ethtool_ops

The virtio committee recently ratified a change, VIRTIO-152, which defines the mtu field to be 'max' MTU, not simply desired MTU. This commit brings the virtio-net device in compliance with VIRTIO-152. Additionally, drop the max_mtu branch - it cannot be taken since the u16 returned by virtio_cread16 will never exceed the initial value of max_mtu. Signed-off-by: Aaron Conole <aconole

The virtio committee recently ratified a change, VIRTIO-152, which defines the mtu field to be 'max' MTU, not simply desired MTU. This commit brings the virtio-net device in compliance with VIRTIO-152. Additionally, drop the max_mtu branch - it cannot be taken since the u16 returned by virtio_cread16 will never exceed the initial value of max_mtu. Signed-off-by: Aaron Conole <aconole

On Thu, Oct 20, 2016 at 01:55:21PM -0400, Jarod Wilson wrote: > hyperv_net: > - set min/max_mtu, per Haiyang, after rndis_filter_device_add > > virtio_net: > - set min/max_mtu > - remove virtnet_change_mtu > vmxnet3: > - set min/max_mtu > > xen-netback: > - min_mtu = 0, max_mtu = 65517 > > xen-netfront: > - min_mtu = 0, max_mtu = 65535 > >

From: Aaron Conole <aconole at bytheb.org> The virtio committee recently ratified a change, VIRTIO-152, which defines the mtu field to be 'max' MTU, not simply desired MTU. This commit brings the virtio-net device in compliance with VIRTIO-152. Additionally, drop the max_mtu branch - it cannot be taken since the u16 returned by virtio_cread16 will never exceed the initial value of

From: Aaron Conole <aconole at bytheb.org> The virtio committee recently ratified a change, VIRTIO-152, which defines the mtu field to be 'max' MTU, not simply desired MTU. This commit brings the virtio-net device in compliance with VIRTIO-152. Additionally, drop the max_mtu branch - it cannot be taken since the u16 returned by virtio_cread16 will never exceed the initial value of

hyperv_net: - set min/max_mtu virtio_net: - set min/max_mtu - remove virtnet_change_mtu vmxnet3: - set min/max_mtu CC: netdev at vger.kernel.org CC: virtualization at lists.linux-foundation.org CC: "K. Y. Srinivasan" <kys at microsoft.com> CC: Haiyang Zhang <haiyangz at microsoft.com> CC: "Michael S. Tsirkin" <mst at redhat.com> CC: Shrikrishna Khare

hyperv_net: - set min/max_mtu virtio_net: - set min/max_mtu - remove virtnet_change_mtu vmxnet3: - set min/max_mtu CC: netdev at vger.kernel.org CC: virtualization at lists.linux-foundation.org CC: "K. Y. Srinivasan" <kys at microsoft.com> CC: Haiyang Zhang <haiyangz at microsoft.com> CC: "Michael S. Tsirkin" <mst at redhat.com> CC: Shrikrishna Khare

On Thu, 2016-03-10 at 09:28 -0500, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes the

On Thu, 2016-03-10 at 09:28 -0500, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes the

On Tue, Mar 15, 2016 at 05:04:13PM -0400, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes

hyperv_net: - set min/max_mtu, per Haiyang, after rndis_filter_device_add virtio_net: - set min/max_mtu - remove virtnet_change_mtu vmxnet3: - set min/max_mtu xen-netback: - min_mtu = 0, max_mtu = 65517 xen-netfront: - min_mtu = 0, max_mtu = 65535 unisys/visor: - clean up defines a little to not clash with network core or add redundat definitions CC: netdev at vger.kernel.org CC:

hyperv_net: - set min/max_mtu, per Haiyang, after rndis_filter_device_add virtio_net: - set min/max_mtu - remove virtnet_change_mtu vmxnet3: - set min/max_mtu xen-netback: - min_mtu = 0, max_mtu = 65517 xen-netfront: - min_mtu = 0, max_mtu = 65535 unisys/visor: - clean up defines a little to not clash with network core or add redundat definitions CC: netdev at vger.kernel.org CC:

On Tue, Mar 15, 2016 at 05:04:13PM -0400, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes

This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it exists, read the advised MTU and use it. No proper error handling is provided for the case where a user changes the negotiated MTU. A future commit will add proper error handling. Instead, a warning is emitted if the guest changes the device MTU after previously being given advice. Signed-off-by: Aaron Conole <aconole