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
