From: Thomas Graf <tgraf@suug.ch>
To: jamal <hadi@cyberus.ca>
Cc: Patrick McHardy <kaber@trash.net>, netdev <netdev@oss.sgi.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: patch: Action repeat
Date: Sun, 1 May 2005 01:58:09 +0200 [thread overview]
Message-ID: <20050430235809.GI577@postel.suug.ch> (raw)
In-Reply-To: <1114900485.8929.171.camel@localhost.localdomain>
* jamal <1114900485.8929.171.camel@localhost.localdomain> 2005-04-30 18:34
> On Sat, 2005-30-04 at 23:55 +0200, Thomas Graf wrote:
> >
> > Right, although I would define local as per device on either ingress
> > or egress. What I'm looking for in particular is a way to transfer
> > classification decisions from one device to another. A common case
> > for this is if a packet enters the packet, gets encapsulated and
> > leaves the host in some kind of tunnel. It's pretty hard to do
> > classification on the tunnel device so you want to do it before
> > the encapsulation and copy the result over to the tunnel. We can
> > use nfmark for this but i'd rather have a well defined variable
> > for this.
>
> 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. 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?
next prev parent reply other threads:[~2005-04-30 23:58 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 [this message]
2005-05-02 12:10 ` jamal
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=20050430235809.GI577@postel.suug.ch \
--to=tgraf@suug.ch \
--cc=davem@davemloft.net \
--cc=hadi@cyberus.ca \
--cc=kaber@trash.net \
--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).