[dpdk-dev] [PATCH v5 1/3] vhost: Add callback and private data for vhost PMD
Yuanhan Liu
yuanhan.liu at linux.intel.com
Wed Dec 23 03:44:53 CET 2015
On Tue, Dec 22, 2015 at 01:38:29AM -0800, Rich Lane wrote:
> On Mon, Dec 21, 2015 at 9:47 PM, Yuanhan Liu <yuanhan.liu at linux.intel.com>
> wrote:
>
> On Mon, Dec 21, 2015 at 08:47:28PM -0800, Rich Lane wrote:
> > The queue state change callback is the one new API that needs to be
> > added because
> > normal NICs don't have this behavior.
>
> Again I'd ask, will vring_state_changed() be enough, when above issues
> are resolved: vring_state_changed() will be invoked at new_device()/
> destroy_device(), and of course, ethtool change?
>
>
> It would be sufficient. It is not a great API though, because it requires the
> application to do the conversion from struct virtio_net to a DPDK port number,
> and from a virtqueue index to a DPDK queue id and direction. Also, the current
> implementation often makes this callback when the vring state has not actually
> changed (enabled -> enabled and disabled -> disabled).
>
> If you're asking about using vring_state_changed() _instead_ of the link status
> event and rte_eth_dev_socket_id(),
No, I like the idea of link status event and rte_eth_dev_socket_id();
I was just wondering why a new API is needed. Both Tetsuya and I
were thinking to leverage the link status event to represent the
queue stats change (triggered by vring_state_changed()) as well,
so that we don't need to introduce another eth event. However, I'd
agree that it's better if we could have a new dedicate event.
Thomas, here is some background for you. For vhost pmd and linux
virtio-net combo, the queue can be dynamically changed by ethtool,
therefore, the application wishes to have another eth event, say
RTE_ETH_EVENT_QUEUE_STATE_CHANGE, so that the application can
add/remove corresponding queue to the datapath when that happens.
What do you think of that?
> then yes, it still works. I'd only consider
> that a stopgap until the real ethdev APIs are implemented.
>
> I'd suggest to add RTE_ETH_EVENT_QUEUE_STATE_CHANGE rather than
> create another callback registration API.
>
> Perhaps we could merge the basic PMD which I think is pretty solid and then
> continue the API discussion with patches to it.
Perhaps, but let's see how hard it could be for the new eth event
discussion then.
--yliu
More information about the dev
mailing list