netdev.vger.kernel.org archive mirror
 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 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).