On Thu, Jul 11, 2019 at 08:40:34PM -0700, Florian Fainelli wrote: > > > On 7/11/2019 4:53 PM, Neil Horman wrote: > >> I would like to emphasize that the configuration of whether these > >> dropped packets are even sent to the CPU from the device still needs to > >> reside in devlink given this is the go-to tool for device-specific > >> configuration. In addition, these drop traps are a small subset of the > >> entire packet traps devices support and all have similar needs such as > >> HW policer configuration and statistics. > >> > >> In the future we might also want to report events that indicate the > >> formation of possible problems. For example, in case packets are queued > >> above a certain threshold or for long periods of time. I hope we could > >> re-use drop_monitor for this as well, thereby making it the go-to > >> channel for diagnosing current and to-be problems in the data path. > >> > > Thats an interesting idea, but dropwatch certainly isn't currently setup for > > that kind of messaging. It may be worth creating a v2 of the netlink > > protocol > > and really thinking out what you want to communicate. > > Is not what you describe more or less what Ido has been doing here with > this patch series? possibly, I was only CCed on this thread halfway throught the conversation, and only on the cover letter, I've not had a chance to look at the entire series
Neil > -- > Florian >
