From: Patrick McHardy <kaber@trash.net>
To: "David S. Miller" <davem@davemloft.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: Fri, 28 Jan 2005 01:08:54 +0100 [thread overview]
Message-ID: <41F98296.9040804@trash.net> (raw)
In-Reply-To: <20050127152450.6daba4fa.davem@davemloft.net>
David S. Miller wrote:
>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.
>
>
indev and outdev are both set in the forward hook.
>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.
>
>
There are currently five hooks. I really hope we'll never reach
256, so u8 should be big enough.
>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?
>
>
Sounds like a good idea to get rid of the static arguments to
nf_hook_slow. Keeping both devices we are still down from 7 to
4 arguments with your suggestion.
Regards
Patrick
next prev parent reply other threads:[~2005-01-28 0:08 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
2005-01-28 0:08 ` Patrick McHardy [this message]
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=41F98296.9040804@trash.net \
--to=kaber@trash.net \
--cc=ak@suse.de \
--cc=bdschuym@pandora.be \
--cc=bridge@osdl.org \
--cc=davem@davemloft.net \
--cc=dwmw2@infradead.org \
--cc=gandalf@wlug.westbo.se \
--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).