On Tue, Dec 19, 2023 at 5:24 AM Oliver Neukum <oneukum@xxxxxxxx> wrote: > > On 19.12.23 13:19, Maciej Żenczykowski wrote: > > On Tue, Dec 19, 2023 at 12:45 AM Oliver Neukum <oneukum@xxxxxxxx> wrote: > >> > >> > >> > >> On 19.12.23 00:00, Maciej Żenczykowski wrote: > > > Perhaps. I've been looking at the gadget tx code, and assuming hrtimers work, > > I don't see how it could possibly screw up... the hrtimer arm/cancel > > are clearly > > at the same spot in the code where we allocate/unqueue the ncm->skb_tx_data > > > > (I have found a potential use-after-free-on-error bug and a stupidity > > that I'll send fixes for, > > but that doesn't appear related to this thread) > > Yes. Could there be a logic bug in the algorithm? Perhaps? But, as I said... I'm not seeing it (on the gadget side). > Maybe it is necessary to also consider the time the first packet > was queued and to transmit if that is too long in the past? The gadget side does not (any more) adjust the timer (on later packets)... Which is part of what makes it so simple logic wise... This sort of bug would likely be easier to make on the host side cdc_ncm driver... I'm still not following it's logic... > > > But the host side driver seems more complex/confusing. > > However, I've not really ever looked at it previously though, so it > > might just be that... > > How can Hiago determine that? If you do a ping from the gadget > to the host, tcpdump should show the timing of the echo requests, > shouldn't it? If they arrive simultaneously we at least know which > side the issue is on. I guess you could ping on one side, and run tcpdump on the *other*. Then look at the timestamps on the tcpdump vs ping cli reported... If tcpdump shows ping requests coming in at equal intervals... then the ping sender side + receiver is OK, and the problem must be the return path. > > Regards > Oliver > -- Maciej Żenczykowski, Kernel Networking Developer @ Google
