On 3/9/20 11:54 AM, Dave Taht wrote: > I am happy to see this driver upstream. > >> Arnd's concern was that the rmnet_data0 network device does not >> have the benefit of information about the state of the underlying >> IPA hardware in order to be effective in controlling TX flow. >> The feared result is over-buffering of TX packets (bufferbloat). >> I began working on some simple experiments to see whether (or how >> much) his concern was warranted. But it turned out that completing >> these experiments was much more work than had been hoped. > > Members of the bufferbloat project *care*, and have tools and testbeds for > exploring these issues. It would be good to establish a relationship with > the vendor, obtain hardware, and other (technical and financial) support, if > possible. > > Is there any specific hardware now available (generally or in beta) that > can be obtained by us to take a harder look? A contact at linaro or QCA > willing discuss options? There exists some hardware that could be used, but at the moment I have not ported this code to operate on it. It is a current effort however, and I will be glad to keep you in the loop on progress. There are a couple of target environments we'd like to support but until last week the primary goal was inclusion in the upstream tree. I will follow up with you after the dust settles a little bit with this patch series, maybe in a week or so. In the mean time I'll also find out whether there are any other resources (people and/or hardware) available. -Alex
