[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: |
Aaron Conole |
Subject: |
Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature |
Date: |
Wed, 23 Nov 2016 09:02:53 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
"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
- 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, Aaron Conole, 2016/11/18
- 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 <=
- Re: [Qemu-devel] [RFC v2 0/3] virtio-net: Add support to MTU feature, Michael S. Tsirkin, 2016/11/23