All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: "David S. Miller" <davem@davemloft.net>
Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org,
	bdschuym@pandora.be, bridge@osdl.org, snort2004@mail.ru,
	rusty@rustcorp.com.au, dwmw2@infradead.org, ak@suse.de,
	shemminger@osdl.org, gandalf@wlug.westbo.se
Subject: [Bridge] 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


WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2005-01-28  0:08 UTC|newest]

Thread overview: 52+ 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     ` [Bridge] " Stephen Hemminger
2005-01-07 18:00       ` Stephen Hemminger
2005-01-07 18:06       ` [Bridge] " David Woodhouse
2005-01-07 18:06         ` David Woodhouse
2005-01-07 21:27       ` [Bridge] " Bart De Schuymer
2005-01-07 21:27         ` Bart De Schuymer
2005-01-18 21:57         ` [Bridge] " David S. Miller
2005-01-18 21:57           ` David S. Miller
2005-01-22 22:30           ` [Bridge] [PATCH/RFC] Reduce call chain length in netfilter (was: Re: do_IRQ: stack overflow: 872..) Bart De Schuymer
2005-01-22 22:30             ` Bart De Schuymer
2005-01-22 23:22             ` [Bridge] " Martin Josefsson
2005-01-22 23:22               ` Martin Josefsson
2005-01-23 12:40               ` [Bridge] " Bart De Schuymer
2005-01-23 12:40                 ` Bart De Schuymer
2005-01-23 16:08                 ` [Bridge] " Martin Josefsson
2005-01-23 16:08                   ` Martin Josefsson
2005-01-26  6:05                   ` [Bridge] " David S. Miller
2005-01-26  6:05                     ` David S. Miller
2005-01-26  9:08                     ` [Bridge] " Bart De Schuymer
2005-01-26  9:08                       ` Bart De Schuymer
2005-01-26 23:49                       ` [Bridge] Re: [PATCH/RFC] Reduce call chain length in netfilter Patrick McHardy
2005-01-26 23:49                         ` Patrick McHardy
2005-01-27  7:18                         ` [Bridge] " David S. Miller
2005-01-27  7:18                           ` David S. Miller
2005-01-27 17:50                           ` [Bridge] " Patrick McHardy
2005-01-27 17:50                             ` Patrick McHardy
2005-01-27 19:47                             ` [Bridge] " David S. Miller
2005-01-27 19:47                               ` David S. Miller
2005-01-27 21:16                               ` [Bridge] " Bart De Schuymer
2005-01-27 21:16                                 ` Bart De Schuymer
2005-01-27 22:48                               ` [Bridge] " Patrick McHardy
2005-01-27 22:48                                 ` Patrick McHardy
2005-01-27 23:24                                 ` [Bridge] " David S. Miller
2005-01-27 23:24                                   ` David S. Miller
2005-01-28  0:08                                   ` Patrick McHardy [this message]
2005-01-28  0:08                                     ` Patrick McHardy
2005-01-28  0:29                                   ` [Bridge] " Rusty Russell
2005-01-28  0:29                                     ` Rusty Russell
2005-01-28  1:10                                     ` [Bridge] " David S. Miller
2005-01-28  1:10                                       ` David S. Miller
2005-01-28  1:32                                       ` [Bridge] " Rusty Russell
2005-01-28  1:32                                         ` Rusty Russell
2005-01-28  1:35                                         ` [Bridge] " Patrick McHardy
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.