netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: jamal <hadi@cyberus.ca>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>, netdev <netdev@oss.sgi.com>
Subject: Re: resend patch:  xfrm policybyid
Date: Sat, 07 May 2005 08:38:16 -0400	[thread overview]
Message-ID: <1115469496.19561.41.camel@localhost.localdomain> (raw)
In-Reply-To: <20050507105500.GA20283@gondor.apana.org.au>

On Sat, 2005-07-05 at 20:55 +1000, Herbert Xu wrote:
> On Fri, May 06, 2005 at 07:53:00AM -0400, jamal wrote:
> > 
> > You are a reasonable man, so i am hoping you will end agreeing 
> > or agreeing to disagree;->
> 
> If it weren't for the fact that the only way of achieving what you
> want here is through ugly code then I wouldn't have any problems with
> it at all.
>  

Rewrite it Herbert ;-> I have no qualms as long as the feature is
available. I even promised not to harass you ;->


> > Note: The index was already guaranteed to be unique even without my
> > patch.
> 
> 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.

>  this case actually the justification exists: The selector is needed
> > for data/packet path lookup key. The index for manager side
> > manageability. 
> 
> I have no argument with the existence of the index per se.  What I am
> yet to be convinced of is the need for the user to set its value.

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

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.
Actually this is a digression, so  just ignore i said it ;->

cheers,
jamal

  reply	other threads:[~2005-05-07 12:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-05 13:14 resend patch: xfrm policybyid jamal
2005-05-05 21:32 ` Herbert Xu
2005-05-05 22:17   ` jamal
2005-05-05 22:18     ` David S. Miller
2005-05-06 13:28       ` Herbert Xu
2005-05-06 18:20         ` David S. Miller
2005-05-05 23:12     ` Herbert Xu
2005-05-06  1:15       ` jamal
2005-05-06  1:31         ` Herbert Xu
2005-05-06  2:10           ` jamal
2005-05-06  2:20             ` jamal
2005-05-06  8:54             ` Herbert Xu
2005-05-06 11:53               ` jamal
2005-05-07 10:55                 ` Herbert Xu
2005-05-07 12:38                   ` jamal [this message]
2005-05-08  8:07                     ` Herbert Xu
2005-05-08 14:30                       ` jamal
2005-05-08 15:23                         ` Patrick McHardy
2005-05-08 17:23                           ` jamal
2005-05-09 11:45                             ` Patrick McHardy
2005-05-09 13:10                               ` jamal
2005-05-06 11:04     ` Herbert Xu
2005-05-06 11:56       ` jamal

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=1115469496.19561.41.camel@localhost.localdomain \
    --to=hadi@cyberus.ca \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).