[dpdk-dev] [PATCH v5 5/6] eal: add per rx queue interrupt handling based on VFIO

Thomas Monjalon thomas.monjalon at 6wind.com
Wed Feb 25 16:44:04 CET 2015


Please Danny, click on the button "uninstall Outlook"
or configure it to have quote marks.
This email is really hard to read.

2015-02-25 15:29, Zhou, Danny:
> 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
> 
> Hello Danny,
> 
> On Wed, Feb 25, 2015 at 7:58 AM, Zhou, Danny <danny.zhou at intel.com<mailto:danny.zhou at intel.com>> wrote:
> 
> +int
> +rte_intr_wait_rx_pkt(struct rte_intr_handle *intr_handle, uint8_t queue_id)
> +{
> +       struct epoll_event ev;
> +       unsigned numfds = 0;
> +
> +       if (!intr_handle || intr_handle->fd < 0 || intr_handle->uio_cfg_fd < 0)
> +               return -1;
> +       if (queue_id >= VFIO_MAX_QUEUE_ID)
> +               return -1;
> +
> +       /* create epoll fd */
> +       int pfd = epoll_create(1);
> +       if (pfd < 0) {
> +               RTE_LOG(ERR, EAL, "Cannot create epoll instance\n");
> +               return -1;
> +       }
> 
> Why recreate the epoll instance at each call to this function ?
> 
> 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.

EAL means Environment Abstraction Layer.
In my mind, OS is part of the environment.
DPDK components don't invoke Linux specific APIs, they use EAL!
What are you thinking about?

> Adding an abstraction here specifically for epoll does not resolve all the porting/migration problem in my mind.



More information about the dev mailing list