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 2F46F1075 for ; Thu, 16 Mar 2017 12:37:29 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D4D65C04BD37; Thu, 16 Mar 2017 11:37:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D4D65C04BD37 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=maxime.coquelin@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com D4D65C04BD37 Received: from [10.36.117.192] (ovpn-117-192.ams2.redhat.com [10.36.117.192]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4583E60319; Thu, 16 Mar 2017 11:37:26 +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> Cc: aconole@redhat.com, sodey@sonusnet.com, jianfeng.tan@intel.com, thomas.monjalon@6wind.com, dev@dpdk.org From: Maxime Coquelin Message-ID: <101becb5-2770-1817-e28f-9f07208c53d8@redhat.com> Date: Thu, 16 Mar 2017 12:37:23 +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: <20170316080059.GT18844@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.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 16 Mar 2017 11:37:30 +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: Thu, 16 Mar 2017 11:37:30 -0000 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? Maxime