From: jamal <hadi@cyberus.ca>
To: Thomas Graf <tgraf@suug.ch>
Cc: Patrick McHardy <kaber@trash.net>, netdev <netdev@oss.sgi.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: patch: Action repeat
Date: Mon, 02 May 2005 08:10:38 -0400 [thread overview]
Message-ID: <1115035838.8929.236.camel@localhost.localdomain> (raw)
In-Reply-To: <20050430235809.GI577@postel.suug.ch>
On Sun, 2005-01-05 at 01:58 +0200, Thomas Graf wrote:
> * jamal <1114900485.8929.171.camel@localhost.localdomain> 2005-04-30 18:34
[..]
> > Perhaps we can reuse classid by flagging somewhere?
> > A good place to do it is tc_verdict. There a few bits still left.
> > We could set a bit to say the meaning of classid to be global vs local.
>
> Sounds good to me, I'm not quite sure if I still have a good enough
> picture of your action code. Let's assume we have ematches and an
> action setting the classid at ingress. The action sets the above flag
> to state the global scope.
Which means the classid is not reset by exec().
> The packet passes the stack and the
> classid gets copied into the new encapsulated packet. On the egress
> device we have something like a nop action assigning the classid
> to res->classid. How do we make sure that the classid remains
> untouched even if the packet passes a dummy device in between having
> actions configured? Can we we still have functional actions on
> this dummy device?
I would say that if dummy changes it because of a policy, then thats a
fair deal. i.e
filter blah blah \
action add meta classid global :23
I am beginning to think that perhaps classid should stay as a local
scope metadata and what Patrick suggested maybe the way out. Although i
have to admit I dont like a generic function to have a parameter that
only a very small set of users find useful. If we are going to allow a
structure to be passed back and forth, perhaps it should also carry
other things (in addition to _result). Need to think a little.
cheers,
jamal
next prev parent reply other threads:[~2005-05-02 12:10 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-30 16:50 patch: Action repeat jamal
2005-04-30 17:06 ` Patrick McHardy
2005-04-30 17:08 ` Patrick McHardy
2005-04-30 17:27 ` jamal
2005-04-30 18:13 ` Patrick McHardy
2005-04-30 19:51 ` jamal
2005-04-30 20:08 ` Thomas Graf
2005-04-30 20:50 ` jamal
2005-04-30 21:55 ` Thomas Graf
2005-04-30 22:34 ` jamal
2005-04-30 23:58 ` Thomas Graf
2005-05-02 12:10 ` jamal [this message]
2005-05-02 15:06 ` Thomas Graf
2005-05-04 11:46 ` jamal
2005-05-04 12:15 ` Patrick McHardy
2005-05-04 12:31 ` Thomas Graf
2005-05-04 12:59 ` jamal
2005-05-04 13:28 ` Thomas Graf
2005-05-04 13:33 ` Thomas Graf
2005-05-04 13:33 ` jamal
2005-05-04 13:48 ` Thomas Graf
2005-05-04 13:53 ` jamal
2005-05-04 14:05 ` Thomas Graf
2005-05-04 14:23 ` jamal
2005-05-04 14:53 ` Thomas Graf
2005-05-05 13:06 ` jamal
2005-05-01 0:08 ` Patrick McHardy
2005-05-01 0:06 ` Patrick McHardy
2005-05-03 23:28 ` David S. 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=1115035838.8929.236.camel@localhost.localdomain \
--to=hadi@cyberus.ca \
--cc=davem@davemloft.net \
--cc=kaber@trash.net \
--cc=netdev@oss.sgi.com \
--cc=tgraf@suug.ch \
/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.