[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] 3.0.4 (and earlier): skbuff_ctor() use of xen_create_contiguous_region()

  • To: David Edmondson <dme@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Fri, 09 Mar 2007 14:06:47 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 09 Mar 2007 06:06:05 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdiVCyya3lI2s5HEduPNwAX8io7RQ==
  • Thread-topic: [Xen-devel] 3.0.4 (and earlier): skbuff_ctor() use of xen_create_contiguous_region()

On 9/3/07 12:37, "David Edmondson" <dme@xxxxxxx> 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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.