Re: [RFC iproute2 0/8] RDMA tool

On Thu, 04 May 2017 16:45:58 -0400
Doug Ledford [off-list ref] wrote:

On Thu, 2017-05-04 at 15:26 -0400, Dennis Dalessandro wrote:

quoted

On 05/04/2017 02:45 PM, Leon Romanovsky wrote:  

quoted

On Thu, May 04, 2017 at 06:30:27PM +0000, Bart Van Assche wrote:  

quoted

On Thu, 2017-05-04 at 21:25 +0300, Leon Romanovsky wrote:  

quoted

On Thu, May 04, 2017 at 06:10:54PM +0000, Bart Van Assche
wrote:  

quoted

On Thu, 2017-05-04 at 21:02 +0300, Leon Romanovsky wrote:  

quoted

Following our discussion both in mailing list [1] and at
the LPC 2016 [2],
we would like to propose this RDMA tool to be part of
iproute2 package
and finally improve this situation.  

Hello Leon,

Although I really appreciate your work: can you clarify why
you would like to
add *RDMA* functionality to an *IP routing* tool? I haven't
found any motivation
for adding RDMA functionality to iproute2 in [1].  

We are planning to reuse the same infrastructure provided by
iproute2,
like netlink parsing, access to distributions, same CLI and
same standards.

Right now, RDMA is already tightened to netdev: iWARP, RoCE,
IPoIB, HFI-VNIC.
Many drivers (mlx, qed, i40, cxgb) are sharing code between net
and
RDMA.

I do expect that iproute2 will be installed on every machine
with any
type of connection, including IB and OPA.

So I think that it is enough to be part of that suite and don't
invent
our own for one specific tool.  

Hello Leon,

Sorry but to me that sounds like a weak argument for including
RDMA functionality
in iproute2. There is already a library for communication over
netlink sockets,
namely libnl. Is there functionality that is in iproute2 but not
in libnl and
that is needed for the new tool? If so, have you considered to
create a new
library for that functionality?  

It is not hard to create new tool, the hardest part is to ensure
that it is
part of the distributions. Did you count how many months we are
trying to
add rdma-core to debian?  

I do agree that it is a strange pairing and am not really a fan.
However 
at the end of the day it's just a name for a repo/package. If the 
iproute folks are fine to include rdma in their repo/package, great
we 
can leverage their code for CLI and other common stuff.  

If you look into the iproute2 package, it becomes clear that the name
iproute2 is historical and not really accurate any more.  It contains
things like the bridge control software, tc for controlling send
queues, and many things network related but not routing related.  The
rdma tool is a perfectly fine fit in the sense that it is an additional
network management tool IMO.

For reference, here's the list of stuff already in iproute on my Fedora
24 box:

/usr/sbin/arpd
/usr/sbin/bridge
/usr/sbin/cbq
/usr/sbin/ctstat
/usr/sbin/genl
/usr/sbin/ifcfg
/usr/sbin/ifstat
/usr/sbin/ip
/usr/sbin/lnstat
/usr/sbin/nstat
/usr/sbin/routef
/usr/sbin/routel
/usr/sbin/rtacct
/usr/sbin/rtmon
/usr/sbin/rtpr
/usr/sbin/rtstat
/usr/sbin/ss
/usr/sbin/tc
/usr/sbin/tipc

And in fact, if you check, tipc is almost similar to RDMA ;-)  So, I
suggest people not get hung up on the name iproute2, the fit is fine
when you look deeper into the nature of the package.

Iproute2 is a collection like busybox. It has bridging, devlink and tipc already.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html