netdev
[Top] [All Lists]

Re: patch: policy update by id

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: patch: policy update by id
From: jamal <hadi@xxxxxxxxxx>
Date: Wed, 27 Apr 2005 21:52:20 -0400
Cc: netdev@xxxxxxxxxxx
In-reply-to: <20050428013014.GA23043@gondor.apana.org.au>
Organization: unknown
References: <1114602874.7670.4.camel@localhost.localdomain> <1114604657.7670.22.camel@localhost.localdomain> <1114604826.7670.24.camel@localhost.localdomain> <20050427233924.GA22238@gondor.apana.org.au> <1114650816.7663.13.camel@localhost.localdomain> <20050428012135.GA22950@gondor.apana.org.au> <20050428013014.GA23043@gondor.apana.org.au>
Reply-to: hadi@xxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
On Thu, 2005-28-04 at 11:30 +1000, Herbert Xu wrote:
> On Thu, Apr 28, 2005 at 11:21:35AM +1000, herbert wrote:
> > 
> > I see.  In that case you want to change your expression above
> > so that the memcmp is never done if excl is off and the index
> > is non-zero.  Otherwise this will result in non-deterministic
> > behaviour as the result will change depending on whether the
> > first hit is an index match or a selector match.
> 
> Sorry, the index match needs more work.  We need to maintain
> these invariants:
> 
> 1) There is only one policy with a given selector.
> 2) There is only one policy with a given index.
> 
> So to allow matching by index when updating, we need to deal
> with the possibility of having to delete two existing policies.
> The current code simply can't deal with that.
> 

Well, while snooping i was bothered as well. I am not sure i agree with
your #1 above ;->

1) It would seem to me that the priority field is to be used 
as a ambiguity resolver (thats what a gazillion other classification
schemes do). 

Lets take an example of an add:
If i specify a priority and a selector matches when doing an add, then
the priority being different should allow me to add the rule even if the
selectors match. 
Current behavior: We dont allow entering multiple selectors with the
same value even if i specify a different prio.

2) index really oughta be unique across the SPD.  
Current behavior: I can add several new rules with the same index.

I realize what i am asking in #2 is the opposite of what i ask for in 
#1 - the big unresolved question is: if both selector and index are
going to be keys to manipulating the SPD, then their behavior needs to
be consistent with each other. I really like to see the index being
unique, but the selector being priority disambiguated.


> So if we're going to do this we'll need a bigger patch :)

Lets agree on the principles first ;-> The patch i sent maintains the
status quo.

cheers,
jamal


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