qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]