[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1175739294.4068.29.camel@localhost>
Date: Wed, 04 Apr 2007 22:14:54 -0400
From: jamal <hadi@...erus.ca>
To: Patrick McHardy <kaber@...sh.net>
Cc: Denys <denys@...p.net.lb>,
Stephen Hemminger <shemminger@...ux-foundation.org>,
netdev@...r.kernel.org
Subject: Re: one more... iproute commands lockup whole system
On Wed, 2007-04-04 at 16:39 +0200, Patrick McHardy wrote:
> Have a tasklet to avoid the deadlocks.
sounds like a good idea from the outset. The principle of punishing only
users of mirred is the right one. It will also provide a clean way to
drop all redirect to self.
The dilema is that the cost may end up being in complexity and
performance. Let me throw a few wrenches your way:
- Mirroring doesnt have this problem, only redirecting does. And the
main problem is on egress. So you may have to do the enqueueing only for
those cases, or we may just have to separate redirects from mirroring as
two separate actions.
- We need to be able to support literally hundreds of such actions, so
if you do a single tasklet per action you will have quiet a few running
- i dont know what the impact is. A solution might be to do a single
tasklet with the mirred table; you will need many queues.
-There may be others like lock contention etc on trying to reinject
which will affect perfomance.
I am not against the idea Patrick, I am just worried about performance
and i feel that the majority of people who redirect will, once bitten
(as was Denys), eventually resort to doing the right config and would
rather have good perfomance.
I could be selfish and wrong by looking at my needs for this action but
i prefer performance and from that perspective i look at this from
someone who didnt read the instructions on a gun and shot at their toe.
You could add a sensor that recognises a toe is being aimed at and pop
up an LCD with a question "are you sure you want to shoot at _a
toe_?" ;-> but that adds to the cost.
I am exagerating - but i hope you get my point.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists