From: "David S. Miller" <davem@davemloft.net>
To: Patrick McHardy <kaber@trash.net>
Cc: bdschuym@pandora.be, netdev@oss.sgi.com,
netfilter-devel@lists.netfilter.org, snort2004@mail.ru,
rusty@rustcorp.com.au, ak@suse.de, bridge@osdl.org,
gandalf@wlug.westbo.se, dwmw2@infradead.org, shemminger@osdl.org
Subject: Re: [PATCH/RFC] Reduce call chain length in netfilter
Date: Thu, 27 Jan 2005 15:24:50 -0800 [thread overview]
Message-ID: <20050127152450.6daba4fa.davem@davemloft.net> (raw)
In-Reply-To: <41F96FA4.4000105@trash.net>
On Thu, 27 Jan 2005 23:48:04 +0100
Patrick McHardy <kaber@trash.net> wrote:
> David S. Miller wrote:
>
> >In the generated asm on sparc64, invoke2() gets a tail-call
> >whereas invoke() does not. Hmmm...
>
> Apparently support for indirect tail-calls was added to gcc 3.4.
Good data point.
I've been trying to figure out ways to decrease the number of
args that get sent to nf_hook_slow but this would require
some API changes unfortunately.
One idea goes like this, we create little descriptors of the form:
struct nf_hook_desc {
int (*okfn)(struct sk_buff *);
int pf;
int hook;
};
Then NF_HOOK*() callsites do something like this:
static const struct nf_hook_desc nf_ip_local_out = {
.okfn = dst_output,
.pf = PF_INET,
.hook = NF_IP_LOCAL_OUT,
};
...
/* Send it out. */
return NF_HOOK(&nf_ip_local_out, skb, NULL, rt->u.dst.dev);
This gets us down to 4 arguments from 6. I think we can kill
one more.
It is never the case that both indev and outdev are both
set, so we can use some nf_hook_desc piece of state to
indicate which (in or out) the passed device pointer is.
Oh yes, we can nicely add the thresh thing in here too
while we're at it.
So the final nf_hook_desc might look something something like:
struct nf_hook_desc {
int (*okfn)(struct sk_buff *);
int hook;
int thresh;
u8 pf; /* AF_MAX is 32 */
u8 is_output;
};
Hook could possibly use a smaller type as well to condense
the size of this thing even further. I don't know if there
are any nice assumptions we can make about the hook numbers.
Now, back to the compatability issue. We could create a
new macro, NF_HOOK_DESC() and keep the existing ones around
via some nf_hook_slow() that basically does:
int nf_hook_slow(int pf, unsigned int hook, struct sk_buff *skb,
struct net_device *indev, struct net_device *outdev,
int (*okfn)(struct sk_buff *), int thresh)
{
struct nf_hook_desc desc;
desc.okfn = okfn;
desc.hook = hook;
desc.thresh = thresh;
desc.pf = pf;
desc.is_output = (outdev != NULL);
return nf_hook_desc(&desc, skb, (outdev ? outdev : indev));
}
So the final new stuff looks something like:
#ifdef CONFIG_NETFILTER
struct nf_hook_desc {
int (*okfn)(struct sk_buff *);
int hook;
int thresh;
u8 pf; /* AF_MAX is 32 */
u8 is_output;
};
#define NF_DESC_DECLARE(_name, _okfn, _hook, _thresh, _pf, _is_output) \
static const struct nf_hook_desc _name = { \
.okfn = _okfn, \
.hook = _hook, \
.thresh = _thresh, \
.pf = _pf, \
.is_output = _is_output, \
};
extern int nf_hook_desc(struct nf_hook_desc *desc, struct sk_buff *skb,
struct net_device *dev);
#define NF_HOOK_DESC(_desc, _skb, _dev) \
nf_hook_desc(_desc, _skb, _dev)
#endif
Just throwing around ideas... comments?
next prev parent reply other threads:[~2005-01-27 23:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1131604877.20041218092730@mail.ru.suse.lists.linux.kernel>
2004-12-18 7:50 ` do_IRQ: stack overflow: 872 Andi Kleen
2004-12-18 11:12 ` Bart De Schuymer
2004-12-18 11:14 ` Andi Kleen
2004-12-18 11:51 ` Bart De Schuymer
2004-12-18 13:53 ` Andi Kleen
2004-12-18 16:07 ` Re[2]: " Crazy AMD K7
2004-12-18 16:46 ` Bart De Schuymer
2005-01-07 17:05 ` David Woodhouse
2005-01-07 18:00 ` Stephen Hemminger
2005-01-07 18:06 ` David Woodhouse
2005-01-07 21:27 ` Bart De Schuymer
2005-01-18 21:57 ` David S. Miller
2005-01-22 22:30 ` [PATCH/RFC] Reduce call chain length in netfilter (was: Re: do_IRQ: stack overflow: 872..) Bart De Schuymer
2005-01-22 23:22 ` Martin Josefsson
2005-01-23 12:40 ` Bart De Schuymer
2005-01-23 16:08 ` Martin Josefsson
2005-01-26 6:05 ` David S. Miller
2005-01-26 9:08 ` Bart De Schuymer
2005-01-26 23:49 ` [PATCH/RFC] Reduce call chain length in netfilter Patrick McHardy
2005-01-27 7:18 ` David S. Miller
2005-01-27 17:50 ` Patrick McHardy
2005-01-27 19:47 ` David S. Miller
2005-01-27 21:16 ` Bart De Schuymer
2005-01-27 22:48 ` Patrick McHardy
2005-01-27 23:24 ` David S. Miller [this message]
2005-01-28 0:08 ` Patrick McHardy
2005-01-28 0:29 ` Rusty Russell
2005-01-28 1:10 ` David S. Miller
2005-01-28 1:32 ` Rusty Russell
2005-01-28 1:35 ` Patrick McHardy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050127152450.6daba4fa.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=ak@suse.de \
--cc=bdschuym@pandora.be \
--cc=bridge@osdl.org \
--cc=dwmw2@infradead.org \
--cc=gandalf@wlug.westbo.se \
--cc=kaber@trash.net \
--cc=netdev@oss.sgi.com \
--cc=netfilter-devel@lists.netfilter.org \
--cc=rusty@rustcorp.com.au \
--cc=shemminger@osdl.org \
--cc=snort2004@mail.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).