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:	Tue, 26 May 2015 10:59:28 -0600
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	Doug Ledford <dledford@...hat.com>
Cc:	Haggai Eran <haggaie@...lanox.com>, linux-rdma@...r.kernel.org,
	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 Tue, May 26, 2015 at 09:34:40AM -0400, Doug Ledford wrote:

> This is a core feature more than anything else.  Namespaces for RDMA
> devices is not unique to IB or RoCE in any way.  Yet no thought has been
> given to how this will work universally across all of the RDMA
> capable

I think if Haggi is able to follow the perscription I gave then things
will be general.

 - All rdma cm ids are associated with a netdev
 - The output flow uses that netdev to restrict, configure and
   determine the output RDMA device QP
 - The input flow locates the netdev as step one and then uses the
   (netdev,ip,port) tuple to find the rdma listener, which is in turn
   tied to a netdev and is restricted/configured by it.

The technology specific part is the two maps: from (input
device,packet) to netdev, from netdev to (output device,packet)

After the above clean up is done, namespace enabling is basically
providing those two mapping functions for each technology in a way
that can locate delegatable netdevs.

The trivial case for all the ethernet techs is to provide the above
maps that can take the (input device,VLAN) and locate the correct
child VLAN specific netdev. The existing code to support VLAN should
pretty much immediately enable basic namespace support for all the
ethernet families.

The big open question for ethernet is how to work without relying on
VLAN to create delgated netdevs - typically one would use a bridge and
veth's, which do not seem very RDMA compatible. But that doesn't need
to be answered right now.

Remember, this isn't RDMA namespaces, this is netdev namespace support
for RDMA-CM -> very different things.

Basically, I'm happy with the generality story, if the clean up work I
outlined turns out..

> issue for usNIC as if you want namespace support there, you just start
> the user space app in a given namespace and you are probably 90% of
> the

usNIC has no kernel facing functionality, and no interaction with
RDMA-CM, so it is irrelevant to any discussion about RDMA-CM :(

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