[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADdy8Hq=Pi2PwuA4JLhd2smV7FKSwFLGCDvbCpviSqxhFaKTfg@mail.gmail.com>
Date: Mon, 30 Jun 2014 14:50:18 +0200
From: Christophe Gouault <christophe.gouault@...nd.com>
To: Steffen Klassert <steffen.klassert@...unet.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: IPsec policy database customization proposal
Hi IPsec and network maintainers,
After proposing a patchset to netdev (xfrm: scalability enhancements
for policy database) and discussing with Steffen Klassert, we agree on
the fact that the SPD lookup algorithm needs performance and
scalability improvements: SPs with non-prefixed selectors are
optimized through a hash table, but other SPs (the majority) are
stored in a sorted chained list, which does not scale. Additionally a
flowcache is used, and is known not to scale.
The bottleneck is the SPD lookup by selector (configuration and lookup itself).
Unfortunately, there is no all-in-one multi-field classifier that
would behave well in all situations. However, various classifiers
exist that are fitted to this or that use case. Therefore, I suggest
the following approach: adding hooks in the IPsec SPD, so that one can
dynamically register a custom SPD implementation ("SPD driver") fitted
to its use case, typically by loading a kernel module.
This obviously needs discussion before starting any development, so
here is a more detailed proposal:
- Define the minimum handlers to manipulate the SPD lookup by selector (alloc,
insert, delete, flush, lookup_bysel, lookup_byflow, destroy...).
- export a register/unregister function, so that an SPD implementation may
register/unregister its handlers.
- Separate the SPD common code from the SPD lookup by selector code. Keep the
policy_all and policy_byidx tables in the common code, extract the current
policy_inexact + policy_bydst implementation as an SPD driver. It is the
default implementation when no SPD driver is registered.
- *struct xfrm_policy* must offer a private area for SPD driver data (void * or
opaque place holder of fixed size or opaque place holder of size specific to
driver implementation).
- since we keep the current implementation as the default, the policy_inexact +
policy_bydst database heads (currently stored in netns->xfrm and xfrm_policy
link fields (bydst and flo) may remain at their current location.
- SPD drivers needing some configuration may export their specific
configuration API (/proc, netlink...)
- as a first step, we only support one registered handler at a time.
- as a first step, an SPD driver can only be loaded or unloaded if the SPD is
empty (return EBUSY otherwise).
Remarks:
- this architecture is open to later evolutions such as supporting the
registration of several handlers, dynamically listing/selecting/switching
drivers via netlink messages (to support dynamic change of SPD implementation
according to SPD content).
- loading/unloading or changing SPD drivers with a non empty SPD implies to
rebuild the SPD from the SP list. This may lock the SPD for a rather long
time.
I would like your opinion/questions/advices.
Best Regards,
Christophe
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists