[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature |
Date: |
Wed, 23 Nov 2016 19:42:47 +0200 |
On Wed, Nov 23, 2016 at 09:02:53AM -0500, Aaron Conole wrote:
> "Michael S. Tsirkin" <address@hidden> writes:
>
> > On Wed, Nov 23, 2016 at 11:42:52AM +0800, Jason Wang wrote:
> >> > > > > > > > Seems to me like an easy way to get out of sync.
> >> > > > > >
> >> > > > > >If we send it to the backend, that has a chance to check
> >> > > > > >mtu and disconnect on error.
> >> > > >
> >> > > >For vhost-user backend, we can send it the MTU value with a
> >> > > >vhost-user protocol feature.
> >> > > >
> >> > > >For tun/macvtap, how do you do without adding a new ioctl ?
> >> > Have management configure same mtu on the backend and in qemu.
> >> >
> >> >
> >>
> >> Then why not do same for vhost-user (instead of using two different
> >> methods)?
> >
> > That's what I'm saying. If backend supports that, we can also
> > check the mtu in some way to make sure it matches.
>
> I'm not sure why we need a new ioctl (or an ioctl at all - netlink
> supports all of this)?
>
> ex:
>
> 08:58:34 aconole {fast-datapath-beta-rhel-7} ~/rhpkg/openvswitch$ sudo ip
> tuntap add dev tap0 mode tap
> [sudo] password for aconole:
> 08:58:40 aconole {fast-datapath-beta-rhel-7} ~/rhpkg/openvswitch$ ip l
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
> DEFAULT group default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> ...
> 7: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
> group default qlen 1000
> link/ether 46:e0:fc:83:54:1c brd ff:ff:ff:ff:ff:ff
> 08:58:51 aconole {fast-datapath-beta-rhel-7} ~/rhpkg/openvswitch$ sudo ip l
> set tap0 mtu 8000
> 08:58:54 aconole {fast-datapath-beta-rhel-7} ~/rhpkg/openvswitch$ ip l
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
> DEFAULT group default qlen 1000
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> ...
> 7: tap0: <BROADCAST,MULTICAST> mtu 8000 qdisc noop state DOWN mode DEFAULT
> group default qlen 1000
> link/ether 46:e0:fc:83:54:1c brd ff:ff:ff:ff:ff:ff
>
> So, at least with iproute2, we can already read and write using the netlink
> interface for tuntap devices. I haven't played with macvtap, but I
> think it's similar support - just do a netlink query, get the configured
> MTU, and advertise it. I might be missing something though - I'm a
> simple guy with simple ideas. Maybe there's a cross-platform issue or
> something?
>
> -Aaron
qemu is generally not running with enough priveledges to
allow access to netlink.
- Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature, (continued)
- Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature, Michael S. Tsirkin, 2016/11/21
- Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature, Jason Wang, 2016/11/21
- Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature, Maxime Coquelin, 2016/11/22
- Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature, Aaron Conole, 2016/11/22
- Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature, Michael S. Tsirkin, 2016/11/22
- Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature, Maxime Coquelin, 2016/11/22
- Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature, Michael S. Tsirkin, 2016/11/22
- Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature, Jason Wang, 2016/11/22
- Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature, Michael S. Tsirkin, 2016/11/22
- Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature, Aaron Conole, 2016/11/23
- Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature,
Michael S. Tsirkin <=