From: Steffen Klassert <steffen.klassert@secunet•com>
To: David Miller <davem@davemloft•net>
Cc: herbert@gondor•apana.org.au, netdev@vger•kernel.org
Subject: Re: [RFC] State resolution packet queue for IPsec
Date: Mon, 4 Feb 2013 09:25:27 +0100 [thread overview]
Message-ID: <20130204082526.GE23291@secunet.com> (raw)
In-Reply-To: <20130122111029.GF9147@secunet.com>
On Tue, Jan 22, 2013 at 12:10:29PM +0100, Steffen Klassert wrote:
> On Mon, Jan 21, 2013 at 04:17:16PM -0500, David Miller wrote:
> >
> > This is probably the best way to solve this problem without adding
> > xfrm_state resolution notifications.
> >
> > But really why would notifications be so bad even if they would not
> > be fine grained?
> >
> > Any time a state is resolved, any state, you run what you have put
> > currently into this new timer function.
> >
>
> When we use state resolution notifiers, we have two problems.
> First, we would probably not dequeue the packets on the same
> cpu we enqueued them, this can introduce packet reorder. The
> timer will at least try to run on the local cpu.
>
> Second, as you already mentioned, even with state resolution
> notifiers, we don't know if the inserted state is the one we
> need and if our state bundle is complete with this state.
> We would need to do a lookup whenever a state is inserted,
> so we hog the cpu that tries to insert the states we need.
>
> With the timer, we don't have these two problems for the price
> that we have take a good choice on the relookup intervals.
> Not sure what's better here.
>
I'd apply the timer version to ipsec-next if there are no objections.
We can still tune it if something does not perform well.
next prev parent reply other threads:[~2013-02-04 8:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-21 9:48 [RFC] State resolution packet queue for IPsec Steffen Klassert
2013-01-21 21:17 ` David Miller
2013-01-22 11:10 ` Steffen Klassert
2013-02-04 8:25 ` Steffen Klassert [this message]
2013-02-04 17:47 ` David Miller
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=20130204082526.GE23291@secunet.com \
--to=steffen.klassert@secunet$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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