On Fri, 2016-10-28 at 10:50 -0700, Eric Dumazet wrote: > On Fri, 2016-10-28 at 10:16 -0700, Eric Dumazet wrote: > > Nice ! > > > > I was working on this as well and my implementation was somewhat > > different. > > This is my WIP > > Note this can be split in two parts. > > 1) One adding struct sock *sk param to ip_cmsg_recv_offset() > > This was because I left skb->sk NULL for skbs stored in receive > queue. > You chose instead to set skb->sk, which is unusual (check > skb_orphan() BUG_ON()) > > 2) Udp changes. > > Tell me what you think, thanks again ! Thank you for working on this. I just gave a very quick look (the WE has started, children are screaming ;-), overall the implementation seems quite similar to our one. I like the additional argument to ip_cmsg_recv_offset() instead of keeping skb->sk set. If I read udp_skb_destructor() correctly, the atomic manipulation of both sk_rmem_alloc and udp_memory_allocated will happen under the receive lock. In our experiments this increment measurably the contention on the lock in respect to moving said the operations outside the lock (as done in our patch). Do you foreseen any issues with that ? AFAICS every in kernel UDP user of skb_recv_datagram() needs to be updated with both implementation. Cheers, Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
