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).
Maxime
