[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20171012.120113.825151862740889559.davem@davemloft.net>
Date: Thu, 12 Oct 2017 12:01:13 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: roopa@...ulusnetworks.com
Cc: jiri@...nulli.us, steven.lin1@...adcom.com, netdev@...r.kernel.org,
jiri@...lanox.com, michael.chan@...adcom.com,
linux-pci@...r.kernel.org, linville@...driver.com,
gospo@...adcom.com
Subject: Re: [RFC 0/3] Adding config get/set to devlink
From: Roopa Prabhu <roopa@...ulusnetworks.com>
Date: Thu, 12 Oct 2017 07:46:24 -0700
> FWIS, devlink is a driver api just like ethtool is.
Devlink a driver API for doing operations where we don't have a
specific 'netdev' object to work upon.
> and ethtool needs to move to netlink soon...and It would be better to
> not put the rtnl_lock burden on ethtool driver operations. Instead of
> adding yet another driver api, extending devlink seems like a great
> fit to me.
You can use genetlink and avoid RTNL.
Also, Florian Westphal has been pushing the RTNL lock down into the
actual rtnetlink operation implementations. So one does not have to
avoid rtnetlink to avoid the RTNL mutex at all.
Powered by blists - more mailing lists