From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id F08D28E66 for ; Fri, 2 Oct 2015 16:00:18 +0200 (CEST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 512F2C1A128D; Fri, 2 Oct 2015 14:00:18 +0000 (UTC) Received: from redhat.com (ovpn-116-85.ams2.redhat.com [10.36.116.85]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t92E0F8K031793; Fri, 2 Oct 2015 10:00:16 -0400 Date: Fri, 2 Oct 2015 17:00:14 +0300 From: "Michael S. Tsirkin" To: Alexander Duyck Message-ID: <20151002165033-mutt-send-email-mst@redhat.com> References: <20151001120027-mutt-send-email-mst@redhat.com> <560CFB66.5050904@scylladb.com> <20151001124211-mutt-send-email-mst@redhat.com> <560D0413.5080401@scylladb.com> <20151001131754-mutt-send-email-mst@redhat.com> <20151001110806.GA16248@bricha3-MOBL3> <20151001141124-mutt-send-email-mst@redhat.com> <20151001120713.GA11504@bricha3-MOBL3> <20151001155943-mutt-send-email-mst@redhat.com> <560D9F60.6040907@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560D9F60.6040907@gmail.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Cc: "dev@dpdk.org" , Avi Kivity Subject: Re: [dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance 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: Fri, 02 Oct 2015 14:00:19 -0000 On Thu, Oct 01, 2015 at 02:02:24PM -0700, Alexander Duyck wrote: > validation and translation would add 10s if not 100s of nanoseconds to the > time needed to process each packet. In addition we are talking about doing > this in kernel space which means we wouldn't really be able to take > advantage of things like SSE or AVX instructions. Yes. But the nice thing is that it's rearming so it can happen on a separate core, in parallel with packet processing. It does not need to add to latency. You will burn up more CPU, but again, all this for boxes/hypervisors without an IOMMU. I'm sure people can come up with even better approaches, once enough people get it that kernel absolutely needs to be protected from userspace. Long term, the right thing to do is to focus on IOMMU support. This gives you hardware-based memory protection without need to burn up CPU cycles. -- MST