From: Thomas Graf <tgraf@suug.ch>
To: jamal <hadi@cyberus.ca>
Cc: Patrick McHardy <kaber@trash.net>,
"David S. Miller" <davem@davemloft.net>,
netdev@oss.sgi.com
Subject: Re: [PATCH] PKT_SCHED: Fix cls indev validation
Date: Wed, 22 Dec 2004 15:26:37 +0100 [thread overview]
Message-ID: <20041222142637.GE7884@postel.suug.ch> (raw)
In-Reply-To: <1103722366.1089.75.camel@jzny.localdomain>
* jamal <1103722366.1089.75.camel@jzny.localdomain> 2004-12-22 08:32
> On Tue, 2004-12-21 at 19:31, Thomas Graf wrote:
> > * Patrick McHardy <41C7F833.4000909@trash.net> 2004-12-21 11:17
> > > Could you make your patchset available somehow ?
> >
> > http://people.suug.ch/~tgr/patches/queue/
> >
> > Unfinished and untested.
>
> I just took a quick glimpse.
>
> 1)Recall: Policer will have to die at some point - only reason for its
> existence is for backward compat.
> New iproute2 code sooner than later stop using that inteface so we can
> kill it. I suspect we can kill it in a year or two and definetely the
> day 2.7 comes out.
I fully agree. The patchset looks like a beautification but it isn't.
Its main purpose is to make changing consistent again. I tried
achieving this with the existing API and the ifdef hell got horrible
and ended up having over 60 lines of redundant code per classifier.
I would rather be implementing new fancy stuff but fixing the existing
issues comes first.
> 2) The name tcf_attrs doesnt sound right - attributes are normally
> data pieces not methods. Cant think of a good name.
I feel the same, I was thinking of extensions but wasn't pleased either.
Suggestions appreciated.
> 3) What can i say? dang - this indev thing is getting out of control ;->
Too late, it's there, we must maintain it ;->
> If you are going to go this far for beautification sake then
> kill the .indev thing please before it becomes a beast.
Again, it's not for beautification, validating the indev tlv must be
done before changing native classifier attributes which lead to
more ifdefs. Putting it into tcf_attrs saves code and makes it
available to the other classifiers at the same time. It's a dodgy
situation, the current status is unsatisfying and all changes
made now will be removed again.
> Do what we discussed a while back:
> - have a generic very basic extended generic match API which indev uses
> that gets invoked from the classifier. It should take no more than one
> page to write the indev extension - if it exceeds that you are doing
> something wrong. There should be capability to mix and match these
> extenders so i can say in u32 something like:
> match ip src X
> match extend indev src eth0
> match protocol tcp
> match extended metadata fwmark 0x10
My actual plan was to introduce a nested TCA_TYPE_ATTRS TLV
containing all the generic matches and attributes so a classifier
no longer has to be changed but the backward compatibility will
be a PITA.
> I think its time we did this right than defering.
Indeed, what about this: I'll try and do a proposal on a new
generic matching layer holding the action bits and providing
backward compatibility to police/indev. We can then build the
metadata match on top of it. I'm going to post the classifier
I'm working on for a long time even if it's still buggy and
unfinished so we can at least take over some ideas and concepts
and then come up with something final that doesn't need to be
changed again in 2 months.
next prev parent reply other threads:[~2004-12-22 14:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-19 20:30 [PATCH] PKT_SCHED: Fix cls indev validation Thomas Graf
2004-12-20 8:27 ` Patrick McHardy
2004-12-20 13:03 ` Thomas Graf
2004-12-20 14:16 ` jamal
2004-12-20 20:07 ` Thomas Graf
2004-12-21 10:17 ` Patrick McHardy
2004-12-22 0:31 ` Thomas Graf
2004-12-22 9:36 ` Patrick McHardy
2004-12-22 13:32 ` jamal
2004-12-22 14:26 ` Thomas Graf [this message]
2004-12-28 13:27 ` jamal
2004-12-21 0:22 ` Thomas Graf
2004-12-21 0:56 ` 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=20041222142637.GE7884@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).