IPsec policy database customization proposal

[Christophe Gouault <christophe.gouault@6wind.com>]

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