Re: [Fwd: [ANNOUNCE] Layer-7 Filter for Linux QoS]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux