From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <maxime.coquelin@redhat.com>
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by dpdk.org (Postfix) with ESMTP id 2F46F1075
 for <dev@dpdk.org>; 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 <yuanhan.liu@linux.intel.com>
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 <maxime.coquelin@redhat.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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