netdev
[Top] [All Lists]

Re: Intel and TOE in the news

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: Intel and TOE in the news
From: Thomas Graf <tgraf@xxxxxxx>
Date: Mon, 21 Feb 2005 15:17:14 +0100
Cc: Andi Kleen <ak@xxxxxx>, Leonid Grossman <leonid.grossman@xxxxxxxxxxxx>, "'rick jones'" <rick.jones2@xxxxxx>, netdev@xxxxxxxxxxx, "'Alex Aizman'" <alex@xxxxxxxxxxxx>
In-reply-to: <1108994621.1089.158.camel@jzny.localdomain>
References: <20050220230713.GA62354@muc.de> <200502210332.j1L3WkDD014744@guinness.s2io.com> <20050221115006.GB87576@muc.de> <20050221132844.GU31837@postel.suug.ch> <1108994621.1089.158.camel@jzny.localdomain>
Sender: netdev-bounce@xxxxxxxxxxx
* jamal <1108994621.1089.158.camel@xxxxxxxxxxxxxxxx> 2005-02-21 09:03
> 
> Everything in the stack would have to be re-written not just that one
> piece. 
> The question is: Is it worth it? My experimentation shows, only in a few
> speacilized cases.

Assuming we can deliver a chain of skbs to enqueue (session based or not),
the locking times should decrease. I'm not sure whether it's worth to
rewrite the whole stack (I wouldn't have any use for it) or just establish
a fast path. We could for example allow the ingress qdisc to redirect
packets directly to a egress qdisc and have "dynamic" fast forwarding.
We can add an action looking up the route and rewriting the packet as
needed and enqueue it to the right qdisc immediately. The redirect action
is already on that way, now if we can reduce the locking overhead a bit
more the fast forwarding routing t-put should increase.

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