netdev
[Top] [All Lists]

Re: dummy as IMQ replacement

To: Thomas Graf <tgraf@xxxxxxx>
Subject: Re: dummy as IMQ replacement
From: jamal <hadi@xxxxxxxxxx>
Date: 31 Jan 2005 15:18:35 -0500
Cc: netdev@xxxxxxxxxxx, Nguyen Dinh Nam <nguyendinhnam@xxxxxxxxx>, Remus <rmocius@xxxxxxxxxxxxxx>, Andre Tomt <andre@xxxxxxxx>, syrius.ml@xxxxxxxxxx, Andy Furniss <andy.furniss@xxxxxxxxxxxxx>, Damion de Soto <damion@xxxxxxxxxxxx>
In-reply-to: <20050131181553.GG31837@xxxxxxxxxxxxxx>
Organization: jamalopolous
References: <1107123123.8021.80.camel@xxxxxxxxxxxxxxxx> <20050131135810.GC31837@xxxxxxxxxxxxxx> <1107181169.7840.184.camel@xxxxxxxxxxxxxxxx> <20050131151532.GE31837@xxxxxxxxxxxxxx> <1107186044.1076.11.camel@xxxxxxxxxxxxxxxx> <20050131155929.GF31837@xxxxxxxxxxxxxx> <1107189625.1076.77.camel@xxxxxxxxxxxxxxxx> <20050131181553.GG31837@xxxxxxxxxxxxxx>
Reply-to: hadi@xxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
On Mon, 2005-01-31 at 13:15, Thomas Graf wrote:

> I haven't left ns sim so far, my calculations are based on some of the
> linux specific cc modifications though, i.e. I modified ns sim a bit
> to provide the same information. I'm thinking about moving to umlsim,
> it should provide a better real world simulation.
> 

The problem is if theres any bugs in the way algos are implemented in
Linux you are influenced by that truth. Starting with ns and then
validating on Linux is a great way to do it.

> Sounds good, we could put up a ematch csum for validation and a eaction
> for recomputation. I'll wait for your code to show up.
> 

Cross your fingers; worst case by weekend i should get something out.

> > Essentially on ingress create state; i have to find my notes to give you
> > precise answer. But one of the parameters was to select the level of
> > state tracking (such as "track IP only" - not sure how doable that is
> > with contrack)
> 
> So you want to have a generic conntrack action capable of dynamically
> taking whatever information into account that the user requests? This
> remembers me of the esfq effort which could benefit from this, it
> extends sfq to take the definition for a flow as a parameter. We could
> share some code here.
> 

I dont think contrack was designed for this kind of effort. If we totaly
fail to do it using contrack then we could go a different path.
sfq already stores some rough view of the state; not sure if it can
benefit from this.

> > Stateless NAT doesnt really need contracking. pedit (taught to speak
> > english) + eaction csum should do it.
> 
> Right, given we don't need any reverse translation. Still it would be
> neat to set the conntrack attributes so one could use iptables later
> on, I'm not sure how doable this is though.
> 

If you are NATing (stateless) you should enter rules for both
directions; Maybe we could write a wrapper where user only enters
outgoing rule and that automatically generates the incoming rule as
well.

> Something different...
> 
> This sounds all very good but I think we're still sucessfully ignoring
> one of the most important points, usability. 

Absolutely.

> Most modifications over
> the last few months have complicated things, introduced different behaviour
> depending on compile time options and userspace tools which are either
> outdated or having features being completely undocumented. Some of the
> recent additions don't even show up in the usage text of iproute2. So
> I think we should at least part time focus a little more on the big
> picture and make things consitent and more useable. At least 50% of the
> functionaility currently in mainline is completely unused because nobody
> knows about it. I'm in no way against any of the recent additions but
> maybe we can also put some more effort into usability.

I think the eactions etc are adding a lot of value towards usability.
Hasso Tepper was ealrier complaining about this same issue. 
As an example, I think u32 and ematches would improve a great deal now
and be more understandable. True, work/time still needs to be invested.

cheers,
jamal



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