netdev
[Top] [All Lists]

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

To: Jamal Hadi <hadi@xxxxxxxxxxxxxxxx>
Subject: Re: [Fwd: [ANNOUNCE] Layer-7 Filter for Linux QoS]
From: Ethan Sommer <sommere@xxxxxxxxxxx>
Date: Tue, 20 May 2003 09:39:40 -0500
Cc: "David S. Miller" <davem@xxxxxxxxxx>, linux-net@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20030520080940.E40885@xxxxxxxxxxxxxxxx>
References: <1053313298.3909.5.camel@xxxxxxxxxxxxx> <20030519202756.I39498@xxxxxxxxxxxxxxxx> <3EC9B815.4000504@xxxxxxxxxxx> <20030520080940.E40885@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030515 Thunderbird/0.1a
Jamal Hadi wrote:

On Tue, 20 May 2003, Ethan Sommer wrote:
Yep. We haven't spent a lot of time on optimizations. Obviously that
example can be fixed pretty quickly... except I'm not sure we can avoid
it and stay thread safe? (linux can route multiple packets at the same
time on an smp box right? so we can't just use a staically defined
buffer...)


Your problem seesm to be the regexp scheme used. You dont need a static
buffer i think. You should be able to operate on an incoming packet
itself.

Nope. I need to strip out all the nulls from the packet, or any posix regex parser will think the string ends at the first null. (so protocols which use null's will be difficult/impossible to identify)

I could modify the regexec function to take a length, but then it wouldn't be the posix regexec prototype and I was hopeing someone would add those to the common library of kernel functions, so others could use them. (and hence make it easier to maintain.)

Ethan


<Prev in Thread] Current Thread [Next in Thread>