On 12/16/19 3:08 PM, Alexei Starovoitov wrote: > On 12/16/19 11:14 AM, Martin Lau wrote: >> At least for bpf_dctcp.c, I did not expect it could be that close to tcp_dctcp.c >> when I just started converted it. tcp_cubic/bpf_cubic still has some TBD >> on jiffies/msec. >> >> Agree that it is beneficial to have one copy. It is likely >> I need to make some changes on the tcp_*.c side also. Hence, I prefer >> to give it a try in a separate series, e.g. revert the kernel side >> changes will be easier. > > I've looked at bpf_cubic.c and bpf_dctcp.c as examples of what this > patch set can do. They're selftests of the feature. > What's the value of keeping them in sync with real kernel cc-s? > I think it's fine if they quickly diverge. > The value of them as selftests is important though. Quite a bit of BTF > and verifier logic is being tested. > May be add a comment saying that bpf_cubic.c is like cubic, but doesn't > have to be exactly cubic ? > The reason I mentioned this is that I am currently working on a fix of Hystart logic, which is quite broken at the moment. (hystart_train detection triggers in cases it should not) But yes, if we add a comment warning potential users, this should be fine.