On 09/28/2017 11:40 AM, Pavel Machek wrote: > Hi! > > On Mon 2017-09-18 20:27:13, tristram...@microchip.com wrote: >>>> +/** >>>> + * Some counters do not need to be read too often because they are less >>> likely >>>> + * to increase much. >>>> + */ >>> >>> What does comment mean? Are you caching statistics, and updating >>> different values at different rates? >>> >> >> There are 34 counters. In normal case using generic bus I/O or PCI to read >> them >> is very quick, but the switch is mostly accessed using SPI, or even I2C. As >> the SPI >> access is very slow and cannot run in interrupt context I keep worrying >> reading >> the MIB counters in a loop for 5 or more ports will prevent other critical >> hardware >> access from executing soon enough. These accesses can be getting 1588 PTP >> timestamps and opening/closing ports. (RSTP Conformance Test sends test >> traffic >> to port supposed to be closed/opened after receiving specific RSTP >> BPDU.) > > Hmm. Ok, interesting. > > I wonder how well this is going to work if userspace actively 'does > something' with the switch. > > It seems to me that even if your statistics code is careful not to do > 'a lot' of accesses at the same time, userspace can use other parts of > the driver to do the same, and thus cause same unwanted effects...
A few switches have a MIB snapshot feature that is implemented such that accessing the snapshot does not hog the remainder of the switch registers, is this something possible on KSZ switches? Tangential: net-next is currently open, so now would be a good time to send a revised version of your patch series to target possibly 4.15 with an initial implementation. Please fix the cover-letter and patch threading such that they look like the following: [PATCH 0/X] [PATCH 1/X] [PATCH 2/X] etc.. Right now this shows up as separate emails/patches and this is very annoying to follow as a thread. Thank you -- Florian
