All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Gouault <christophe.gouault@6wind.com>
To: David Laight <David.Laight@ACULAB.COM>,
	'Steffen Klassert' <steffen.klassert@secunet.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH ipsec-next 2/2] xfrm: configure policy hash table thresholds by /proc
Date: Fri, 23 May 2014 10:30:13 +0200	[thread overview]
Message-ID: <537F0715.7010207@6wind.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1724B7DA@AcuExch.aculab.com>

On 05/22/2014 12:15 PM, David Laight wrote:
> From: Klassert
> ...
>>> Exporting a userland API (here by /proc) enables a user or a daemon to
>>> choose a strategy according to information the kernel does not
>>> necessarily have, and enables to implement various (possibly complex)
>>> policies.
>>>
>>
>> If we add a user API for the current lookup mechanism, we will stick
>> with this because we can't change it anymore without breaking userspace.
>> So I don't want to add one before we finally decided on a long term
>> lookup mechanism for IPsec.
>
> You could have a user API call to find the list of available mechanisms
> as well as one that returns/sets the current one.
> Then there is no actual requirement to continue to support any specific one.
>
> 	David

Hi David,

It sounds like a brilliant idea, since we will probably need to support
several types of mechanisms. If nobody objects, I can start working on
such API.

Any preference on the type of API? (/proc, netlink, ioctl?...)

Christophe

  reply	other threads:[~2014-05-23  8:30 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-12 13:45 [PATCH ipsec-next 0/2] xfrm: scalability enhancements for policy database Christophe Gouault
2014-05-12 13:45 ` [PATCH ipsec-next 1/2] xfrm: hash prefixed policies based on preflen thresholds Christophe Gouault
2014-05-12 13:45 ` [PATCH ipsec-next 2/2] xfrm: configure policy hash table thresholds by /proc Christophe Gouault
2014-05-15  8:34   ` Steffen Klassert
2014-05-19  7:41     ` Christophe Gouault
2014-05-22 10:09       ` Steffen Klassert
2014-05-22 10:15         ` David Laight
2014-05-23  8:30           ` Christophe Gouault [this message]
2014-08-01  9:12 ` [PATCH net-next v2 0/2] xfrm: scalability enhancements for policy database Christophe Gouault
2014-08-01  9:12   ` [PATCH net-next v2 1/2] xfrm: hash prefixed policies based on preflen thresholds Christophe Gouault
2014-08-01  9:12   ` [PATCH net-next v2 2/2] xfrm: configure policy hash table thresholds by netlink Christophe Gouault
2014-08-01 13:01     ` [PATCH RFC iproute2 0/2] ipxfrm: configuration of SPD hash Christophe Gouault
2014-08-01 13:01       ` [PATCH RFC iproute2 1/2] Update headers to net-next Christophe Gouault
2014-08-01 13:01       ` [PATCH RFC iproute2 2/2] ipxfrm: add command for configuring SPD hash table Christophe Gouault
2014-08-21  6:09     ` [PATCH net-next v2 2/2] xfrm: configure policy hash table thresholds by netlink Steffen Klassert
2014-08-26  7:27       ` Christophe Gouault
2014-08-27 15:48       ` [PATCH ipsec-next v3 0/2] xfrm: scalability enhancements for policy database Christophe Gouault
2014-08-27 15:48         ` [PATCH ipsec-next v3 1/2] xfrm: hash prefixed policies based on preflen thresholds Christophe Gouault
2014-08-27 15:48         ` [PATCH ipsec-next v3 2/2] xfrm: configure policy hash table thresholds by netlink Christophe Gouault
2014-08-29  9:54           ` Steffen Klassert
2014-08-29 10:02             ` Christophe Gouault
2014-08-29 14:16             ` [ipsec-next v4 0/2] xfrm: scalability enhancements for policy database Christophe Gouault
2014-08-29 14:16               ` [ipsec-next v4 1/2] xfrm: hash prefixed policies based on preflen thresholds Christophe Gouault
2014-08-29 14:16               ` [ipsec-next v4 2/2] xfrm: configure policy hash table thresholds by netlink Christophe Gouault
2014-09-03 11:59               ` [ipsec-next v4 0/2] xfrm: scalability enhancements for policy database Steffen Klassert
2014-09-03 12:53                 ` Christophe Gouault
2014-08-04 22:09   ` [PATCH net-next v2 " 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=537F0715.7010207@6wind.com \
    --to=christophe.gouault@6wind.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.