Hi, Thank you for the prompt reply!
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). > 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. > > 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
