Re: [PATCH net-next 0/3] net: introduce IFF_PROTO_DOWN flag.

On Fri, Mar 20, 2015 at 3:15 PM, David Miller [off-list ref] wrote:

From: Anuradha Karuppiah <redacted>
Date: Fri, 20 Mar 2015 14:16:26 -0700

quoted

What we are looking for is a way for user space to hold the device
down on detecting incorrect config/topology and for enabling the
device once the error condition is removed provided the administrator
didn’t intentionally disable it. And we don't see a way for a user
protocol to do this without involving the kernel.

It is not your business to override what the administrator asks for.

This is what I mean by "cooperative".

ip link up has no idea about your error states, neither does every
administrator out there.

So you're changing behavior in an incompatible way.

This is why you need a wholistic approach in userland that propagates
this knowledge all around, rather than just using a sledge hammer by
asking the kernel to enforce some new rule upon unsuspecting existing
users.

I agree with you, applications cannot/must not override the
administrator’s directive. I also agree that “ip link set up” doesn’t
need to know about errors that user daemons detect.

That is one of the reasons for not clearing IFF_UP from the user space
MLAG application on detecting errors. But I need a way to notify the
device drivers (of the devices that have MLAG enabled) that an error
has occurred allowing them to handle the error gracefully i.e. without
traffic getting black holed.

The change in the net core is only to prevent the oper state from
going UP when errors are encountered not to dev_close (Sorry, I think
I caused this confusion by saying error “disable”). This in some way
is similar to the dormant mode/state implementation which lets the
user space application/driver influence the operstate. Only additional
thing here is a notification that let’s drivers know that errors have
been encountered on the device.