[Top] [All Lists]

Re: resend patch: xfrm policybyid

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: resend patch: xfrm policybyid
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 8 May 2005 18:07:30 +1000
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev <netdev@xxxxxxxxxxx>
In-reply-to: <1115469496.19561.41.camel@localhost.localdomain>
References: <> <1115331436.8006.112.camel@localhost.localdomain> <> <1115342122.7660.25.camel@localhost.localdomain> <> <1115345403.7660.49.camel@localhost.localdomain> <> <1115380381.7660.123.camel@localhost.localdomain> <> <1115469496.19561.41.camel@localhost.localdomain>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Sat, May 07, 2005 at 08:38:16AM -0400, jamal wrote:
> Rewrite it Herbert ;-> I have no qualms as long as the feature is
> available. I even promised not to harass you ;->

Sorry, I can't think of any good ways to implement what you want.

> > The difference is that the uniqueness is easy when we (the kernel) are
> > the only ones setting it.  Once you let the user choose the value for
> > index, that's where the horror starts.
> But the uniqueness is still maintained. Nothing changes there.

The difference is that we now have to guarantee the uniqueness of
two unrelated fields during insertion: the index as well as the
selector.  This is where the complexity of your patch comes from.

> As i said in the last email, a lot of known management apps out there
> typically deal with row indices when managing tables: examples include
> SNMP, COPS, etc - and i am not sure how Racoon or pluto store their
> policies but they would be a good fit as well. 
> If you can specify what indices get used, then you can do some fast
> lookups when need to (because you specify then based on how things are
> laid out in your current tables). This is the way things are - i am not
> trying to innovate anything here. 
> How fast you add or delete these rules is a performance metric that
> affects your setup/teardown rates.

I'm afraid I don't buy this.  The policies are not stored in a
linear random-access data structure.  So setting the index
doesn't help performance one tiny bit.

In future it'll probably become a hash table or a tree, in neither
case will there be a linear index that could be used to determine

> Theres also another use of being able to use indices:  HA
> synchronization in active/backup. If the manager wants to make sure the
> active and backup are exactly the same and it(the manager) maintains
> less amount of data it will ensure that both nodes have exactly the same
> indices as well for the same policy.

Please elaborate by giving an example of how the index is actually
used.  Sorry, but as it is I'm too thick to see your point :)

> Having said the above, the SAD as well oughta have an index; infact one
> exists (the reqid) but is quiet bizzare. I dont wanna touch the SAD,
> yet ;-> not for the next few months until we talk at netconf probably.

The reqid is definitely not an index.  In fact it is not unique at all.
It's a way of condensing all the fields in a SA template into one u32.

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page:
PGP Key:

<Prev in Thread] Current Thread [Next in Thread>