On Wed, Feb 25, 2015 at 4:29 PM, Zhou, Danny <danny.zhou at intel.com> wrote:
> > > > > *From:* David Marchand [mailto:david.marchand at 6wind.com] > *Sent:* Wednesday, February 25, 2015 6:22 PM > *To:* Zhou, Danny > *Cc:* dev at dpdk.org; Liang, Cunming > *Subject:* Re: [dpdk-dev] [PATCH v5 5/6] eal: add per rx queue interrupt > handling based on VFIO > > > > > > DZ: To avoid recreating the epoll instance for each queue, the struct > rte_intr_handle(or a new structure added to ethdev) > > should be extended by adding fields storing per-queue pfd. This way, it > could reduce user/kernel context switch overhead > > when calling epoll_create() each time. > > > > Sounds good? > > > > You don't need a epfd per queue. And hardcoding epfd == eventfd will give > a not very usable api. > > > > Plus, epoll is something linux-specific, so you can't move it out of > eal/linux. > > I suppose you need an abstraction here (and in the future we could add > something for bsd ?). > > > > DZ: libev provides abstraction layer which is a good candidate to > integrate, rather than > > reinventing one I think. The BSD support can be implemented in the files > under > > lib\librte_eal\bsdapp\eal folder by calling BSD specific APIs. Maybe it is > a good idea to introduce > > a separated component like OS Adaption Layer into EAL in the future once > DPDK is widely adopted in > > BSD as well as Windows, then all DPDK components invoke Linux specific > APIs could instead calling abstraction APIs. > > > > Adding an abstraction here specifically for epoll does not resolve all the > porting/migration problem in my mind. > Yes, reusing this kind of library (or libevent) looks like a good idea. Hum, I would say eal/common is there for the common part and for the different abstractions. Do you see anything that would not fit in ? > eventfds creation can not be handled by ethdev, since it needs > infrastructure and informations from within the eal/linux. > > Again, do we need an abstraction ? > > > > ethdev must be the one that does the mappings between port/queue and > eventfds (or any object that represents a way to wake up for a given > port/queue). > > > > DZ: agreed after revisiting code. Let us follow your direction to create a > ethdev API, similar to > rte_eth_dev_rx_queue_intr_enable()/rte_eth_dev_rx_queue_intr_disable(), to > use portiid and queueid as arguments. Then this ethdev API uses the mapped > eventfds to invoke corresponding EAL API, waiting for interrupt event > notification from kernel. A V6 patchset will be created for this. > Ok, I will look at it when available. -- David Marchand
