netdev - Re: [PATCH v4 for-next 00/12] Add network namespace support in the RDMA-CM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 8 Jun 2015 10:52:34 +0300
From:	Haggai Eran <haggaie@...lanox.com>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
CC:	Or Gerlitz <gerlitz.or@...il.com>,
	Doug Ledford <dledford@...hat.com>,
	"Or Gerlitz" <ogerlitz@...lanox.com>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Liran Liss <liranl@...lanox.com>,
	Guy Shapiro <guysh@...lanox.com>,
	"Shachar Raindel" <raindel@...lanox.com>,
	Yotam Kenneth <yotamke@...lanox.com>
Subject: Re: [PATCH v4 for-next 00/12] Add network namespace support in the
 RDMA-CM

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. 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.

Haggai
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html