From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f194.google.com (mail-qt0-f194.google.com [209.85.216.194]) by dpdk.org (Postfix) with ESMTP id 154DA2B96 for ; Fri, 3 Feb 2017 18:40:41 +0100 (CET) Received: by mail-qt0-f194.google.com with SMTP id n13so5896812qtc.0 for ; Fri, 03 Feb 2017 09:40:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=AaqExsWJ4sEVMI8xk3FW4rK2Lv7IdkrOjazEKGHV2q0=; b=m7a+x03Emj+J0AS5ZA+vhymgCfYS5O31ai2AF5bqb9g1ozi3BXrzjpgU5XGN4izZ1i w/0NkwX6Oz0L7P3NcZE0W0G07MemCjulH1vLHFPrg3juzlNJ9oscIUTbXYjUyYkK5FTg wHxgbv0Yf2hLlD6lElVN1zwf/lnnq2tr4GzqXqNn7OLBHTt41qHAwuUZk2vWGNp7dbOn NKDx4FbdlO6GuKV4vAm/yaGH1gi0/CNbSiw8ZvEVgdnJ4Z/hfWgIzM4EhDhSm4j5mJBm yLQJSywTDf+RsmxKeM6bKmPGIqoLOsCYWtYm3AkRiYkd5viYSD7yu5Xu8iFhvJ51Ssfd KyaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=AaqExsWJ4sEVMI8xk3FW4rK2Lv7IdkrOjazEKGHV2q0=; b=Lb7v8qADAhD8Y9vqXR5o0SWv18aIGwhj2Ru+/XCTUwvRkRprHfPGx1gioKEaCxTtSG 0R5WiPwDRFXN9rhrWxO9roKL9ThmvGQDGqMzB192v1eGPAaioQMyxXw2GfZbkw5wzWkx bv9uzqmkZRbyrulZznVl6DwZnFrZIBS/lyaaS65CRQvOfSEZfizUrP21tIqLbzmRHif3 MfWPzLV7kofMLlNKT/wll5TsG89Bq7RGL9rkIsM7c41YVo7zABw/4e5HIYVsZDCzR3gA +maqvzqOU6PextqcEcc6R7Vy7OdVoy/EZUWv97jKtmk0NJCiL9ldVj9bm+w8yGUjZrvb GTPQ== X-Gm-Message-State: AIkVDXJVZiAIA75ipsLTZWT/WIMJY04nmzF600GiVzjkpz/h9zs3L6GuFLQgvCzxwxv+cg== X-Received: by 10.200.37.85 with SMTP id 21mr15405914qtn.238.1486143641272; Fri, 03 Feb 2017 09:40:41 -0800 (PST) Received: from tlap.laine.org ([2600:8805:3800:1:4c4e:fc72:454c:32ac]) by smtp.gmail.com with ESMTPSA id t7sm24952940qtb.11.2017.02.03.09.40.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 09:40:40 -0800 (PST) Sender: sendmail To: Michal Privoznik , Maxime Coquelin , "Michael S. Tsirkin" , Laine Stump References: <20170201094304.GA3232@redhat.com> <20170201114119.GE3232@redhat.com> <20170202150621.GQ2915@redhat.com> <20170202190811-mutt-send-email-mst@kernel.org> <7637e2f5-5002-a39c-ad39-a814cdd33145@redhat.com> <3ca28dd9-140b-85c2-2040-b1397b3ea254@redhat.com> Cc: "dev@openvswitch.org" , Yuanhan Liu , Flavio Leitner , "dev@dpdk.org" , Ciara Loftus , Kevin Traynor , Daniele Di Proietto , "libvir-list@redhat.com" , mark.b.kavanagh@intel.com From: Laine Stump Message-ID: <9266365d-5a97-9105-635e-2fbdeda98587@laine.org> Date: Fri, 3 Feb 2017 12:40:38 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <3ca28dd9-140b-85c2-2040-b1397b3ea254@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 03 Feb 2017 21:46:27 +0100 Subject: Re: [dpdk-dev] [libvirt] [RFC] Vhost-user backends cross-version migration support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 17:40:42 -0000 On 02/03/2017 04:12 AM, Michal Privoznik wrote: > On 02/02/2017 06:16 PM, Maxime Coquelin wrote: >> >> On 02/02/2017 06:09 PM, Michael S. Tsirkin wrote: >>> On Thu, Feb 02, 2017 at 11:47:57AM -0500, Laine Stump wrote: >>>> On 02/02/2017 10:06 AM, Daniel P. Berrange wrote: >>>>> On Thu, Feb 02, 2017 at 03:14:01PM +0100, Maxime Coquelin wrote: >>>>>> On 02/01/2017 12:41 PM, Daniel P. Berrange wrote: >>>>>>> It depends where / how in OVS it needs to be set. The only stuff >>>>>>> libvirt >>>>>>> does with OVS is to run 'add-port' and 'del-port' commands via the >>>>>>> ovs >>>>>>> cli tool. >>>> (aside note: the code that exec's ovs-vsctl was written back when >>>> there was >>>> no standardized API for performing such operations. libvirt would >>>> prefer to >>>> not exec external programs though, and I've heard that OVS may now >>>> have an >>>> official API of some sort for doing things like this (maybe via >>>> netlink or >>>> dbus or something?) If that's the case, can someone point me in the >>>> right >>>> direction?) >>>> >>>>>>> We pass through arguments from the port profile stored in the >>>>>>> XML config. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/> >>>>>>> >>>>>>> >>>>>>> >>>>>>> eg those things in get passed as cli args to the >>>>>>> 'add-port' >>>>>>> command. Soo if add-port needs this new version string, then we'd >>>>>>> need >>>>>>> to add the version to the openvswitch virtualport XML. >>>>>>> >>>>>>> If the version is provided to OVS in a different command, then it >>>>>>> would >>>>>>> probably be outside scope of libvirt. >>>>>> I think it would make sense to be a parameter of the add-port command. >>>>>> But it would be for vhost-user related add-port command, I didn't find >>>>>> where/if this is managed in libvirt XML. >>>>> For vhost-user, libvirt does not have any interaction with OVS at >>>>> all. If the thing that's using the vhost-user UNIX socket, in turn >>>>> connects to OVS, that's outside scope of libvirt. IOW, for vhost-user >>>>> OVS it seems like that job is for Nova / os-vif to solve. >>>> This brings up another tangentially related question I came up >>>> against last >>>> night - qemu now has an option to report the host's MTU to the guest for >>>> virtio and vhost-user interfaces, and Michal Privoznik recently pushed >>>> patches to set the MTU sent to the guest via an explicit >>> size='n'/> in >>>> libvirt's interface config: >>>> >>>> https://bugzilla.redhat.com/1408701 >>>> >>>> But it would be much nicer if libvirt could learn the MTU of [that >>>> stuff at >>>> the other end of the unix socket] without requiring intervention in >>>> libvirt's config. For example, I'm just now testing patches for >>>> tap-based >>>> interfaces (connecting to Linux host bridges or OVS switches) that >>>> query the >>>> current MTU of the bridge and report that to qemu; this eliminates the >>>> burden of configuring each interface of each guest individually (and >>>> changing that config in all those places if someone ever wants to >>>> change the >>>> MTU of the bridge). >>>> >>>> As Dan says, though, libvirt's only interaction in the case of >>>> vhost-user is >>>> with the unix socket. Is there any way to learn what is the >>>> appropriate MTU >>>> from OVS in these cases? Or must Nova (or ovirt or some poor user) >>>> set that >>>> up in the libvirt config for every single interface? >>> We could add commands for all kind of queries to the vhost-user >>> protocol. libvirt would have to learn the vhost-user protocol though. >>> Interested? >>> >> I think it could be possible to query the MTU value from the OVS DB >> using its JSON RPC-like API, but this is something I haven't tried. >> I guess it would need to resolve the ovs interface from the vhost-user >> socket path. >> >> Can people familiar with OVS confirm this is something possible? > Libvirt does not use OVS' JSON RPC yet (it'll be long way to go anyway). > Therefore, for any OVS interaction it uses ovs-vsctl directly. Therefore: > > ovs-vsctl get Interface ovsbr0 mtu > > is what Laine is looking for. However, something fishy is happening here: > > lisa ~ # ovs-vsctl set Interface ovsbr0 mtu=9000 > lisa ~ # ovs-vsctl get Interface ovsbr0 mtu > 1500 > lisa ~ # ifconfig ovsbr0 mtu 9000 > lisa ~ # ovs-vsctl get Interface ovsbr0 mtu > 9000 > > (yes, Lisa Simpson) > > But since we just want to query the bridge's MTU and not set it, we > should be safe. Except that (as I just noted in the BZ) libvirt doesn't know the name of the bridge in the case of vhost-user. It only knows the name of the socket. So maybe in this case the only solution is for Nova (which *does* know about the bridge) needs to query the MTU and populate libvirt's XML appropriately.