Understanding what's missing is important. It doesn't require prototyping netlink statistics in ib subsystem. Latest Cisco VIC adapters only report rx byte/pkt counts on flows. Users expect networking statistics to report both tx and rx counts. If a tx or rx counter is 0 or missing altogether it is *assumed* that counter is 0. Because Cisco VIC adapters only reports rx byte/pkt counts, these statistics confuse/mislead the user if exposed through a standard interface. Hence, we do not wish to report these through any tools easily accessible to the user. The statistics being exposed are for developers, who understand the caveats, for debugging and the most apt interface for this purpose is debugfs.
Upinder On Jan 13, 2014, at 3:39 PM, Or Gerlitz <[email protected]> wrote: > On Tue, Jan 14, 2014 at 12:14 AM, Upinder Malhi (umalhi) > <[email protected]> wrote: >> We are happy to use netlink if it makes sense. What you are saying is: >> Netlink is used all over the kernel. Bc it is used all over the kernel, it >> must be the right answer for all userspace/kernel interactions. Therefore, >> if something doesn't use netlink, it must be wrong (ex. procfs, sysfs, >> debugfs). >> >> We want to put the rx byte/packet count in debug fs because it is intended >> for developers. We do not want to put these in a common infrastructure bc >> as we have found internally, lacking tx statistics confuses users. We are >> being asked to write the ib core statistics infrastructure, that if it was >> available today, we would not use. So unless someone else jumps in here, we >> are going to keep these in the debug fs. > > What wrong with exposing the the flow tuples from netlink and then see > what's missing that justified debugfs? > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
