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?
--
Florian
