Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755596Ab0FTPTY (ORCPT ); Sun, 20 Jun 2010 11:19:24 -0400 Received: from mail.solarflare.com ([216.237.3.220]:47211 "EHLO exchange.solarflare.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755226Ab0FTPTU (ORCPT ); Sun, 20 Jun 2010 11:19:20 -0400 Subject: Re: [RFC PATCH v7 01/19] Add a new structure for skb buffer from external. From: Ben Hutchings To: Herbert Xu Cc: "Michael S. Tsirkin" , "Xin, Xiaohui" , Stephen Hemminger , "netdev@vger.kernel.org" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "mingo@elte.hu" , "davem@davemloft.net" , "jdike@linux.intel.com" , Rusty Russell In-Reply-To: <20100620115926.GA31849@gondor.apana.org.au> References: <20100618055929.GA11333@gondor.apana.org.au> <20100620100631.GB4578@redhat.com> <20100620103235.GA31284@gondor.apana.org.au> <20100620103909.GA5285@redhat.com> <20100620110254.GA31484@gondor.apana.org.au> <20100620111124.GB5285@redhat.com> <20100620113609.GA31693@gondor.apana.org.au> <20100620114719.GC5285@redhat.com> <20100620115926.GA31849@gondor.apana.org.au> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Sun, 20 Jun 2010 16:19:14 +0100 Message-ID: <1277047154.14011.880.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2010 15:19:53.0226 (UTC) FILETIME=[08616EA0:01CB108C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.000.1038-17456.005 X-TM-AS-Result: No--33.528000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1587 Lines: 35 On Sun, 2010-06-20 at 21:59 +1000, Herbert Xu wrote: > On Sun, Jun 20, 2010 at 02:47:19PM +0300, Michael S. Tsirkin wrote: > > > > Let's do this then. So far the virtio spec avoided making layout > > assumptions, leaving guests lay out data as they see fit. > > Isn't it possible to keep supporting this with zero copy for hardware > > that can issue DMA at arbitrary addresses? > > I think you're mistaken with respect to what is being proposed. > Raising 512 bytes isn't a hard constraint, it is merely an > optimisation for Intel NICs because their PS mode can produce > a head fragment of up to 512 bytes. > > If the guest didn't allocate 512 bytes it wouldn't be the end of > the world, it'd just mean that we'd either copy whatever is in > the head fragment, or we waste 4096-X bytes of memory where X > is the number of bytes in the head. If I understand correctly what this 'PS mode' is (I haven't seen the documentation for it), it is a feature that Microsoft requested from hardware vendors for use in Hyper-V. As a result, the SFC9000 family and presumably other controllers also implement something similar. Ben. -- Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/