netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Patrick McHardy <kaber@trash.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH 2/2] netfilter: conntrack: optional reliable conntrack event	delivery
Date: Wed, 10 Jun 2009 14:22:05 +0200	[thread overview]
Message-ID: <4A2FA56D.4090105@netfilter.org> (raw)
In-Reply-To: <4A2F9BB8.8020701@trash.net>

Patrick McHardy wrote:
> This is a first attempt to replace some global locks by private
> per conntrack locks. On 64 bit, it fits into a hole and doesn't
> enlarge struct nf_conn.
> 
> Wrt. to the event cache, we certainly don't want to take and release
> the lock for every event. I was thinking about something like this:
> 
> - add a new member to the event structure to hold undelivered events
>   (named "missed" below)
> - cache events in the existing member as you're doing currently
> - on delivery, do something like this:
> 
>     events = xchg(&e->cache, 0);
>     missed = e->missed;
               ^^^
I think that we need to take the lock since we read e->missed, I see
this possible issue:

CPU0 gets a copy of the missed events (without taking the lock)
CPU1 has already delivered the missed events, it clears them
CPU0 delivers missed events that were already delivered by CPU1.

>     ret = notify->fcn(events | missed, &item);
>     if (!success || missed) {
>         spin_lock_bh(&ct->lock);
>         if (!success)
>             e->missed |= events;
>         else
>             e->missed &= ~missed;
>         spin_unlock_bh(&ct->lock);
>     }
> 
> so if we failed to deliver the events, we add them to the missed
> events for the next delivery attempt. Once we've delivered the
> missed events, we clear them from the cache.
> 
> Now is that really better - I'm not sure myself :) The per-conntrack
> locking would be an improvement though. What do you think?

Indeed, I also think that the per-conntrack locking would be an
improvement for the protocol helpers.

wrt. the event cache, the missed field can save us from doing the
locking in every event caching at the cost of consuming a bit more of
memory. I think this is more conservative but safer than my approach (no
potential defering by calling cmpxchg forever, even if it's unlikely).
Still, we would need to take the spin lock for the event delivery. Let
me know what you think.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers

  reply	other threads:[~2009-06-10 12:22 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-04 11:07 [PATCH 0/2] Pablo Neira Ayuso
2009-06-04 11:08 ` [PATCH 1/2] netfilter: conntrack: move event cache to conntrack extension infrastructure Pablo Neira Ayuso
2009-06-04 12:16   ` Pablo Neira Ayuso
2009-06-05 11:04   ` Patrick McHardy
2009-06-05 13:06     ` Pablo Neira Ayuso
2009-06-05 14:13       ` Patrick McHardy
2009-06-06  6:24         ` Pablo Neira Ayuso
2009-06-04 11:08 ` [PATCH 2/2] netfilter: conntrack: optional reliable conntrack event delivery Pablo Neira Ayuso
2009-06-05 14:37   ` Patrick McHardy
2009-06-06  6:34     ` Pablo Neira Ayuso
2009-06-08 13:49       ` Patrick McHardy
2009-06-09 22:36     ` Pablo Neira Ayuso
2009-06-09 22:43       ` Patrick McHardy
2009-06-09 22:45         ` Patrick McHardy
2009-06-09 22:58           ` Pablo Neira Ayuso
2009-06-10  1:18             ` Eric Dumazet
2009-06-10  9:55               ` Patrick McHardy
2009-06-10 10:36                 ` Pablo Neira Ayuso
2009-06-10 10:55                   ` Patrick McHardy
2009-06-10 11:01                     ` Patrick McHardy
2009-06-10 11:40                       ` Patrick McHardy
2009-06-10 12:22                         ` Pablo Neira Ayuso [this message]
2009-06-10 12:27                           ` Patrick McHardy
2009-06-10 12:43                             ` Pablo Neira Ayuso
2009-06-10 12:56                               ` Patrick McHardy
2009-06-10 12:26                         ` Jozsef Kadlecsik
2009-06-10 12:30                           ` Patrick McHardy
2009-06-10 12:41                             ` Patrick McHardy
2009-06-04 11:17 ` [PATCH 0/2] reliable per-conntrack event cache Pablo Neira Ayuso
  -- strict thread matches above, loose matches on Subject: below --
2009-05-04 13:53 [PATCH 0/2] conntrack event subsystem updates for 2.6.31 (part 2) Pablo Neira Ayuso
2009-05-04 13:53 ` [PATCH 2/2] netfilter: conntrack: optional reliable conntrack event delivery Pablo Neira Ayuso
2009-05-04 14:02   ` Pablo Neira Ayuso

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=4A2FA56D.4090105@netfilter.org \
    --to=pablo@netfilter.org \
    --cc=eric.dumazet@gmail.com \
    --cc=kaber@trash.net \
    --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).