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@xxxxxxxxx> > > 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
