On Wed, Apr 18, 2018 at 7:44 AM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Mon, Apr 16, 2018 at 08:43:31AM -0700, Eric Dumazet wrote: >> >> >> On 04/16/2018 08:33 AM, Yafang Shao wrote: >> > tcp_rcv_space_adjust is called every time data is copied to user space, >> > introducing a tcp tracepoint for which could show us when the packet is >> > copied to user. >> > This could help us figure out whether there's latency in user process. >> > >> > When a tcp packet arrives, tcp_rcv_established() will be called and with >> > the existed tracepoint tcp_probe we could get the time when this packet >> > arrives. >> > Then this packet will be copied to user, and tcp_rcv_space_adjust will >> > be called and with this new introduced tracepoint we could get the time >> > when this packet is copied to user. >> > >> > arrives time : user process time => latency caused by user >> > tcp_probe tcp_rcv_space_adjust >> > >> > Hence in the prink message, sk is printed as a key to connect these two >> > tracepoints. >> > >> >> socket pointer is not a key. >> >> TCP sockets can be reused pretty fast after free. >> >> I suggest you go for cookie instead, this is an unique 64bit identifier. >> ( sock_gen_cookie() for details ) > > I think would be even better if the stack would do this sock_gen_cookie() > on its own in some way that user cannnot infere the order. > In many cases we wanted to use socket cookie, but since it's not inited > by default it's kinda useless. > Turning this tracepoint on just to get cookie would be an ugly workaround. >
Could we init it in sk_alloc() ? Then in other code paths, for example sock_getsockopt or tracepoints, we only read the value through a new inline function named sock_read_cookie(). Thanks Yafang
