From: Patrick McHardy <kaber@trash.net>
To: Holger Eitzenberger <holger@eitzenberger.org>
Cc: David Miller <davem@davemloft.net>,
netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [patch 0/6] netfilter: ctnetlink allocation improvement
Date: Tue, 17 Mar 2009 05:35:47 +0100 [thread overview]
Message-ID: <49BF28A3.3010606@trash.net> (raw)
In-Reply-To: <20090316220659.756862181@jonathan.eitzenberger.org>
Holger Eitzenberger wrote:
> what follows is a small patchset against net-next-2.6 which tries to
> improve the way ctnetlink events are allocated. By allocating the
> ctnetlink skbs roughly the size of the message we prevent the skb from
> later being reallocated in netlink_trim().
>
> Though I haven't got any hard performance numbers yet I think this
> might introduce a noticable performance gain.
>
> The overall idea of these patches is to compute the proto independant
> attribute sizes at compile time, the proto-dependant parts are
> computed at registration of the actual proto helpers. This is
> achieved by introducing nla_policy_len(), which computes the max.
> length of a nla_policy.
>
> I also have to introduce NF_CT_HELPER_NAME_LEN as an upper limit for
> the conntrack protcol helper names, which is not much of a problem
> because all names in mainline are actually shorter than that.
The helper name change is fine. We currently have a limit of 30
in the helper match, but that is just as arbitrary and 16 does
seem like enough. In fact I need the same change for nftables :)
> It would be great to have that being merged. Please share youre
> comments.
These patches look almost perfect, there's just one minor thing
that should be fixed from my perspective (from patch 4):
> + l3proto = nf_ct_l3proto_find_get(tuple->src.l3num);
> + len += l3proto->nla_size;
> + nf_ct_l3proto_put(l3proto);
> +
> + l4proto = nf_ct_l4proto_find_get(tuple->src.l3num, tuple->dst.protonum);
> + len += l4proto->nla_size;
> + nf_ct_l4proto_put(l4proto);
> +
> + return alloc_skb(len, gfp);
Its preferrable not to use module reference counting during packet
processing, the protocols can be accessed safely using RCU. I thought
I had fixed all those areas, but I now notice that ctnetlink is full
of similar spots and takes and drops module references quite
excessively. So just leave it as it is I guess, this should be fully
fixed anyways.
I'll wait a few hours for others to comment before applying your
patches.
next prev parent reply other threads:[~2009-03-17 4:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-16 22:06 [patch 0/6] netfilter: ctnetlink allocation improvement Holger Eitzenberger
2009-03-16 22:07 ` [patch 1/6] ctnetlink: add callbacks to the per-proto nlattrs Holger Eitzenberger
2009-03-25 17:25 ` Patrick McHardy
2009-03-16 22:07 ` [patch 2/6] netlink: add nla_policy_len() Holger Eitzenberger
2009-03-25 17:27 ` Patrick McHardy
2009-03-16 22:07 ` [patch 3/6] netfilter: limit the length of the helper name Holger Eitzenberger
2009-03-25 17:32 ` Patrick McHardy
2009-03-25 17:41 ` Holger Eitzenberger
2009-03-25 17:44 ` Patrick McHardy
2009-03-16 22:07 ` [patch 4/6] ctnetlink: allocate right-sized ctnetlink skb Holger Eitzenberger
2009-03-25 17:46 ` Patrick McHardy
2009-03-16 22:07 ` [patch 5/6] netfilter: add generic function to get len of generic policy Holger Eitzenberger
2009-03-16 22:07 ` [patch 6/6] netfilter: calculate per-protocol nlattr size Holger Eitzenberger
2009-03-17 4:35 ` Patrick McHardy [this message]
2009-03-17 7:39 ` [patch 0/6] netfilter: ctnetlink allocation improvement Holger Eitzenberger
2009-03-17 9:07 ` Florian Westphal
2009-03-17 10:24 ` Pablo Neira Ayuso
2009-03-17 9:49 ` Pablo Neira Ayuso
2009-03-17 10:03 ` Holger Eitzenberger
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=49BF28A3.3010606@trash.net \
--to=kaber@trash.net \
--cc=davem@davemloft.net \
--cc=holger@eitzenberger.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
/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.