From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: 3.0.4 (and earlier): skbuff_ctor() use of xen_create_contiguous_region() Date: Fri, 09 Mar 2007 14:06:47 +0000 Message-ID: References: <20070309123724.GQ25301@cheesecake.uk.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070309123724.GQ25301@cheesecake.uk.sun.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: David Edmondson , Jan Beulich Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 9/3/07 12:37, "David Edmondson" wrote: > So that a multi-page packet is physically contiguous when passed to > the NIC for transmit? > > If it's not physically contiguous and the NIC hardware can't do > scatter gather then the driver has to re-allocate and copy. Yes, it was originally intended for drivers that would do dma_map_single() on the whole multi-page network buffer (for receive and/or transmit buffers). Of course we still potentially have this issue and will now end up falling back to swiotlb at the time of the dma_map_single() call. It's only (usually) an issue for jumbo-frame systems since kmalloc() will not usually return page-straddling allocations for sub-page requests. Also the custom allocator did not help the transmit-from-domU case since jumbo packets are always fragged across netfront/netback, and then many drivers will handle fragged packets efficiently. But it could have helped the receive-to-domU case by avoiding an extra copy, as most drivers want to allocate a single contiguous buffer for jumbo frames. -- Keir