On Mon, Jun 08, 2015 at 10:52:34AM +0300, Haggai Eran wrote: > On 04/06/2015 19:40, Jason Gunthorpe wrote: > > Discussion idea: Can we actually use the netstack to process the > > RDMA-CM packets? It looks like the netstack wants a skb to do this > > mid-layer work, so rdma-cm would have to synthesize a skb for the CM > > packets and pass it through netdev to apply all the transformations > > and access the various internal states (eg from ipvlan, bonding, > > etc). rdma-cm would have to 'catch' the skb once it is done traveling > > and resume its normal processing. Very similar to your notion of using > > UDP, but without any on-the-wire change. > > > > This would fit in that same ingress spot I suggested adding the > > routing lookup, instead of routing we want the full stack to have a go > > at figuring out the final netdev. > > > > This seems the most general because it will work for all the *vlan > > type drivers, bonding, and all of the RDMA technologies. (each would > > have a slightly different way to make the skb, but same basic idea) > > > > Lots and lots of details to do that, but conceptually it seems pretty > > solid? > > The problem is that the network stack can do all sort of changes to the > packets (like NAT), and it may be the case that the hardware can't > reflect these changes later on when creating a QP.
Yes, I am aware of that, but there are also alot of things netdev can do that we can realize, like netfilter rules to block packets, for instance Ignoring NAT is a bad choice as well, the best would be to drop on NAT. It would be easy to detect if the netstack mangled the REQ skb packet, for instance. We can't track netdev after the QP is created, but totally ignoring one thing and while re-implementing others seems like a bad idea, long term... > I think it would be best to stick with resolving the net_dev using > the request parameters, and the simpler routing lookup. This way > RDMA CM remains in control, and if the user configures routing in an > unexpected way, it can just block the request. As I said, I think that is fine for the immediate IB support, but when you start talking about roce and emulating macvlan and ipvlan.. Then it starts to look really bad. At least think it through carefully before posting those series. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
