From: jamal <hadi@cyberus.ca>
To: mahatma@eu.by
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH 2.6.23+] ingress classify to [nf]mark
Date: Fri, 11 Jan 2008 22:03:47 -0500 [thread overview]
Message-ID: <1200107027.4477.36.camel@localhost> (raw)
In-Reply-To: <4787D49E.6080906@bspu.unibel.by>
On Fri, 2008-11-01 at 18:42 -0200, Dzianis Kahanovich wrote:
> About script example:
> While I compose filter, I check flag ($TC_INDEX2MARK), tells me are patch
> applied or no. If no - I use usual "-j MARK --set-mark", else I use classid to
> change mark. All in ingress only. For example:
> tc filter add dev eth0 parent ffff: protocol ip u32 ... action ipt -j MARK 0x10
> are cname to:
> tc filter add dev eth0 parent ffff: protocol ip u32 ... flowid :10
I thought you were doing something like this (to achieve your policy):
----------
major=1
minor=12
mark=`expr $major + $minor`
#
tc qdisc add dev XXX ingress
tc filter add dev XXX parent ffff: protocol ip prio 5 \
u32 blah bleh \
flowid $major:$minor action \
ipt -j mark --set-mark $mark
---------------
> - it use less code/modules and, in many cases, may be single/main goal to
> ingress usage - pre-marking packets.
That is true and you would also have one less line in your policy; as an
example in above the line "ipt -j mark --set-mark $mark" would be
unnecessary; however, all the other lines in the policy setting _will be
necessary_. And this + the fact there are many other values/shapes the
default policy could take is essentially whats bothering me.
In any case, scanning the current code it seems mark is no longer
considered a netfilter-only metadatum - so it may not be semantically as
obscene as i felt earlier; Can you pick something simpler for policy?
example set the mark to whatever tc_index gets set?
If you still could write the metadata action, we could use it to
override mark, tc_index etc in addition.
cheers,
jamal
next prev parent reply other threads:[~2008-01-12 3:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-10 19:05 [PATCH 2.6.23+] ingress classify to [nf]mark Dzianis Kahanovich
2008-01-10 17:29 ` Patrick McHardy
2008-01-11 17:37 ` Dzianis Kahanovich
2008-01-10 21:39 ` jamal
2008-01-11 17:24 ` Dzianis Kahanovich
2008-01-11 14:59 ` jamal
2008-01-11 20:42 ` Dzianis Kahanovich
2008-01-12 3:03 ` jamal [this message]
2008-01-12 17:56 ` Dzianis Kahanovich
2008-01-13 19:44 ` jamal
2008-01-14 15:40 ` Dzianis Kahanovich
2008-01-14 12:56 ` jamal
2008-01-14 22:20 ` Dzianis Kahanovich
2008-01-16 12:45 ` jamal
2008-01-23 0:14 ` Dzianis Kahanovich
2008-01-23 16:42 ` Dzianis Kahanovich
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=1200107027.4477.36.camel@localhost \
--to=hadi@cyberus.ca \
--cc=mahatma@eu.by \
--cc=netdev@vger.kernel.org \
/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.