RE: [iproute2-next v2 4/4] vdpa: Enable user to set mtu of the vdpa device

From: Michael S. Tsirkin <mst@redhat.com>
Sent: Monday, December 20, 2021 5:33 PM

On Mon, Dec 20, 2021 at 03:49:21AM +0000, Parav Pandit wrote:

quoted

quoted

From: Michael S. Tsirkin <mst@redhat.com>
Sent: Sunday, December 19, 2021 3:37 AM

On Sat, Dec 18, 2021 at 01:53:01PM -0700, David Ahern wrote:

quoted

On 12/17/21 1:08 AM, Parav Pandit wrote:

quoted

@@ -204,6 +217,8 @@ static void vdpa_opts_put(struct nlmsghdr

*nlh,

struct vdpa *vdpa)

quoted

quoted

 	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,

quoted

quoted

opts->mtu);

quoted

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.

quoted

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.

quoted

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.

quoted

Let me know, if you think that's future proofing is better, I first need to

update the kernel to take nla u32.

quoted

quoted

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.