Alexey Orishko <alexey.orishko@xxxxxxxxx> writes: > Hi all, > > On Wed, May 22, 2013 at 10:40 PM, Bjørn Mork <bjorn@xxxxxxx> wrote: > >> Thomas Schäfer <tschaefer@xxxxxxxxxxx> writes: >> >> > 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. >> >> > It is possible to count exact size of IP packets in Tx(Rx) direction, since > we know > size of each IP packet when we add(extract) it into(from) NTB. And it's > possible > to make this information available to user space application as well. Yes, looking quickly at this I believe usbnet in general could benefit from having ethtool stats added, including a few extra counters showing bytes/packets before calling the minidriver rx/tx fixup functions. This would be useful for all minidrivers using some sort of extra framing. > However, the main problem is that host driver statistic will never be exact > match > of the statistic done by mobile operator while charging you for the used > traffic. > They most likely are charging you for the volume over the air and it means > additional framing from 3GPP protocol stack, which is unavailable for ncm > driver. > Also there might be some internal applications on mobile device which are > generating some traffic over the air. > > I would rather rely on Tx/Rx values provided via AT commands by each > vendor (if implemented) instead of using usb driver counters. Agreed. That is definitely much better if available. But this doesn't rule out the possibility of adding more driver counters as well. 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
