From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 5D100CF7A for ; Fri, 17 Mar 2017 10:59:18 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7BA194E357; Fri, 17 Mar 2017 09:59:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7BA194E357 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=maxime.coquelin@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7BA194E357 Received: from [10.36.116.165] (ovpn-116-165.ams2.redhat.com [10.36.116.165]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3BD305DD62; Fri, 17 Mar 2017 09:59:15 +0000 (UTC) To: Yuanhan Liu References: <20170213142820.8964-1-maxime.coquelin@redhat.com> <20170312163406.17714-1-maxime.coquelin@redhat.com> <20170312163406.17714-5-maxime.coquelin@redhat.com> <20170316080059.GT18844@yliu-dev.sh.intel.com> <101becb5-2770-1817-e28f-9f07208c53d8@redhat.com> <20170317053251.GA18844@yliu-dev.sh.intel.com> Cc: aconole@redhat.com, sodey@sonusnet.com, jianfeng.tan@intel.com, thomas.monjalon@6wind.com, dev@dpdk.org From: Maxime Coquelin Message-ID: Date: Fri, 17 Mar 2017 10:59:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170317053251.GA18844@yliu-dev.sh.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 17 Mar 2017 09:59:18 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v3 4/9] vhost: Add API to get MTU value 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, 17 Mar 2017 09:59:18 -0000 On 03/17/2017 06:32 AM, Yuanhan Liu wrote: > On Thu, Mar 16, 2017 at 12:37:23PM +0100, Maxime Coquelin wrote: >> >> >> On 03/16/2017 09:00 AM, Yuanhan Liu wrote: >>> On Sun, Mar 12, 2017 at 05:34:01PM +0100, Maxime Coquelin wrote: >>>> This patch implements the function for the application to >>>> get the MTU value. >>> >>> I'm thinking the other way. As we are making vhost being generic, it >>> doesn't make too much sense now to store a net specific value at vhost >>> layer. I'm thinking we may could introduce a vhost-user request handler, >>> something like: >>> >>> rte_vhost_driver_register_msg_handler(socket, handler); >> >> That's a good point. >> >>> All vhost-user message then will goto the driver's sepcific handler. >>> if it's handlered, do nothing in vhost lib. Otherwise, we handle it >>> in vhost lib. >>> >>> In this way, you could handle the mtu message inside vhost-pmd; thus, >>> there is no need to introduce one more (net specific) API. >>> >>> Thoughts? >> >> I need to think more about it, but advantage of having a dedicated API >> is that in case the MTU value is not available, you can know from >> return code whether it is not yet available (-EAGAIN), or not supported >> (-ENOTSUP). >> >> That could be managed with the callback tough, by calling the callback >> with a 0 mtu value if not supported, so that the application can be >> sure that if the callback hasn't been called, then it is just that it >> is not ready yet. >> >> What do you think? > > I don't think the application should even be aware of the callback. > Application should get the mtu from the ethdev layer, by the API > rte_eth_dev_get_mtu(). And such MTU request should be only handled > in vhost-pmd, to serve the rte_eth_dev_get_mtu() API. I thought about OVS, which doesn't rely on Vhost PMD (at least didn't last time I checked). Maxime