lkml.org 
[lkml]   [2019]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH net-next v5 13/22] ethtool: provide driver/device information in GET_INFO request
Thu, Mar 28, 2019 at 10:53:47AM CET, mkubecek@suse.cz wrote:
>On Thu, Mar 28, 2019 at 10:21:26AM +0100, Jiri Pirko wrote:
>> Wed, Mar 27, 2019 at 11:25:54PM CET, mkubecek@suse.cz wrote:
>> >
>> >I'm all for implementing new features which are are related to physical
>> >device (ASIC) rather than network interface only in devlink (at the
>> >level of kernel-userspace interface). But for features already provided
>> >by ethtool (userspace utility) I can't help seeing the state of devlink
>> >support in NIC drivers as a serious blocker.
>>
>> What I'm thinking about at for some time now would be en explicit
>> default devlink and devlink_port registration for every netdev for
>> drivers that does not support devlink themselves. I need to think about
>> it more, but it seems doable. Then we can hang appropriate things there
>> and make the ethtoolnl/devlink separation clear. I believe we need to do
>> it.
>
>That sounds great, such "generic devlink" implementation would be a way
>around. Kernel could then emulate features which are not implemented by
>an actual devlink handler (i.e. "generic devlink" is used or particular
>handler is missing) by falling back to ethtool_ops handler so that
>userspace could rely on devlink API for things like device information,
>various dumps, flashing etc. without losing anything.

Yep. Plan to do that next week.

>
>Michal

\
 
 \ /
  Last update: 2019-03-28 17:35    [W:0.082 / U:4.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site