[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1432647280.28905.107.camel@redhat.com>
Date: Tue, 26 May 2015 09:34:40 -0400
From: Doug Ledford <dledford@...hat.com>
To: Haggai Eran <haggaie@...lanox.com>
Cc: 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 Sun, 2015-05-17 at 08:50 +0300, Haggai Eran wrote:
> Thanks again everyone for the review comments. I've updated the patch set
> accordingly. The main changes are in the first patch to use a read-write
> semaphore instead of an SRCU, and with the reference counting of shared
> ib_cm_ids.
> Please let me know if I missed anything, or if there are other issues with
> the series.
Hi Haggai,
I know you are probably busy reworking this right now on the basis of
Jason's comments. However, my biggest issue with this patch set right
now is not technical (well, it is, but it's only partially technical).
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 think this is an
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
way there since the user space application gets its own device and so
its own MAC/IP and all of the RDMA transfers are UDP, so the
application's namespace should get inherited by all the rest, but Cisco
would need to confirm that, hence why I say 90% of the way there, it
needs confirmed).
So, while you are reworking things right now, you would ideally contact
Steve Wise and/or Tatyana Nikolova and discuss the iWARP story on this.
I know there won't be a lot of overlap between IB and iWARP, but last
time you were asked you didn't even know if this setup could be extended
to iWARP.
For this next statement, I know I'm directing this to you Haggai, but
please don't take it that way. I'm really using your patch set to make
a broader point to everyone on the list.
When I look at patches for support for a given feature, one of the
things I'm going to look at is whether or not that feature is specific
to a given hardware type, or if it's a generic feature. If it's a
generic feature, then I'm going to want to know that the person
submitting it has designed it well. A pre-requisite of designing a
generic feature well is that it considers all hardware types, not just
your specific hardware type. So when you come back with the next
version of this patch set, please have an answer for how it should work
on each hardware type even if you don't have implementation patches for
each hardware type.
--
Doug Ledford <dledford@...hat.com>
GPG KeyID: 0E572FDD
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists