Geliang Tang wrote: > On Mon, 2024-05-27 at 21:36 +0200, Jakub Sitnicki wrote: > > On Mon, May 27, 2024 at 10:12 AM -07, John Fastabend wrote: > > > Geliang Tang wrote: > > > > From: Geliang Tang <tanggeliang@xxxxxxxxxx> > > > > > > > > Switch attachments to bpf_link using > > > > bpf_program__attach_sockmap() instead > > > > of bpf_prog_attach(). > > > > > > Sorry it took me a few days to get to this. > > > > > > Is there a reason to push this to links vs just leave it as is? I > > > had > > > a plan to port all the test_sockmap tests into prog_tests anyways. > > > I'll > > > try to push some initial patch next week. > > Great, I strongly agree with porting them into prog_tests. I am also > willing to participate in implementing this plan together. I have a first patch that starts to move things I'll dig it up here. Still a bit behind on everything as you see its Thr already. > > > > > > > The one advantage of test_sockmap is we can have it run for longer > > > runs by pushing different options through so might be worth keeping > > > just for that. > > > > > > If you really want links here I'm OK with that I guess just asking. > > > > It was me who suggested the switch to bpf_link in reaction to a > > series > > of cleanups to prog_type and prog_attach_type submitted by Geliang. > > Yes, patches 3-5 address Jakub's suggestion: switching attachments to > bpf_link. OK. Lets just take them the series lgtm. Jakub any other comments? > > > Relevant threads: > > > > https://lore.kernel.org/bpf/9c10d9f974f07fcb354a43a8eca67acb2fafc587.1715926605.git.tanggeliang@xxxxxxxxxx > > https://lore.kernel.org/bpf/20240522080936.2475833-1-jakub@xxxxxxxxxxxxxx > > https://lore.kernel.org/bpf/e27d7d0c1e0e79b0acd22ac6ad5d8f9f00225303.1716372485.git.tanggeliang@xxxxxxxxxx > > > > I thought bpf_links added more value than cleaning up "old style" > > attachments. > > Other patches 1-2, 6-8 are small fixes which I found while trying to > solve the NONBLOCK issue [1]. Yes, I haven't given up on solving this > issue yet. I think it must be solved, since there is a bug somewhere. > WDYT? Yes I think this is an actual issue with the stream parser waking up sockets before the data is copied into the recv buffers.
