| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] pktgen: reduce stack usage, Robert Olsson |
|---|---|
| Next by Date: | RE: Intel and TOE in the news, jamal |
| Previous by Thread: | Re: Intel and TOE in the news, jamal |
| Next by Thread: | Re: Intel and TOE in the news, jamal |
| Indexes: | [Date] [Thread] [Top] [All Lists] |