On Wed, Sep 12, 2018 at 08:59:54PM -0400, Sowmini Varadhan wrote: > > On 09/11/2018 09:00 PM, Alexei Starovoitov wrote: > > >please no samples. > > >Add this as proper test to tools/testing/selftests/bpf > > >that reports PASS/FAIL and can be run automatically. > > >samples/bpf is effectively dead code. > > Just a second. > > You do realize that RDS is doing real networking, so it needs > RDMA capable hardware to test the rds_rdma paths? Also, when we > "talk to ourselves" we default to the rds_loop transport, so > we would even bypass the rds-tcp module. > > I dont think this can be tested with some academic "test it > over lo0" exercise.. I suppose you can add example code in > sefltests for this, but asking for a "proper test" may be > a litte unrealistic here- a proper test needs proper hardware > in this case.
I didn't know that. The way I understand your statement that this new program type, new sg logic, and all the complexity are only applicable to RDMA capable hw and RDS. In such case, I think, such BPF extensions do not belong in the upstream kernel. I don't want BPF to support niche technologies, since the maintenance overhead makes it prohibitive long term. If the kernel had a way to deprecate the api it would have been different story. Every new feature and bpf extension lands once and then being maintained forever. Hence we have to be very selective weighting the benefits vs long term maintenance. I'm happy to review the code further and suggest improvements, but it's not going to be applied.
