netdev - Re: [PATCH net-next] xfrm: Call IP receive handler directly for inbound tunnel-mode packets

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 03 Jan 2012 12:56:37 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	eric.dumazet@...il.com
Cc:	herbert@...dor.hengli.com.au, david.ward@...mit.edu,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] xfrm: Call IP receive handler directly for
 inbound tunnel-mode packets

From: Eric Dumazet <eric.dumazet@...il.com>
Date: Mon, 02 Jan 2012 09:18:02 +0100

> if (skb->data - skb->head < DEPTH_THRESHOLD)
> 	netif_receive_skb(skb);

Fundamentally I think such things are doomed to failure.

I encourage you to instead look into the idea proposed the other year
(but unfortunately I found no time to implement) wherein we have a
top-level looping structure.

The scheme was originally proposed for TX but we can do it just as easily
for RX too.  Essentially the entity that begins the traversal into the
packet send or receive path makes a mark in some per-cpu data structure.

When we return to the mark setting spot, we check if any "continued
processing" work got queued there, and run it if so, keeping the mark
set.  Once the queued work is rechecked and found to be all clear, we
clear the mark and finish.

This has performance benefits too because on both the TX and RX side
we'll stop this whole dance where we schedule a SW interrupt and incr
all the overhead necessary to do that.

It's going to be faster than your threshold test scheme because we'll
be using a smaller stack frame and thus get better cache hits there.
--
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