On Mon, 05 Feb 2024 16:49:33 +0100 Paolo Abeni <pab...@redhat.com> wrote:
[... > > > > > > In general is quite bad that the existing infra does not allow > > > leveraging NAPI. Have you considered expanding the QMC to accomodate > > > such user? > > > > I cannot mask/unmask the 'end of transfer' interrupt. > > Indeed, other streams use this interrupt among them audio streams and so > > masking the interrupt for HDLC data will also mask the interrupt for audio > > data. > > Uhm... I fear the above makes the available options list empty :( > > > At the HDLC driver level, the best I can to is to store a queue of complete > > HDLC skbs (queue filled on interrupts) and send them to the network stack > > when the napi poll() is called. > > > > I am not sure that this kind of queue (additional level between always > > enabled interrupts and the network stack) makes sense. > > > > Do you have any opinion about this additional queue management for NAPI > > support? > > With such idea in place, what HDLC-level data will be accessed by the > napi context? The RX interrupts will remain unmasked after the > interrupt and before the napi poll right? That would be > problematic/could cause drop if the ingress pkt/interrupt rate will be > higher that what the napi could process - and that in turn could bring > back old bad livelock times :( Indeed. So the best thing to do is to keep this driver without NAPI support. Best regards, Hervé