[Top] [All Lists]

Re: resend patch: xfrm policybyid

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: resend patch: xfrm policybyid
From: jamal <hadi@xxxxxxxxxx>
Date: Sun, 08 May 2005 10:30:43 -0400
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev <netdev@xxxxxxxxxxx>
In-reply-to: <20050508080730.GA30512@xxxxxxxxxxxxxxxxxxx>
Organization: unknown
References: <20050505213239.GA29526@xxxxxxxxxxxxxxxxxxx> <1115331436.8006.112.camel@xxxxxxxxxxxxxxxxxxxxx> <20050505231210.GA30574@xxxxxxxxxxxxxxxxxxx> <1115342122.7660.25.camel@xxxxxxxxxxxxxxxxxxxxx> <20050506013125.GA31780@xxxxxxxxxxxxxxxxxxx> <1115345403.7660.49.camel@xxxxxxxxxxxxxxxxxxxxx> <20050506085404.GA26719@xxxxxxxxxxxxxxxxxxx> <1115380381.7660.123.camel@xxxxxxxxxxxxxxxxxxxxx> <20050507105500.GA20283@xxxxxxxxxxxxxxxxxxx> <1115469496.19561.41.camel@xxxxxxxxxxxxxxxxxxxxx> <20050508080730.GA30512@xxxxxxxxxxxxxxxxxxx>
Reply-to: hadi@xxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
On Sun, 2005-08-05 at 18:07 +1000, Herbert Xu wrote:
> 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.

There is really nothing in my (small) patch that you have pointed out
that is unresolvable;->
You just dont like the idea, period.

> > > 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.

Both the index and the selector MUST be unique, no question about that.
What i did is introduce setting of the index - and that makes the
checking do a little more. It would be worng not to do the checking.

> 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
> insertion/deletion.

I am talking about user space apps - not the kernel.
Have you ever looked at IPSEC related MIBs and PIBs? or apps that
implement those sorts of entities? I suspect you have not otherwise we
would have closed this ages ago.

> 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 :)

I have given you enough info that i am concluding this is now becoming a
debate for the sake of one;->

Sorry, Herbert, I strongly disagree with your views on this topic. This
is one of those moments when it becomes obvious there can be no
compromise. So I am hoping that someone following this discussion or
writing management apps would speak up.

> > 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.

I dont wanna talk about this right now; 


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