3 ms·
I setup the AUR package [0] for this while troubleshooting some dropped UDP data and was kind of shocked at how hard this tool was to used. It reported tons of
by 2bluesc 6y ago
I setup the AUR package [0] for this while troubleshooting some dropped UDP data and was kind of shocked at how hard this tool was to used. It reported tons of drops everywhere that I couldn't observe from userspace on any of my tests.
Is anyone aware of an overview showing how to approach and get started with this tool?
[0] https://aur.archlinux.org/packages/dropwatch/ https://aur.archlinux.org/packages/dropwatch/
- Ao7bei3s 6y agodropwatch's definition of drop is literally kfree_skb, ie kernel stops processing a packet (plus changes to drop count at napi device). Don't think of it as recording drops, think of it as recording the ultimate fate of every packet, including e.g. iptables -j DROP, but also e.g. successful transmit by your network driver. dropwatch is a low level tool. I've found it useful to perform a baseline test to see "normal" drops and their rates, then run intense test traffic and compare. You pretty much have to understand each reported call site by looking at the kernel source code. As you gain experience with the kernel network code, you learn which locations do what, and how to access the regular statistics for them. Having the (outdated but) relevant kernel networking books on your desk helps.
- 2bluesc 6y ago> dropwatch's definition of drop is literally kfree_skb Wow, this changes everything. Thanks for clarifying. With this insight `dropwatch` sounds much harder to use then suggested.