[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABE8wwvi_Yz8AyALr1-uDW9xSgrSqfrYWhB_22NQ2ydTa81+mg@mail.gmail.com>
Date: Mon, 23 Apr 2012 11:30:33 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Jiang Liu <liuj97@...il.com>
Cc: Vinod Koul <vinod.koul@...el.com>,
Jiang Liu <jiang.liu@...wei.com>,
Keping Chen <chenkeping@...wei.com>,
"David S. Miller" <davem@...emloft.net>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
James Morris <jmorris@...ei.org>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Patrick McHardy <kaber@...sh.net>, netdev@...r.kernel.org,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 6/8] dmaengine: enhance network subsystem to support
DMA device hotplug
On Mon, Apr 23, 2012 at 6:51 AM, Jiang Liu <liuj97@...il.com> wrote:
> Enhance network subsystem to correctly update DMA channel reference counts,
> so it won't break DMA device hotplug logic.
>
> Signed-off-by: Jiang Liu <liuj97@...il.com>
This introduces an atomic action on every channel touch, which is more
expensive than what we had previously. There has always been a
concern about the overhead of offload that sometimes makes ineffective
or a loss compared to cpu copies. In the cases where net_dma shows
improvement this will eat into / maybe eliminate that advantage.
Take a look at where dmaengine started [1]. It was from the beginning
going through contortions to avoid something like this. We made it
simpler here [2], but still kept the principle of not dirtying a
shared cacheline on every channel touch, and certainly not locking it.
If you are going to hotplug the entire IOH, then you are probably ok
with network links going down, so could you just down the links and
remove the driver with the existing code?
--
Dan
[1]: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=c13c826
[2]: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=6f49a57a
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists