From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 43DDF11DE for ; Mon, 20 Mar 2017 09:44:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1489999450; x=1521535450; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=kj5602GKJ3FJwVH2IRXaPyJRRJF67p9P4TTorJQpojs=; b=qWv7jeIls2NDWDYnaeP29BR73zhmeeLLqRDm/OACEgYG0INDUMW0Oqhl 6nQmmINbB/KU5RQZ5tSf9RFEE82PNg==; Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Mar 2017 01:44:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,193,1486454400"; d="scan'208";a="1144563596" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga002.fm.intel.com with ESMTP; 20 Mar 2017 01:44:07 -0700 Date: Mon, 20 Mar 2017 16:42:03 +0800 From: Yuanhan Liu To: Maxime Coquelin Cc: aconole@redhat.com, sodey@sonusnet.com, jianfeng.tan@intel.com, thomas.monjalon@6wind.com, dev@dpdk.org Message-ID: <20170320084203.GL18844@yliu-dev.sh.intel.com> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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: Mon, 20 Mar 2017 08:44:10 -0000 On Fri, Mar 17, 2017 at 10:59:12AM +0100, Maxime Coquelin wrote: > > > 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). Oh, right. Let's keep this API then. --yliu