On 3/29/17, 5:23 AM, Vlad Yasevich wrote: > [ resending to list. hit the wrong reply button last time ] > > On 03/27/2017 06:58 PM, David Miller wrote: >> From: Vladislav Yasevich <vyasev...@gmail.com> >> Date: Sat, 25 Mar 2017 21:59:47 -0400 >> >>> RTNL currently generates notifications on some netdev notifier events. >>> However, user space has no idea what changed. All it sees is the >>> data and has to infer what has changed. For some events that is not >>> possible. >>> >>> This patch adds a new field to RTM_NEWLINK message called IFLA_EVENT >>> that would have an encoding of the which event triggered this >>> notification. Currectly, only 2 events (NETDEV_NOTIFY_PEERS and >>> NETDEV_MTUCHANGED) are supported. These events could be interesting >>> in the virt space to trigger additional configuration commands to VMs. >>> Other events of interest may be added later. >>> >>> Signed-off-by: Vladislav Yasevich <vyase...@redhat.com> >> At what point do we start providing the metadata for the changed >> values as well? You'd probably need to provide both the old and >> new values to cover all cases. > I don't think if that would be possible because of when events are triggered. > We send these notifications after all the changes have already been made, so > it might be tough to carry old data. > > Looking at just the two events I am supporting in this patch, we could > actually > supply the old mtu data through a NETDEV_PRECHANGEMTU event, if it is > necessary.
But, NETDEV_PRECHANGEMTU will be a unnecessary notification to userspace without changes. There are already enough notifications generated for links (I know you are not suggesting adding it here) > For the use cases I am looking at, it isn't usefull, but easy enough to add. > Most of the times a single notification can carry multiple changes, this helps user-space..by cutting down on notifications in systems with large number of links. I don't see IFLA_EVENT attribute handle multiple changes.. Given the number of attributes for which events are generated, I think a model where user-space maintains a cache and diff's the new link object with the old one works best in all cases.
