From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by dpdk.org (Postfix) with ESMTP id 2CD695A43 for ; Wed, 25 Feb 2015 16:44:40 +0100 (CET) Received: by wggy19 with SMTP id y19so4435778wgg.10 for ; Wed, 25 Feb 2015 07:44:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=/IIQGnjUz+vRtFuUjXAqJD74BMYPeSa2GC3dp8I4/AM=; b=dAAMLegxTMn6T339UWwb0NTRLK3V9VS0ImxTI0dMZNRe3+Ak98X0EXW3QrL/yGThx2 3HBjrzJRb1Xk2LlCdFMFu0J+RbW2f6xCA3nvcStoSE/rhiycsrFuPzqswyAlI4m6sLxG hZ3ZoViRpz/bp65LG1Jmq66Zsboywjz726SqNGJXphNKd937YaTAjmLol8WNFn1QuP8/ 6reuvjThRTBYttX8QHpNiYhmK5k5ZvVBwWQaNiRuPBSzY+uXacw+eY+9gZZAXNqm8NWs 4ensGqKkKuUpewy6oosn4gH8i+DoMn9uKatiUSZipAzGH3VvoJepoVwe3OBuKWLpzYx+ a1zg== X-Gm-Message-State: ALoCoQmatZoshZ7JW+7oTuetWU9YDODiHu4lk071IYyM0nxJboTfK9ik0w2l7zZfNTFlYBUbGAtu X-Received: by 10.180.99.194 with SMTP id es2mr7592170wib.23.1424879079076; Wed, 25 Feb 2015 07:44:39 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id l4sm25642106wiw.9.2015.02.25.07.44.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Feb 2015 07:44:38 -0800 (PST) From: Thomas Monjalon To: "Zhou, Danny" Date: Wed, 25 Feb 2015 16:44:04 +0100 Message-ID: <3146058.vTVU0j4VY5@xps13> Organization: 6WIND User-Agent: KMail/4.14.4 (Linux/3.18.4-1-ARCH; KDE/4.14.4; x86_64; ; ) In-Reply-To: References: <1424710542-14637-1-git-send-email-danny.zhou@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v5 5/6] eal: add per rx queue interrupt handling based on VFIO X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2015 15:44:40 -0000 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@6wind.com] > Sent: Wednesday, February 25, 2015 6:22 PM > To: Zhou, Danny > Cc: dev@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 > 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.