On Fri, Sep 14, 2018 at 1:16 PM Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > > On Fri, Sep 14, 2018 at 11:47 AM Paolo Abeni <pab...@redhat.com> wrote: > > > > Currently, the UDP GRO callback is always invoked, regardless of > > the existence of any actual user (e.g. a UDP tunnel). With retpoline > > enabled, this causes measurable overhead. > > > > This changeset introduces explicit accounting of the sockets requiring > > UDP GRO and updates the UDP offloads at runtime accordingly, so that > > the GRO callback is present (and invoked) only when there is at least > > one socket requiring it. > > I have a difference solution both to the UDP socket lookup avoidance > and configurable GRO in general. > > I've been sitting on it for too long. Let me slightly clean it up and > send it out for discussion sake..
http://patchwork.ozlabs.org/project/netdev/list/?series=65763 That udp gro implementation is clearly less complete than yours in this patchset. The point I wanted to bring up for discussion is not the protocol implementation, but the infrastructure for enabling it conditionally. Assuming cycle cost is comparable, what do you think of using the existing sk offload callbacks to enable this on a per-socket basis? As for the protocol-wide knob, I do strongly prefer something that can work for all protocols, not just UDP. I also implemented a version that atomically swaps the struct ptr instead of the flag based approach I sent for review. I'm fairly agnostic about that point. One subtle issue is that I believe we need to keep the gro_complete callbacks enabled, as gro packets may be queued for completion when gro_receive gets disabled.
