On 4/8/17 2:06 PM, Roopa Prabhu wrote: > On 4/7/17, 2:25 PM, David Ahern wrote: >> Changing MTU on a link currently causes 3 messages to be sent to userspace: >> >> [LINK]11: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1490 qdisc noqueue state >> UNKNOWN group default event PRE_CHANGE_MTU >> link/ether f2:52:5c:6d:21:f3 brd ff:ff:ff:ff:ff:ff >> >> [LINK]11: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state >> UNKNOWN group default event CHANGE_MTU >> link/ether f2:52:5c:6d:21:f3 brd ff:ff:ff:ff:ff:ff >> >> [LINK]11: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state >> UNKNOWN group default >> link/ether f2:52:5c:6d:21:f3 brd ff:ff:ff:ff:ff:ff >> >> Remove the PRE_CHANGE_MTU and CHANGE_MTU messages. >> >> > > This change is good... multiple notifications for the same event does not > help in large scale links setups. However, this > reverts what vlad was trying to do with his patchset. Vlad's patch-set relies > on the rtnl notifications generated from > notifiers (rtnetlink_event) to add specific event (IFLA_EVENT) in > notifications. > > The third notification in your example above is the correct one and is an > aggregate notification for a set of changes, but > it cannot really fill in all types of events in the single IFLA_EVENT > attribute as it stands today. IFLA_EVENT should be > a bitmask to include all events in this case (i had indicated this in vlads > first version). >
Agreed. I think it would be best to revert def12888c161 before the UAPI goes out. The change can instead add the IFLA_EVENT as a bitmask mentioned here to note the changes in a setlink. On top of that, remove the notifications for the events I mentioned in this set to reduce the overhead on userspace.
