netdev - Re: [Just for fun] loopback: avoid softirq on most transmits

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20101028.130917.179938102.davem@davemloft.net>
Date:	Thu, 28 Oct 2010 13:09:17 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	netdev@...r.kernel.org
Subject: Re: [Just for fun] loopback: avoid softirq on most transmits

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Thu, 28 Oct 2010 21:48:46 +0200

> With the introduction of xmit_recursion percpu variable, its pretty
> cheap to check our recursion level in loopback transmit, and avoid
> raising softirq.
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@...il.com>
> ---
> tbench faster by 4%, sorry I couldnt resist...

Hehehe :-)

Maybe even that limit is low enough to prevent stack overflow
situations even when doing NFS over a loopback to a raid volume using
XFS as the filesystem which seems to be the standard stack usage
stress test.

But really, just like DST iteration, we should probably make these
things more iterative.

The cool thing about loopback is that we have a trigger for the cases
we care about, release_sock().

So we could have something like:

1) lock_sock() sets "local cpu will run release_sock()" mark.

2) netif_rx() checks mark, if set it puts SKB on "release_sock()
   local cpu work queue"

3) release_sock() retains mark, and runs SKB queue until empty.
   Once SKB work queue is empty, mark is cleared.

Anyways, just an idea.
--
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