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 611668D91 for ; Thu, 1 Oct 2015 13:09:34 +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 C901EC0B64D6; Thu, 1 Oct 2015 11:09:33 +0000 (UTC) Received: from redhat.com (ovpn-116-83.ams2.redhat.com [10.36.116.83]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t91B9UjX020497; Thu, 1 Oct 2015 07:09:32 -0400 Date: Thu, 1 Oct 2015 14:09:30 +0300 From: "Michael S. Tsirkin" To: Avi Kivity Message-ID: <20151001135054-mutt-send-email-mst@redhat.com> References: <560C0171.7080507@scylladb.com> <20150930204016.GA29975@redhat.com> <20151001113828-mutt-send-email-mst@redhat.com> <560CF44A.60102@scylladb.com> <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> <560D0FE2.7010905@scylladb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560D0FE2.7010905@scylladb.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Cc: "dev@dpdk.org" 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: Thu, 01 Oct 2015 11:09:34 -0000 On Thu, Oct 01, 2015 at 01:50:10PM +0300, Avi Kivity wrote: > > > >>It's not just the lack of system calls, of course, the architecture is > >>completely different. > >Absolutely - I'm not saying move all of DPDK into kernel. > >We just need to protect the RX rings so hardware does > >not corrupt kernel memory. > > > > > >Thinking about it some more, many devices > >have separate rings for DMA: TX (device reads memory) > >and RX (device writes memory). > >With such devices, a mode where userspace can write TX ring > >but not RX ring might make sense. > > I'm sure you can cause havoc just by reading, if you read from I/O memory. Not talking about I/O memory here. These are device rings in RAM. > > > >This will mean userspace might read kernel memory > >through the device, but can not corrupt it. > > > >That's already a big win! > > > >And RX buffers do not have to be added one at a time. > >If we assume 0.2usec per system call, batching some 100 buffers per > >system call gives you 2 nano seconds overhead. That seems quite > >reasonable. > > You're ignoring the page table walk Some caching strategy might work here. > and other per-descriptor processing. You probably can let userspace pre-format it all, just validate addresses. > Again^2, maybe this can work. But it shouldn't block a patch enabling > interrupt support of VFs. After the ring proxy is available and proven for > a few years, we can deprecate bus mastering from uio, and after a few more > years remove it. We are talking about DPDK patches posted in June 2015. It's not some software proven for years. If Linux keeps enabling hacks, no one will bother doing the right thing. Upstream inclusion is the only carrot Linux has to make people do the right thing. -- MST