From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by dpdk.org (Postfix) with ESMTP id D2D978D8D for ; Fri, 2 Oct 2015 17:56:12 +0200 (CEST) Received: by wiclk2 with SMTP id lk2so37012268wic.1 for ; Fri, 02 Oct 2015 08:56:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to; bh=94HMB5OHDUR8HACQ71Jas1LQtuRGwYpKrWAeas1yvTo=; b=iI2pE3Zkdx6ODedrgEdqWDnmqVY48uJgC/JyvGC92Sf/vzHFPnstd2XVxwfvuRyCmH /dsmNqqL7o3IFWZ/UOF1dLUeW8d/5/yZ8pO11y4LeoE4Z2QZPWzBkp6YgZhNVpPhbynT JwbBjy6jgCYdbGxKJnv3H8UGDC1/Aftupdsg8Eqx8+0+ZHDF1f5pZZV+DQ3PyoV8/PP2 IgKKTMiHx5292W2YBr8B7wyA8zCGHZ0y1ZVRHhWUQh/bXa+mpF6etJN7Bk/p21iMx7tH c47pFnzkpFcBJ0UbN0HqarZl1X2mnnX4wHNIY0Q1+v62tAsJVYcZCVLH8Ss/vJaoR05G E/LQ== X-Gm-Message-State: ALoCoQknaSIcXDgY8lcPtjvt8PIVXaxxWQed8dgVq+AR6lWHNCERfpA7w/IZLyFFuakNHGBjrw9/ X-Received: by 10.180.39.175 with SMTP id q15mr5433925wik.73.1443801372631; Fri, 02 Oct 2015 08:56:12 -0700 (PDT) Received: from trex.cloudius-systems.com ([2002:546f:9be1:0:e8b:fdff:fe2d:f361]) by smtp.gmail.com with ESMTPSA id bs8sm11947748wjc.47.2015.10.02.08.56.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2015 08:56:11 -0700 (PDT) Received: by trex.cloudius-systems.com (Postfix, from userid 1042) id A101283F52; Fri, 2 Oct 2015 18:56:08 +0300 (IDT) Date: Fri, 2 Oct 2015 18:56:08 +0300 From: Gleb Natapov To: "Michael S. Tsirkin" Message-ID: <20151002155608.GA21311@scylladb.com> References: <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> <20151002165033-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151002165033-mutt-send-email-mst@redhat.com> 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 15:56:13 -0000 On Fri, Oct 02, 2015 at 05:00:14PM +0300, Michael S. Tsirkin wrote: > 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. > Modern nics have no less queues than most machines has cores. There is no such thing as free core to offload you processing to, otherwise you designed your application wrong and waste cpu cycles. > 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. > People should not "get" things which are, lets be polite here, untrue. The kernel never tried to protect itself from userspace rumning on behalf of root. Secure boot, which is quite recent, is may be an only instance where kernel tries to do so (unfortunately) and it does so by disabling things if boot is secure. Linux was always "jack of all trades" and was suitable to run on a machine with secure boot and a vm that acts as application container or embedded device running packet forwarding. the only valid point is that nobody should debug crashes that may be caused by buggy userspace and tainting kernel solves that. > 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 -- Gleb.