Thomas Schäfer <tschaefer@xxxxxxxxxxx> writes: > Hello Bjørn > > ... > > TX-counter-problem > ... > >> This is expected as a result of the cdc_ncm <=> usbnet design. > ..... > >> >> The buffer filling may seem strange, but Alexey has explained it several >> times here on this list. It has to do with device DMA optimizations. >> Google it or search this list if you want the proper explanation. >> > > Thank you for the explanation (again). > May be the following question is also repeated. > Is there a different way to count the tx bytes? On mobile devices, mostly > with volume-limited contracts, this number may have a higher meaning than > normal. Yes, I understand that. I don't have any good answers. You really want to know the number of bytes transmitted and received by the modem. This is never the same as the host counters, but the approximation is good enough for most drivers. Just not for cdc_ncm (or cdc_mbim which use the same logic). If you can read the modem counters via some management protocol, then that would be best. But I don't know if that is supported for devices using cdc_ncm with AT command managent. We should probably make a better "payload" counter available for cdc_ncm and cdc_mbim. I must admit that I know next to nothing about netdev counter policies. I assume the current driver behaviour is correct (it really counts the number of bytes transferred from the host to the device). Maybe you could research this a bit? If the current behaviour is considered correct, how do we add other counters to a driver? This needs to be done in a generic way. I am pretty sure there are examples of net drivers counting lots of stuff. Actually counting the bytes isn't hard. It's the userspace interface that needs some consideration. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
