netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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 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).