[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Dom0 physical networking/swiotlb/something issue in 3.7-rc1
Hi Konrad, The following patch causes fairly large packet loss when transmitting from dom0 to the physical network, at least with my tg3 hardware, but I assume it can impact anything which uses this interface. I suspect that the issue is that the compound pages allocated in this way are not backed by contiguous mfns and so things fall apart when the driver tries to do DMA. However I don't understand why the swiotlb is not fixing this up successfully? The tg3 driver seems to use pci_map_single on this data. Any thoughts? Perhaps the swiotlb (either generically or in the Xen backend) doesn't correctly handle compound pages? Ideally we would also fix this at the point of allocation to avoid the bouncing -- I suppose that would involve using the DMA API in netdev_alloc_frag? We have a, sort of, similar situation in the block layer which is solved via BIOVEC_PHYS_MERGEABLE. Sadly I don't think anything similar can easily be retrofitted to the net drivers without changing every single one. Ian. commit 69b08f62e17439ee3d436faf0b9a7ca6fffb78db Author: Eric Dumazet <edumazet@xxxxxxxxxx> Date: Wed Sep 26 06:46:57 2012 +0000 net: use bigger pages in __netdev_alloc_frag We currently use percpu order-0 pages in __netdev_alloc_frag to deliver fragments used by __netdev_alloc_skb() Depending on NIC driver and arch being 32 or 64 bit, it allows a page to be split in several fragments (between 1 and 8), assuming PAGE_SIZE=4096 Switching to bigger pages (32768 bytes for PAGE_SIZE=4096 case) allows : - Better filling of space (the ending hole overhead is less an issue) - Less calls to page allocator or accesses to page->_count - Could allow struct skb_shared_info futures changes without major performance impact. This patch implements a transparent fallback to smaller pages in case of memory pressure. It also uses a standard "struct page_frag" instead of a custom one. Signed-off-by: Eric Dumazet <edumazet@xxxxxxxxxx> Cc: Alexander Duyck <alexander.h.duyck@xxxxxxxxx> Cc: Benjamin LaHaise <bcrl@xxxxxxxxx> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |