netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevic@redhat.com>
To: David Ahern <dsa@cumulusnetworks.com>,
	Roopa Prabhu <roopa@cumulusnetworks.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net
Subject: Re: [PATCH net-next 1/8] rtnetlink: Do not generate notifications for MTU events
Date: Fri, 14 Apr 2017 21:51:58 -0400	[thread overview]
Message-ID: <34331f55-e3ef-4cfa-f911-4201d5a2014e@redhat.com> (raw)
In-Reply-To: <541c220b-9e55-8206-3886-6a98c86ae2e7@cumulusnetworks.com>

On 04/10/2017 11:49 AM, David Ahern wrote:
> On 4/10/17 9:39 AM, Vlad Yasevich wrote:
>> OK, so this will work for the events that are generated as a result of device state change
>> (like mtu, address, and others).
>>
>> However, the original event data may be needed for other events that may be
>> of use to userspace like NETDEV_NOTIFY_PEERS and NETDEV_RESEND_IGMP (possibly others...)
> 
> sure. My objection is to multiple messages with identical content.
> 
> I think the rtnetlink_event message is unique for those 2 netdev events,
> so no objections if it has value.
> 

So, I've been looking at adding a bitmap and collecting all modification, however
I ran into an interesting issue in do_setlink.

Currently the notifications from do_setlink() don't appear to work as one would
expect and it's somewhat confusing upon deeper inspection.

We have 2 values DO_SETLINK_MODIFIED (1) and DO_SETLINK_NOTIFY (3).  These 2 'attempt'
to do different jobs, but really fail at it.  The function will generate notifications
regardless of which of the above values is used.

Those changes were done in commit ba9989069f4e426b1e0ed7018eacc9e1ba607095 (cc Nicolas
just in case he remembers the history)

I am not sure which changes should really trigger a call netdev_state_change(), thus this
message.  Right now, all changes done in this function trigger them.  If that's how that
should function, that I can simplify the code.  If not, then some of the changes may
require us to export the event to the user.

To use the dreaded NETDEV_CHANGEMTU event as an example, we used to generate 3 messages
(PRECHANGEMTU, CHANGEMTU, and a message from netdev_state_change).  With recent changes,
we now only generate a message from netdev_state_change.  However, mtu change is tagged
with DO_SETLINK_MODIFIED which doesn't include the notify bit.  So, should there be a
NETDEV_CHANGE event associated with this change and a rtnl message (as it is now) or not?
It's unclear.

-vlad

  reply	other threads:[~2017-04-15  1:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-07 21:25 [PATCH net-next 0/8] rtnetlink: Cleanup user notifications for netdev events David Ahern
2017-04-07 21:25 ` [PATCH net-next 1/8] rtnetlink: Do not generate notifications for MTU events David Ahern
2017-04-08 18:06   ` Roopa Prabhu
2017-04-08 18:13     ` David Ahern
2017-04-08 18:18       ` Roopa Prabhu
2017-04-10 15:39         ` Vlad Yasevich
2017-04-10 15:49           ` David Ahern
2017-04-15  1:51             ` Vlad Yasevich [this message]
2017-04-15  4:26               ` David Ahern
2017-04-18  7:52                 ` Nicolas Dichtel
2017-04-09  1:36   ` Vlad Yasevich
2017-04-09  2:58     ` David Ahern
2017-04-07 21:25 ` [PATCH net-next 2/8] rtnetlink: Do not generate notification for UDP_TUNNEL_PUSH_INFO David Ahern
2017-04-07 21:25 ` [PATCH net-next 3/8] rtnetlink: Do not generate notifications for CHANGEADDR event David Ahern
2017-04-07 21:25 ` [PATCH net-next 4/8] rtnetlink: Do not generate notifications for POST_TYPE_CHANGE event David Ahern
2017-04-07 21:25 ` [PATCH net-next 5/8] rtnetlink: Remove NETDEV_CHANGEINFODATA netdev event David Ahern
2017-04-07 21:25 ` [PATCH net-next 6/8] rtnetlink: Do not generate notifications for PRECHANGEUPPER event David Ahern
2017-04-07 21:25 ` [PATCH net-next 7/8] rtnetlink: Do not generate notifications for NOTIFY_PEERS event David Ahern
2017-04-09  1:37   ` Vlad Yasevich
2017-04-07 21:25 ` [PATCH net-next 8/8] rtnetlink: Do not generate notifications for CHANGELOWERSTATE event David Ahern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=34331f55-e3ef-4cfa-f911-4201d5a2014e@redhat.com \
    --to=vyasevic@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dsa@cumulusnetworks.com \
    --cc=netdev@vger.kernel.org \
    --cc=roopa@cumulusnetworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).