From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>
Cc: aconole@redhat.com, sodey@sonusnet.com, jianfeng.tan@intel.com,
thomas.monjalon@6wind.com, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v3 4/9] vhost: Add API to get MTU value
Date: Mon, 20 Mar 2017 16:42:03 +0800 [thread overview]
Message-ID: <20170320084203.GL18844@yliu-dev.sh.intel.com> (raw)
In-Reply-To: <c8067a17-f3df-96d6-d330-d66bf981cb1f@redhat.com>
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
next prev parent reply other threads:[~2017-03-20 8:44 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 14:28 [dpdk-dev] [PATCH 0/7] virtio/vhost: Add MTU feature support Maxime Coquelin
2017-02-13 14:28 ` [dpdk-dev] [PATCH 1/7] vhost: Enable VIRTIO_NET_F_MTU feature Maxime Coquelin
2017-02-13 14:28 ` [dpdk-dev] [PATCH 2/7] vhost: vhost-user: Add MTU protocol feature support Maxime Coquelin
2017-02-13 14:28 ` [dpdk-dev] [PATCH 3/7] vhost: Add new ready status flag Maxime Coquelin
2017-02-13 14:28 ` [dpdk-dev] [PATCH 4/7] vhost: Add API to get/set MTU value Maxime Coquelin
2017-02-13 14:28 ` [dpdk-dev] [PATCH 5/7] net/vhost: Implement mtu_set callback Maxime Coquelin
2017-02-13 14:28 ` [dpdk-dev] [PATCH 6/7] net/virtio: Add MTU feature support Maxime Coquelin
2017-02-16 19:31 ` Aaron Conole
2017-02-16 21:17 ` Maxime Coquelin
2017-02-13 14:28 ` [dpdk-dev] [PATCH 7/7] app/testpmd: print MTU value in show port info Maxime Coquelin
2017-02-23 7:10 ` [dpdk-dev] [PATCH 0/7] virtio/vhost: Add MTU feature support Yuanhan Liu
2017-03-01 7:44 ` Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 " Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 1/7] vhost: Enable VIRTIO_NET_F_MTU feature Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 2/7] vhost: vhost-user: Add MTU protocol feature support Maxime Coquelin
2017-03-08 2:31 ` Yuanhan Liu
2017-03-12 10:24 ` Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 3/7] vhost: Add new ready status flag Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 4/7] vhost: Add API to get MTU value Maxime Coquelin
2017-03-08 2:45 ` Yuanhan Liu
2017-03-12 10:23 ` Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 5/7] net/vhost: Fill rte_eth_dev's MTU property Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 6/7] net/virtio: Add MTU feature support Maxime Coquelin
2017-03-06 8:27 ` [dpdk-dev] [PATCH v2 7/7] app/testpmd: print MTU value in show port info Maxime Coquelin
2017-03-07 21:57 ` [dpdk-dev] [PATCH v2 0/7] virtio/vhost: Add MTU feature support Thomas Monjalon
2017-03-12 10:00 ` Maxime Coquelin
2017-03-12 16:33 ` [dpdk-dev] [PATCH v3 0/9] " Maxime Coquelin
2017-03-12 16:33 ` [dpdk-dev] [PATCH v3 1/9] vhost: Enable VIRTIO_NET_F_MTU feature Maxime Coquelin
2017-03-12 16:33 ` [dpdk-dev] [PATCH v3 2/9] vhost: vhost-user: Add MTU protocol feature support Maxime Coquelin
2017-03-12 16:34 ` [dpdk-dev] [PATCH v3 3/9] vhost: Add new ready status flag Maxime Coquelin
2017-03-12 16:34 ` [dpdk-dev] [PATCH v3 4/9] vhost: Add API to get MTU value Maxime Coquelin
2017-03-16 8:00 ` Yuanhan Liu
2017-03-16 11:37 ` Maxime Coquelin
2017-03-17 5:32 ` Yuanhan Liu
2017-03-17 9:59 ` Maxime Coquelin
2017-03-20 8:42 ` Yuanhan Liu [this message]
2017-03-12 16:34 ` [dpdk-dev] [PATCH v3 5/9] vhost: export " Maxime Coquelin
2017-03-12 16:34 ` [dpdk-dev] [PATCH v3 6/9] net/vhost: Fill rte_eth_dev's MTU property Maxime Coquelin
2017-03-12 16:34 ` [dpdk-dev] [PATCH v3 7/9] net/virtio: Add MTU feature support Maxime Coquelin
2017-04-05 4:52 ` Tan, Jianfeng
2017-04-05 7:11 ` Maxime Coquelin
2017-04-05 9:42 ` Tan, Jianfeng
2017-04-05 13:54 ` Maxime Coquelin
2017-04-05 14:50 ` Tan, Jianfeng
2017-04-07 16:40 ` Maxime Coquelin
2017-04-10 6:48 ` Tan, Jianfeng
2017-03-12 16:34 ` [dpdk-dev] [PATCH v3 8/9] doc: announce Virtio and Vhost MTU support Maxime Coquelin
2017-03-12 16:34 ` [dpdk-dev] [PATCH v3 9/9] app/testpmd: print MTU value in show port info Maxime Coquelin
2017-03-22 8:58 ` [dpdk-dev] [PATCH v3 0/9] virtio/vhost: Add MTU feature support Yuanhan Liu
2017-03-22 9:03 ` Maxime Coquelin
2017-03-28 5:39 ` Yao, Lei A
2017-03-30 11:34 ` Maxime Coquelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170320084203.GL18844@yliu-dev.sh.intel.com \
--to=yuanhan.liu@linux.intel.com \
--cc=aconole@redhat.com \
--cc=dev@dpdk.org \
--cc=jianfeng.tan@intel.com \
--cc=maxime.coquelin@redhat.com \
--cc=sodey@sonusnet.com \
--cc=thomas.monjalon@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).