lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 1 Feb 2019 20:22:33 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Ido Schimmel <idosch@...lanox.com>
Cc:     netdev@...r.kernel.org, Michael Chan <michael.chan@...adcom.com>,
        "David S. Miller" <davem@...emloft.net>,
        Derek Chickles <dchickles@...vell.com>,
        Satanand Burla <sburla@...vell.com>,
        Felix Manlunas <fmanlunas@...vell.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Leon Romanovsky <leon@...nel.org>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Ioana Radulescu <ruxandra.radulescu@....com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ivan Vecera <ivecera@...hat.com>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Dirk van der Merwe <dirk.vandermerwe@...ronome.com>,
        "Francois H. Theron" <francois.theron@...ronome.com>,
        Simon Horman <simon.horman@...ronome.com>,
        Quentin Monnet <quentin.monnet@...ronome.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Eric Dumazet <edumazet@...gle.com>,
        John Hurley <john.hurley@...ronome.com>,
        Edwin Peer <edwin.peer@...ronome.com>,
        open list <linux-kernel@...r.kernel.org>,
        "open list:MELLANOX MLX5 core VPI driver" 
        <linux-rdma@...r.kernel.org>,
        "open list:NETRONOME ETHERNET DRIVERS" <oss-drivers@...ronome.com>,
        "open list:STAGING SUBSYSTEM" <devel@...verdev.osuosl.org>
Subject: Re: [RFC net-next 11/13] nfp: Handle SWITCHDEV_PORT_ATTR_GET event

Le 2/1/19 à 7:45 PM, Jakub Kicinski a écrit :
> On Fri,  1 Feb 2019 14:06:55 -0800, Florian Fainelli wrote:
>> Following patches will change the way we communicate getting or setting
>> a port's attribute and use a blocking notifier to perform those tasks.
>>
>> Prepare nfp to support receiving notifier events targeting
>> SWITCHDEV_PORT_ATTR_GET and simply translate that into the existing
>> switchdev_ops::switchdev_port_attr_get operation.
>>
>> We register a single blocking switchdev notifier for the entire driver
>> instance and we differentiate a "net" from a "repr" by comparing the
>> network device's netdev_ops with the ones that this driver manages.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@...il.com>
> 
> Thanks Florian, the code looks good, only nit I have is - could you
> move nfp_switchdev_blocking_event() to nfp_port.c and nfp_port.h?
> We shouldn't touch nfp_net_common.c here.

Sounds good, thanks for the suggestion.

> 
> In general calling a notifier to get the parent_id (which is the only
> thing all these SR-IOV NIC drivers implement) seems a tad heavy.  It's
> an immutable, read-only attribute of a port, perhaps we can break it
> out?  Could we make it an NDO, perhaps?

A NDO would be fine with me, Ido, what do you think?

> 
> That's just my knee jerk reaction, given that NIC drivers don't
> implement any of the bridging side of switchdev I may not have a full
> appreciation of the abstraction you are building here :)
> 

Ido convinced me to convert the switchdev_port_attr_set() into a
blocking notifier such that we could veto operations in switch drivers,
once you do that, leaving the getter as switchdev_ops became pointless
:) but yes, it's a lot of code just to get there.
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ