All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamal Hadi <hadi@shell.cyberus.ca>
To: Martin Josefsson <gandalf@wlug.westbo.se>
Cc: Ethan Sommer <sommere@ethanet.com>,
	"David S. Miller" <davem@redhat.com>,
	linux-net@vger.kernel.org, netdev@oss.sgi.com,
	biondi@cartel-securite.fr
Subject: Re: [Fwd: [ANNOUNCE] Layer-7 Filter for Linux QoS]
Date: Wed, 21 May 2003 08:39:27 -0400 (EDT)	[thread overview]
Message-ID: <20030521075617.N43477@shell.cyberus.ca> (raw)
In-Reply-To: <1053443703.17386.138.camel@tux.rsn.bth.se>



On Tue, 20 May 2003, Martin Josefsson wrote:

> Maybe make it take a length parameter and if it's zero treat null's like
> all other algorithms do and it's non-zero use the length instead.
> Then you can hide it in a wrapper function for the "normal" case that
> just calls the actual search-function but with 0 as length.
>

Actually, the library that you pointed to seems to have callbacks
associated with every match - so it could be used on string matches.
The author is on the cc.

> Well we don't have a that big bread slicer (yet) but take a look at
> libqsearch, it is a library for searching and has been ported to the
> linux kernel by the author. It has support for various algorithms that

Didnt see anything kernel related in my quick scan.
The library certainly appears sane.

> have diffrent capabilities, unfortunately I don't think it has an
> algorithm that has support for regexp yet (the framework is there, ie
> the flag that says an algorithm supports regexp).
> It's modular and I don't think it should be that hard to add an regexp
> algorithm.

it does seems to imply regexp is available but wasnt anywhere i could
find.

> It looks quite nice and it can search for multiple strings at the same
> time and call diffrent callbacks depending on which string matched.
>

yep, can sed that packet easily with those callbacks ;-> s/val/val2/g

On Tue, 20 May 2003, Ethan Sommer wrote:

> One thing I should have pointed out earlier, it only copies that
> memory/does regex stuff until it finds a match or the first 8 packets,
> whichever is less. So, at least based on my tests, it doesn't seem to
> slow down 100BT much from what it would be otherwise. We might run into
> trouble if we look at GB or 10GB, but until we find a problem with
> speed, I think it is probably more important to make this as simple and
> easy to maintain as possible. If we see a need to make it more
> complicated due to speed issues, _then_ we should think about trying to
> get rid of that copy.
>

I think you should do some measurements - "it  doesnt slow 100Mbps" and
"lets worry about it when we get to 1 or 10Gbps" are handwaving at best.
Infact i would strongly recommend looking at the libqpsearch above.

cheers,
jamal

  reply	other threads:[~2003-05-21 12:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-19  3:01 [Fwd: [ANNOUNCE] Layer-7 Filter for Linux QoS] David S. Miller
2003-05-20  0:38 ` Jamal Hadi
2003-05-20  5:07   ` Ethan Sommer
2003-05-20 12:14     ` Jamal Hadi
2003-05-20 14:39       ` Ethan Sommer
2003-05-20 15:00         ` Jamal Hadi
2003-05-20 15:15           ` Martin Josefsson
2003-05-21 12:39             ` Jamal Hadi [this message]
2003-05-21 13:20               ` Philippe Biondi
2003-05-21 15:46                 ` Ethan Sommer
2003-05-21 23:11                   ` Philippe Biondi
2003-05-21 23:26                     ` Ethan Sommer
2003-05-22  8:26                       ` Philippe Biondi
2003-05-22 14:40                         ` Ethan Sommer
2003-05-24  7:22                           ` Werner Almesberger
2003-05-24  4:11                       ` Werner Almesberger
2003-05-24  4:23                         ` Werner Almesberger
2003-05-21 15:42               ` Ethan Sommer
2003-05-20 19:50           ` Ethan Sommer

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=20030521075617.N43477@shell.cyberus.ca \
    --to=hadi@shell.cyberus.ca \
    --cc=biondi@cartel-securite.fr \
    --cc=davem@redhat.com \
    --cc=gandalf@wlug.westbo.se \
    --cc=linux-net@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    --cc=sommere@ethanet.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 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.