>From: Jeff Garzik [mailto:[EMAIL PROTECTED] > >Andi Kleen wrote: >> Index: linux-2.6.24-rc1-hack/arch/x86_64/Kconfig >> =================================================================== >> --- linux-2.6.24-rc1-hack.orig/arch/x86_64/Kconfig >> +++ linux-2.6.24-rc1-hack/arch/x86_64/Kconfig >> @@ -753,7 +753,6 @@ config PCI_DOMAINS >> config DMAR >> bool "Support for DMA Remapping Devices (EXPERIMENTAL)" >> depends on PCI_MSI && ACPI && EXPERIMENTAL >> - default y >> help >> DMA remapping (DMAR) devices support enables >independent address >> translations for Direct Memory Access (DMA) from devices. > >ACK > > >> Index: linux-2.6.24-rc1-hack/drivers/dma/Kconfig >> =================================================================== >> --- linux-2.6.24-rc1-hack.orig/drivers/dma/Kconfig >> +++ linux-2.6.24-rc1-hack/drivers/dma/Kconfig >> @@ -43,7 +43,6 @@ comment "DMA Clients" >> config NET_DMA >> bool "Network: TCP receive copy offload" >> depends on DMA_ENGINE && NET >> - default y >> help >> This enables the use of DMA engines in the network stack to >> offload receive copy-to-user operations, freeing CPU cycles. > >ACK -- but its arguable that given the current code, its worth setting >this if DMA_ENGINE is also set. >
The intent is to give us a DMA offload for NIC-to-user operations. At the moment the ioatdma device is the only gizmo supporting this through NET_DMA, and is the only DMA_ENGINE supported on x86. As more devices are made available through DMA_ENGINE on platforms that don't have ioatdma, removing the "default y" makes sense. I agree that this is ACK-able, but under the "it should just work" philosophy, and with the Intel servers coming out with the hardware support, it may want to wait until there are more DMA_ENGINE choices. In any case, I'll ACK this and let the maintainers decide on the timing. sln - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
