> From: Michael S. Tsirkin <mst@xxxxxxxxxx> > Sent: Monday, December 20, 2021 5:33 PM > > On Mon, Dec 20, 2021 at 03:49:21AM +0000, Parav Pandit wrote: > > > > > > > From: Michael S. Tsirkin <mst@xxxxxxxxxx> > > > Sent: Sunday, December 19, 2021 3:37 AM > > > > > > On Sat, Dec 18, 2021 at 01:53:01PM -0700, David Ahern wrote: > > > > On 12/17/21 1:08 AM, Parav Pandit wrote: > > > > > @@ -204,6 +217,8 @@ static void vdpa_opts_put(struct nlmsghdr > > > > > *nlh, > > > struct vdpa *vdpa) > > > > > if (opts->present & VDPA_OPT_VDEV_MAC) > > > > > mnl_attr_put(nlh, VDPA_ATTR_DEV_NET_CFG_MACADDR, > > > > > sizeof(opts->mac), opts->mac); > > > > > + if (opts->present & VDPA_OPT_VDEV_MTU) > > > > > + mnl_attr_put_u16(nlh, > VDPA_ATTR_DEV_NET_CFG_MTU, > > > opts->mtu); > > > > > > > > Why limit the MTU to a u16? Eric for example is working on "Big TCP" > > > > where IPv6 can work with Jumbograms where mtu can be > 64k. > > > > > > > > https://datatracker.ietf.org/doc/html/rfc2675 > > > > > > Well it's 16 bit at the virtio level, though we can extend that of > > > course. Making it match for now removes need for validation. > > > -- > > As Michael mentioned virtio specification limits the mtu to 64k-1. Hence 16- > bit. > > First we need to update the virtio spec to support > 64K mtu. > > However, when/if (I don't know when) that happens, we need to make this > also u32. > > So may be we can make it u32 now, but still restrict the mtu value to 64k-1 in > kernel, until the spec is updated. > > > > Let me know, if you think that's future proofing is better, I first need to > update the kernel to take nla u32. > > > > > MST > > After consideration, this future proofing seems like a good thing to have. Ok. I will first get kernel change merged, after which will send v3 for iproute2. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
