netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Graf <tgraf@suug.ch>
To: jamal <hadi@cyberus.ca>
Cc: "David S. Miller" <davem@davemloft.net>, netdev@oss.sgi.com
Subject: Re: [PKT_SCHED]: Allow using nfmark as key in U32 classifier.
Date: Thu, 30 Dec 2004 18:43:13 +0100	[thread overview]
Message-ID: <20041230174313.GB32419@postel.suug.ch> (raw)
In-Reply-To: <1104335620.1025.22.camel@jzny.localdomain>

* jamal <1104335620.1025.22.camel@jzny.localdomain> 2004-12-29 10:53
> > > Also in the case of u32 (to take this opportunity) i would like to stash
> > > state inot a 16 bit ID to help in pretty printing the matches.
> > 
> > Not sure what you mean. Which "state"?
> > 
> 
> One example of what state you could store:
> In the case where i enter something readable in english, the display
> back is raw; 
> example:
> match ip src 10.0.0.210/32
> gets displayed as: match 0a0000d2/ffffffff at 12
> And a lot of times its tricky to find exactly what "at 12" means.
> 
> If i store some ID that would tell me "IP" when i dump then i can pretty
> print it in english in user space using ip_print().

Understood, we could store a map in userspace mapping those IDs to
pretty english match descriptions. I think avoiding to hardcode those
ids but rather just hold it for userspace is the best thing. OTOH, if
we give unique ids to matches we can use it instead of a separate ID.
Unique in terms of parent classid + filter handle + match handle must
be unique per interface. Thoughts? 

> Sounds good to me since we have a new sel.
> It may endup being tricky to be both fast and backward compat; but we'll
> see what fun awaits when you start coding.

I started developing concrete thoughts. The current u32 match could be
made a generic match just like meta which would give us a u32 w/o hashtables
on a always-true classifier. The problem arises with exactly those
hashtables.  u32 uses the same selector for this and furthermore even defines
stuff like hoff and hmask for this purpose. I have to read up again to
understand the hashing in full detail but this is the only issue I see that
we might face.

What I have in mind is, something like u32 but much simpler, w/o the
overhead of creating additional filters for hashing etc. Basically
this can be the always-true classifier which just implements the
generic matches tree. And have the existing u32 with the generic
matches added when hashing is required.

I planned to write these 2 additional generic matches so far. It's
pretty simple because I can just take over the code from EGP.

 KMP: Knuth-Morris-Pratt text search algorithm
 NByte: Compares any number of bytes against a pattern, very useful
        for comparing IPv6 addresses instead of creating 4 ANDed
        u32 matches.

  reply	other threads:[~2004-12-30 17:43 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200412270715.iBR7Fffe026855@hera.kernel.org>
2004-12-27 12:16 ` [PKT_SCHED]: Allow using nfmark as key in U32 classifier Thomas Graf
2004-12-28 13:20   ` jamal
2004-12-28 13:40     ` Thomas Graf
2004-12-28 13:59       ` jamal
2004-12-28 14:50         ` Thomas Graf
2004-12-28 15:55           ` jamal
2004-12-28 16:11         ` Thomas Graf
2004-12-28 16:36           ` jamal
2004-12-28 16:51             ` jamal
2004-12-28 19:26             ` Thomas Graf
2004-12-28 21:14               ` jamal
2004-12-28 22:10                 ` Thomas Graf
2004-12-28 23:06                   ` jamal
2004-12-28 23:19                     ` Thomas Graf
2004-12-28 23:39                       ` jamal
2004-12-29  0:09                         ` Thomas Graf
2004-12-29  1:13                           ` jamal
2004-12-29 12:48                             ` Thomas Graf
2004-12-29 14:20                               ` jamal
2004-12-29 15:01                                 ` Thomas Graf
2004-12-29 15:53                                   ` jamal
2004-12-30 17:43                                     ` Thomas Graf [this message]
2004-12-31  4:58                                       ` jamal
2004-12-31 11:08                                         ` Thomas Graf
2004-12-31 14:59                                           ` jamal
2004-12-31 15:39                                             ` Thomas Graf
2004-12-31 16:44                                               ` jamal
2004-12-31 17:32                                                 ` jamal
2004-12-31 18:11                                                 ` Thomas Graf
2004-12-31 18:19                                                   ` Thomas Graf
2004-12-31 20:51                                                   ` jamal
2005-01-01 12:10                                                     ` Thomas Graf
2005-01-01 23:29                                                       ` jamal
2005-01-02  0:06                                                         ` Thomas Graf
2005-01-03 14:36                                                           ` jamal
2005-01-03 15:02                                                             ` Thomas Graf
2005-01-03 15:55                                                               ` jamal
2005-01-03 16:26                                                                 ` Thomas Graf
2005-01-01 18:32                                                     ` Thomas Graf
2005-01-01 23:42                                                       ` jamal
2005-01-02  0:13                                                         ` Thomas Graf
2005-01-03 14:39                                                           ` 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=20041230174313.GB32419@postel.suug.ch \
    --to=tgraf@suug.ch \
    --cc=davem@davemloft.net \
    --cc=hadi@cyberus.ca \
    --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).