On Fri, Oct 5, 2018 at 11:30 AM Paolo Abeni <pab...@redhat.com> wrote: > > Hi, > > Thank you for the prompt reply! >
Not at all. Thanks for moving this forward :) > On Fri, 2018-10-05 at 10:41 -0400, Willem de Bruijn wrote: > > On Fri, Oct 5, 2018 at 9:53 AM Paolo Abeni <pab...@redhat.com> wrote: > > > > > > Hi all, > > > > > > On Fri, 2018-09-14 at 13:59 -0400, Willem de Bruijn wrote: > > > > This is a *very rough* draft. Mainly for discussion while we also > > > > look at another partially overlapping approach [1]. > > > > > > I'm wondering how we go on from this ? I'm fine with either approaches. > > > > Let me send the udp gro static_key patch. > > Would love that. We need to care of key decr, too (and possibly don't > be fooled by encap_rcv() users). I just sent http://patchwork.ozlabs.org/patch/979525/ Right now all users are those that call setup_udp_tunnel_sock to register encap_rcv. If accepted, I'll add a separate patch to decrement the key. That's probably in udp_tunnel_sock_release, but I need to take a closer look. > > Then we don't need the enable udp on demand logic (patch 2/4). > > ok. > > > Your implementation of GRO is more fleshed out (patch 3/4) than > > my quick hack. My only request would be to use a separate > > UDP_GRO socket option instead of adding this to the existing > > UDP_SEGMENT. > > > > Sounds good? > > Indeed! > I need also to add a cmsg to expose to the user the skb gro_size, and > some test cases. Locally I'm [ab-]using the GRO functionality > introduced recently on veth to test the code in a namespace pair > (attaching a dummy XDP program to the RX-side veth). I'm not sure if > that could fit a selftest. Very nice. Yes, veth only implements napi in xdp mode. > > > > Also, I'm interested in [try to] enable GRO/GSO batching in the > > > forwarding path, as you outlined initially in the GSO series > > > submission. That should cover Steffen use-case, too, right? > > > > Great. Indeed. Though there is some unresolved discussion on > > one large gso skb vs frag list. There has been various concerns > > around the use of frag lists for GSO in the past, and it does not > > match h/w offload. So I think the answer would be the first unless > > the second proves considerably faster (in which case it could also > > be added later as optimization). > > Agreed. > > Let's try the first step first ;) > > Final but relevant note: I'll try my best to avoid delaying this, but > lately I tend to be pre-empted by other tasks, it's difficult for me to > assure a deadline here. > > Cheers, > > Paolo >
