Messages in this thread | | | Date | Wed, 13 Oct 2010 17:27:47 -0700 | Subject | Re: [PATCH RFC] tun: dma engine support | From | Dan Williams <> |
| |
[ added Maciej ]
On Mon, Oct 11, 2010 at 1:52 PM, Michael S. Tsirkin <mst@redhat.com> wrote: > Simple hack to use dma engine for tun RX. > Only one skb in flight at the moment. > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > --- > > I am still looking at handling multiple skbs, but > sending this out for early flames and improvement suggestions. > > Loopback testing seems to show only minor performance gains: > this is not really suprising as data is hot in cache already. > Where I would expect this to help more is with incoming > traffic from an external NIC. This still needs to be tested.
Actually it is interesting that you did not see a performance loss because the dma performs the transfer in memory so the destination will be cache cold in the dma case compared to a cpu copy.
[..] > +int tun_dma_copybreak = 0x10000; > +module_param_named(dma_copybreak, tun_dma_copybreak, int, 0644);
What platform are you using for testing? If this proves beneficial we may need to adjust this value to have a platform specific default, similar to how ioatdma sets tcp_dma_copybreak depending on the hardware version. You will notice that on Nehalem class hardware (drivers/dma/ioat/dma_v3.c) the default is set to 256K effectively disabling offload as the overhead of managing the dma engine overshadows any offload advantage.
-- Dan
| |