From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934883AbcLOCwH (ORCPT ); Wed, 14 Dec 2016 21:52:07 -0500 Received: from mail-dm3nam03on0113.outbound.protection.outlook.com ([104.47.41.113]:45417 "EHLO NAM03-DM3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933849AbcLOCwF (ORCPT ); Wed, 14 Dec 2016 21:52:05 -0500 From: Haiyang Zhang To: Greg KH , Stephen Hemminger CC: "olaf@aepfle.de" , "jasowang@redhat.com" , "linux-kernel@vger.kernel.org" , "bjorn.helgaas@gmail.com" , "apw@canonical.com" , "devel@linuxdriverproject.org" , "leann.ogasawara@canonical.com" Subject: RE: [PATCH 3/3] hv_netvsc: Implement VF matching based on serial numbers Thread-Topic: [PATCH 3/3] hv_netvsc: Implement VF matching based on serial numbers Thread-Index: AQHSUR21+bJgO3U+U0emkkp2CWFPCaD+NO0AgACI2oCAAHx4AIAAtV0AgAAbvVCAAAhUgIAAENNggAAESwCAAAHRAIAAA8WAgAAGUICAAB/eAIAAyPCAgAb+3GA= Date: Wed, 14 Dec 2016 23:18:59 +0000 Message-ID: References: <20161209073122.GB1513@kroah.com> <20161209102030.1f550c5a@xeon-e3> <20161209122935.2bd0779e@xeon-e3> <20161209134510.22087f81@xeon-e3> <20161209140509.1dd7cad2@xeon-e3> <20161209162148.44887938@xeon-e3> <20161210122059.GA21421@kroah.com> In-Reply-To: <20161210122059.GA21421@kroah.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=haiyangz@microsoft.com; x-originating-ip: [72.74.33.140] x-microsoft-exchange-diagnostics: 1;BLUPR03MB1411;7:PS1SIu+Exe5IOgasHbm/icVpFPMqx4ezmsoyb0BUFdY/tcRtEK6uKzBs5wxR8l3H6D4YOuO0T+MNeMEg2kFCy9J/tHSpeVEmCyzoZ0OZ0/OUpKf7yPaBjHuZW0qkDah/Upx6hg03h6t7paw7PrOcOpLZ1ff15WIiFN4XMMRTq1HP5dpho8cbRiz2Kgxe61LGHxvIB5vzK4ZeMrcDBN1kdKZEv4D+ApS2OcBuhBrxEmvtb/jU6Jl6YBfW9CNtoRLsUvXzGoGysI2j3uIhIU+YREy24C1I3hRUHVvkFtzOBKHkOKOoOAWjcxArvr3sbJloGZaBcSJZ0+baqKK2ijr/DpVBjcumuLWOcqCY/Kx3uKmfCXisDnOX0/qJzp0cub8O x-ms-office365-filtering-correlation-id: 78a0a870-b047-49a3-fc75-08d4247795f4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BLUPR03MB1411; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(9452136761055)(198206253151910); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148)(6047074);SRVR:BLUPR03MB1411;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1411; x-forefront-prvs: 01565FED4C x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(39860400002)(39450400003)(39840400002)(39850400002)(39410400002)(24454002)(13464003)(377454003)(189002)(40224003)(199003)(6506006)(38730400001)(7736002)(92566002)(74316002)(305945005)(5660300001)(76176999)(6436002)(189998001)(2900100001)(229853002)(86362001)(2906002)(50986999)(93886004)(3660700001)(10090500001)(39060400001)(97736004)(76576001)(5001770100001)(77096006)(2950100002)(4326007)(3280700002)(106116001)(8676002)(102836003)(6116002)(99286002)(86612001)(5005710100001)(81166006)(105586002)(122556002)(8990500004)(106356001)(81156014)(33656002)(7696004)(101416001)(3846002)(8936002)(54356999)(66066001)(10290500002)(9686002)(68736007)(25786008);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR03MB1411;H:BLUPR03MB1412.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2016 23:18:59.9776 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1411 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uBF2qDrW019026 > -----Original Message----- > From: Greg KH [mailto:gregkh@linuxfoundation.org] > Sent: Saturday, December 10, 2016 7:21 AM > To: Stephen Hemminger > Cc: Haiyang Zhang ; olaf@aepfle.de; > jasowang@redhat.com; linux-kernel@vger.kernel.org; > bjorn.helgaas@gmail.com; apw@canonical.com; devel@linuxdriverproject.org; > leann.ogasawara@canonical.com > Subject: Re: [PATCH 3/3] hv_netvsc: Implement VF matching based on > serial numbers > > On Fri, Dec 09, 2016 at 04:21:48PM -0800, Stephen Hemminger wrote: > > On Fri, 9 Dec 2016 22:35:05 +0000 > > Haiyang Zhang wrote: > > > > > > > > > > > > > > Emulated NIC is already excluded in start of netvc notifier > handler. > > > > > > > > > > > > static int netvsc_netdev_event(struct notifier_block *this, > > > > > > unsigned long event, void *ptr) > > > > > > { > > > > > > struct net_device *event_dev = > netdev_notifier_info_to_dev(ptr); > > > > > > > > > > > > /* Skip our own events */ > > > > > > if (event_dev->netdev_ops == &device_ops) > > > > > > return NOTIFY_DONE; > > > > > > > > > > > > > > > > Emulated device is not based on netvsc. It's the native Linux > > > > (dec100M?) > > > > > Driver. So this line doesn't exclude it. And how about other NIC > type > > > > > may be added in the future? > > > > > > > > Sorry, forgot about that haven't used emulated device in years. > > > > The emulated device should appear to be on a PCI bus, but the > serial > > > > would not match?? > > > > > > It's not a vmbus device, not a hv_pci device either. Hv_PCI is a > subset > > > of vmbus devices. So emulated NIC won't have hv_pci serial number. > > > > > > In my patch, the following code ensure, we only try to get serial > number > > > after confirming it's vmbus and hv_pci device: > > > > > > + if (!dev_is_vmbus(dev)) > > > + continue; > > > + > > > + hdev = device_to_hv_device(dev); > > > + if (hdev->device_id != HV_PCIE) > > > + continue; > > > > Ok, the walk back up the device tree is logically ok, but I don't > > know enough about PCI device tree to be assured that it is safe. > > Also, you could short circuit away most of the unwanted devices > > by making sure the vf_netdev->dev.parent is a PCI device. > > Ugh, this seems really really messy. Can't we just have the > netdev_event interface pass back a pointer to something that we "know" > what it is? This walking the device tree is a mess, and not good. > > I'd even argue that dev_is_pci() needs to be removed from the tree too, > as it shouldn't be needed either. We did a lot of work on the driver > model to prevent the need for having to declare the "type" of 'struct > device' at all, and by doing this type of thing it goes against the > basic design of the model. > > Yes, it makes things a bit "tougher" in places, but you don't do crazy > things like walk device trees to try to find random devices and then > think it's safe to actually use them :( > We register a notifier_block with: register_netdevice_notifier(struct notifier_block *nb) The "struct notifier_block" basically contains a callback function: struct notifier_block { notifier_fn_t notifier_call; struct notifier_block __rcu *next; int priority; }; It doesn't specify which device we want, so all net devices can trigger this event. Seems we can't have this notifier return VF device only. Thanks, - Haiyang