[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52B74C3A.1050900@mojatatu.com>
Date: Sun, 22 Dec 2013 15:31:54 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Cong Wang <xiyou.wangcong@...il.com>
CC: Linux Kernel Network Developers <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next v4 3/8] net_sched: mirred: remove action when
the target device is gone
On 12/22/13 14:42, Cong Wang wrote:
> On Sun, Dec 22, 2013 at 8:15 AM, Jamal Hadi Salim <jhs@...atatu.com> wrote:
> You know qdiscs and filters are removed too when the device
> is gone, right? So isn't that also a policy you are talking about?
>
That is an easy optimization that made sense to make - we
deleted the root of a graph. No need to spam the policy manager.
What we are talking about is deleting a faulty node shared
by multiple graphs and deleting the vertex but then leaving
dangling edges around. Doesnt make sense.
No action that is shared between two flows or devices is EVER
going to be removed because you deleted a qdisc or a netdev.
> This doesn't make any sense to me, if it did, you should remove
> all net device notifications in kernel, right?
>
Refer to above.
> Have you ever thought about how hard it is to remove a mirred action
> upon the device removal? Even with libnl, we still have to:
>
> 1) monitor the device removal notification
> 2) search the action cache to get the action matches the target device
> 3) search for the filters that contains such actions
> 4) remove the action by changing the filters it is attached
>
> Try it and see how much more work you will do, compare it with
> this kernel patch. It would not be hard to conclude which is easier.
>
It is not about ease - it is about correctness.
You are making a macroscopic decision with a microscopic view. This is
why we have control planes. It is like the legs making decisions on
behalf of the brain.
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