On (09/12/18 19:07), Alexei Starovoitov wrote: > > 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.
I dont know if you have been following the RFC series at all (and DanielB/JohnF feedback to it) but that is not what the patch set is about. To repeat a summary of the original problem statement: RDS (hardly a "niche" driver, let's please not get carried away with strong assertions based on incomplete understanding), is an example of a driver that happens to pass up packets as both scatterlist and sk_buffs to the ULPs. The scatterlist comes from IB, the sk_buffs come from the ethernet drivers. At the moment, the only way to build firewalls for this is to convert scatterlist to skb and use either netfilter or eBPF on the skb. What Tushar is adding is support to use eBPF on the scatterlist itself, so that you dont have to do this inefficient scatterlist->skb conversion. > 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. After I sent the message, I noticed that selftests/bpf has some tests using veth/netns. I think Tushar should be able to write tests for the rds-tcp path (and thus test the eBPF infrastructure, which seems to be what you are worried about) Does that address your concern? --Sowmini
