On Thu, Sep 13, 2018 at 06:10:13AM -0400, Sowmini Varadhan wrote: > 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.
if the goal is to add firewall ability to RDS then the patch set is going in the wrong direction. New bpf prog type and attaching to sockets isn't going to be helpful in building firewalls. Also there was a mention of some form of 'redirect' for some future use? That doesn't fit the firewall goal as well. I think it would be the best to start from scratch and discuss the bigger goal first. May be the right answer is to teach rds to behave like the rest of protocols. Then all existing tooling and features will 'just work' ?
