On 7/10/19 4:52 PM, Edward Cree wrote: > Hmm, I was caught out by the call to napi_poll() actually being a local > function pointer, not the static function of the same name. How did a > shadow like that ever get allowed? > But in that case I _really_ don't understand napi_busy_loop(); nothing > in it seems to ever flush GRO, so it's relying on either > (1) stuff getting flushed because the bucket runs out of space, or > (2) the next napi poll after busy_poll_stop() doing the flush. > What am I missing, and where exactly in napi_busy_loop() should the > gro_normal_list() call go? Please look at busy_poll_stop()
- [RFC PATCH net-next 0/3] net: batched receive in GRO path Edward Cree
- [RFC PATCH net-next 1/3] sfc: don't score irq moderation... Edward Cree
- [RFC PATCH net-next 3/3] net: use listified RX for handl... Edward Cree
- [RFC PATCH net-next 2/3] sfc: falcon: don't score irq mo... Edward Cree
- Re: [RFC PATCH net-next 0/3] net: batched receive in GRO... Paolo Abeni
- Re: [RFC PATCH net-next 0/3] net: batched receive in... Edward Cree
- Re: [RFC PATCH net-next 0/3] net: batched receiv... Eric Dumazet
- Re: [RFC PATCH net-next 0/3] net: batched re... Edward Cree
- Re: [RFC PATCH net-next 0/3] net: batch... Eric Dumazet
- Re: [RFC PATCH net-next 0/3] net: b... Edward Cree
- Re: [RFC PATCH net-next 0/3] ne... Eric Dumazet
- Re: [RFC PATCH net-next 0/3] ne... David Miller
- Re: [RFC PATCH net-next 0/3] ne... Edward Cree
- Re: [RFC PATCH net-next 0/3] ne... Edward Cree