From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f68.google.com (mail-it0-f68.google.com [209.85.214.68]) by dpdk.org (Postfix) with ESMTP id 80DD15598 for ; Wed, 12 Oct 2016 10:14:36 +0200 (CEST) Received: by mail-it0-f68.google.com with SMTP id m138so3526635itm.0 for ; Wed, 12 Oct 2016 01:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Yxb+aVo+AUC467Un8tv5a8reLTVOxR41mJEkdItFvH0=; b=0deZOg2Vm5jbUQUISxmm13VLZYgVTORsJ6847k53cD5V0JsiMRR6esn/Ulo990XEJP GyOGu3elCMDmTz57umQhNnWJRLi64GGNwBsZVM1TAQmTWlbCPISbq1hE11vEZXDaxY4y h0TmpjxY/cFI9hn8KF10aV5ZbtwKwhzaf/YCZInU9vNS9RHSkhJQtk/QyigRc4xAnMXR X4CalhLgD/sZjrKhTT7d77fFA/7mddjVE2jlsJGdA8sO3bciMBdTfoDZjMvY9PkI0mnq ao5LhE46jZp1zW+3IqWWr/akmLcbsgOZAkOFtz5aHsgjxDS/6R1vSGWssz4ldhl62rVK oM0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Yxb+aVo+AUC467Un8tv5a8reLTVOxR41mJEkdItFvH0=; b=O0oAuM3XtTK8jTUgeHQRyPdbhbKdL2etcTI0Ybsp5poUtbe0g83rfrFE4sZTy0M37q A/ltx6Mr+LhrzOlmt9wdJ/UZB9AWTb9xhSptg17hPgWR80oWA6Dq1xP5u0IUFU6ZYXyQ ehPBTLYQy1B5/T9yrJjMWrG3IBhkpx2C2dk+nmvI3dU00Fy0bnEHPVte4R+t+FOd4L5I 7Apwj9h+EEkAXKvgkdDSY1ODmlHK2Kvu1IUb67qxbzQMxdVjfmUC8H6CtuVnuocSHhRn qMLAzEm5lCtJ+QyfCiGVrKf5viy+/N+HPysqDUreFaqPAgCiZ6XwEZj7dpkiTWXabG3m 6jEQ== X-Gm-Message-State: AA6/9Rl4H40gefpLkKtrfW+ygQKCjzP688I0jtY1iavVobPUG7Q293ostSupuCKoQZ/K/sfxFNB13CHMToJtPg== X-Received: by 10.36.153.194 with SMTP id a185mr1283695ite.70.1476260075904; Wed, 12 Oct 2016 01:14:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.2.229 with HTTP; Wed, 12 Oct 2016 01:14:15 -0700 (PDT) In-Reply-To: <0685C9CE-94DC-43E4-A34B-17912E51B5ED@intel.com> References: <1474423220-10207-1-git-send-email-keith.wiles@intel.com> <1475592311-25749-1-git-send-email-keith.wiles@intel.com> <0685C9CE-94DC-43E4-A34B-17912E51B5ED@intel.com> From: =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= Date: Wed, 12 Oct 2016 10:14:15 +0200 Message-ID: To: "Wiles, Keith" Cc: "dev@dpdk.org" , "pmatilai@redhat.com" , "yuanhan.liu@linux.intel.com" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v4] drivers/net:new PMD using tun/tap host interface 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, 12 Oct 2016 08:14:36 -0000 2016-10-11 22:56 GMT+02:00 Wiles, Keith : >> On Oct 11, 2016, at 6:30 AM, Micha=C5=82 Miros=C5=82aw wrote: >> >> 2016-10-04 16:45 GMT+02:00, Keith Wiles : >>> The rte_eth_tap.c PMD creates a device using TUN/TAP interfaces >>> on the local host. The PMD allows for DPDK and the host to >>> communicate using a raw device interface on the host and in >>> the DPDK application. The device created is a Tap device with >>> a L2 packet header. >> [...] >>> +static uint16_t >>> +pmd_rx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts) >>> +{ >>> + int len, n; >>> + struct rte_mbuf *mbuf; >>> + struct rx_queue *rxq =3D queue; >>> + struct pollfd pfd; >>> + uint16_t num_rx; >>> + unsigned long num_rx_bytes =3D 0; >>> + >>> + pfd.events =3D POLLIN; >>> + pfd.fd =3D rxq->fd; >>> + for (num_rx =3D 0; num_rx < nb_pkts; ) { >>> + n =3D poll(&pfd, 1, 0); >>> + >>> + if (n <=3D 0) >>> + break; >>> + >> >> Considering that syscalls are rather expensive, it would be cheaper to >> allocate an mbuf here and free it when read() returns -1 instead of >> calling poll() to check whether a packet is waiting. This way you >> save a syscall per packet and replace one syscall with one mbuf free >> per poll. > > I made this change, but saw no performance difference in the two methods.= Removing poll seems reasonable as it is simpler. TAP is already so slow is= why the performance did not change is my guess. Anyone wanting to use TAP = as a high performance interface is going to be surprised. I believe the bes= t use case for the TAP interface is for control or exception path. Agreed, TAP does not look like designed for performance as a first goal. You could do the same simplification for TX path, BTW. Best Regards, Micha=C5=82 Miros=C5=82aw