netdev - Re: Question on IOAT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 5 Feb 2007 21:03:59 +0100
From:	Olaf Kirch <olaf.kirch@...cle.com>
To:	chris.leech@...il.com
Cc:	netdev@...r.kernel.org
Subject: Re: Question on IOAT

On Monday 05 February 2007 19:24, Chris Leech wrote:
> It is busy waiting, but only because the TCP socket use initiates the
> DMA copies from the softirq and they have time to complete during the
> switch back to application context.

But to me it looks as if the code in tcp_recvmsg will also initiate DMA
copies when the user calls recvmsg and there is data queued on the
socket. So in that case, what you end up doing in the same process
context is queue DMA ops -> issue pending -> busy wait. In that case,
sleeping would sound like the right approach, wouldn't it?

> Going back to sleep and creating 
> more context switching made things worse.  I'm working on seeing if
> completion interrupts could be used with a better thought out
> implementation, the performance implications aren't fully clear to me
> yet.
>
> For other uses, interrupts are probably desired.

The NFS client's RPC code hooks into the data_ready callback,
tries to find the task that the reply is going to, and copies the data.
So per your argument above, for the NFS client it should be okay to
busy wait after switching to the task.

This would leave the NFS server, which basically uses some kind
of poll/recvmsg scheme. In essence, it doesn't call recvmsg until
the data has been queued. I guess this kind of code would benefit
from using async IO - then the stack can DMA directly into the
buffer and then wake up the process.

> It's just not there now, but it can be added easily, it's one bit in
> the descriptor and a register read in the interrupt handler to see
> which channel(s) need attention.

Hm, okay.

Olaf
-- 
Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
okir@....de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html