On Thu, 2015-05-28 at 16:07 +0300, Haggai Eran wrote: > On 26/05/2015 16:34, Doug Ledford wrote: > > On Sun, 2015-05-17 at 08:50 +0300, Haggai Eran 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 > > devices (mainly I'm talking about iWARP here... > I don't agree. It is true we have are not planning to provide an iWarp > implementation for network namespaces, as we lack the capacity and the > expertise. However, I think that the changes we proposed to the rdma_cm > module will work with iWarp too. Perhaps with some of Jason's > suggestions it will be smoother, but even in the current design, I think > that if iWarp drivers can provide iw_cm with the network device on which > a request is received, then it should be simple to modify it for > namespace support without significant change to rdma_cm.
My request wasn't for a functional implementation, just a statement that
you had in fact thought about it and, as you say here, would expect it
to work (and preferably why as well).
> Well, because the RDMA subsystem supports a very diverse set of devices,
> I think there are few people who know the details of all hardware types
> well. If we are going to evolve the generic parts of the stack, we have
> to cooperate. We have to rely on the knowledge of people on the mailing
> list to say whether the feature is well designed for all hardware types,
> or whether changes are warranted. In this specific case, the patches has
> been on the list since February. I think it is enough time to allow
> anyone who is interested in network namespace support to chime in.
You would think that, but sometimes important information comes from
totally different places. See mine and Jason's comments back and forth
in the SRIOV thread started by Or.
Long story short:
ip link add dev ib0 name ib0.1 type ipoib
is totally broken on at least all Red Hat OSes. It will require
reworking of the network scripts and NetworkManager assumptions to make
it work. It will also break DHCP on the interface as pkey/guid are the
only items that uniquely identify DHCP clients. The net result of our
talks was that it is likely that each interface on the same pkey will
require an alias GUID per child interface in order to keep things
workable.
--
Doug Ledford <dledf...@redhat.com>
GPG KeyID: 0E572FDD
signature.asc
Description: This is a digitally signed message part
