RDMA tool

In order to close object model, ensure reuse of existing code and make this tool usable from day one, we decided to implement wrappers over legacy sysfs prior to implementing netlink functionality. As a nice bonus, it will allow to use this tool with old kernels too.

Quoted 4 lines · Leon Romanovsky

In order to close object model, ensure reuse of existing code and make this tool usable from day one, we decided to implement wrappers over legacy sysfs prior to implementing netlink functionality. As a nice bonus, it will allow to use this tool with old kernels too.

This sounds wrong. We don't support legacy ioctl interface for the 'ip' command, either. I think rdma should be converted to netlink first and the new tool should only use netlink.

Jiri

Quoted 9 lines · Jiri Benc

Quoted 4 lines · Leon Romanovsky

In order to close object model, ensure reuse of existing code and make this tool usable from day one, we decided to implement wrappers over legacy sysfs prior to implementing netlink functionality. As a nice bonus, it will allow to use this tool with old kernels too.

This sounds wrong. We don't support legacy ioctl interface for the 'ip' command, either. I think rdma should be converted to netlink first and the new tool should only use netlink.

RDMA in slightly different situation than "ip" tool was. "ip" was implemented when tools like ifconfig existed. It allowed to old and new systems to be configured to some degree. In RDMA community, there are no similar tools like "ifconfig". Implementation in netlink-only interface will leave old systems without common tool at all.

As an upstream-oriented person, I personally fine with that, but anyway would like to get wider agreement/disagreement on that, before removing sysfs parsing logic from the rdmatool.

Quoted 17 lines · Fri, May 05, 2017 at 03:17:54PM CEST, [email protected].…

Quoted 9 lines · Jiri Benc

Quoted 4 lines · Leon Romanovsky

In order to close object model, ensure reuse of existing code and make this tool usable from day one, we decided to implement wrappers over legacy sysfs prior to implementing netlink functionality. As a nice bonus, it will allow to use this tool with old kernels too.

This sounds wrong. We don't support legacy ioctl interface for the 'ip' command, either. I think rdma should be converted to netlink first and the new tool should only use netlink.

RDMA in slightly different situation than "ip" tool was. "ip" was implemented when tools like ifconfig existed. It allowed to old and new systems to be configured to some degree. In RDMA community, there are no similar tools like "ifconfig". Implementation in netlink-only interface will leave old systems without common tool at all.

Quoted 3 lines

As an upstream-oriented person, I personally fine with that, but anyway would like to get wider agreement/disagreement on that, before removing sysfs parsing logic from the rdmatool.

I tend to agree with Jiri Benc. I fear that supporting sysfs + netlink api later on for the same things will make the code unnecessary complex. Also, the legacy sysfs will most likely stay there forever so there will be no actual motivation to port the existing things to the new netlink api.

For the prototyping purposes, I belive that what you did makes perfect sense. But for the actual mergable version, my feeling is that we need to strictly stick with new netlink rdma interface and just forget about the old sysfs one. Distros would have to backport the new kernel rdma netlink api.

Yes, this will be little bit more painful at the beginning, but in the long run, I believe it will save some severe headaches.

Quoted 28 lines · Jiri Pirko

Quoted 17 lines · Fri, May 05, 2017 at 03:17:54PM CEST, [email protected] wrote:

Quoted 9 lines · Jiri Benc

Quoted 4 lines · Leon Romanovsky

In order to close object model, ensure reuse of existing code and make this tool usable from day one, we decided to implement wrappers over legacy sysfs prior to implementing netlink functionality. As a nice bonus, it will allow to use this tool with old kernels too.

This sounds wrong. We don't support legacy ioctl interface for the 'ip' command, either. I think rdma should be converted to netlink first and the new tool should only use netlink.

RDMA in slightly different situation than "ip" tool was. "ip" was implemented when tools like ifconfig existed. It allowed to old and new systems to be configured to some degree. In RDMA community, there are no similar tools like "ifconfig". Implementation in netlink-only interface will leave old systems without common tool at all.

Quoted 3 lines

As an upstream-oriented person, I personally fine with that, but anyway would like to get wider agreement/disagreement on that, before removing sysfs parsing logic from the rdmatool.

I tend to agree with Jiri Benc. I fear that supporting sysfs + netlink api later on for the same things will make the code unnecessary complex. Also, the legacy sysfs will most likely stay there forever so there will be no actual motivation to port the existing things to the new netlink api.

Quoted 5 lines

For the prototyping purposes, I belive that what you did makes perfect sense. But for the actual mergable version, my feeling is that we need to strictly stick with new netlink rdma interface and just forget about the old sysfs one. Distros would have to backport the new kernel rdma netlink api.

Thanks,
It looks like that most of the comments are in favor of netlink-only solution.

Quoted 28 lines · Jiri Pirko

Quoted 17 lines · Fri, May 05, 2017 at 03:17:54PM CEST, [email protected] wrote:

Quoted 9 lines · Jiri Benc

Quoted 4 lines · Leon Romanovsky

In order to close object model, ensure reuse of existing code and make this tool usable from day one, we decided to implement wrappers over legacy sysfs prior to implementing netlink functionality. As a nice bonus, it will allow to use this tool with old kernels too.

This sounds wrong. We don't support legacy ioctl interface for the 'ip' command, either. I think rdma should be converted to netlink first and the new tool should only use netlink.

RDMA in slightly different situation than "ip" tool was. "ip" was implemented when tools like ifconfig existed. It allowed to old and new systems to be configured to some degree. In RDMA community, there are no similar tools like "ifconfig". Implementation in netlink-only interface will leave old systems without common tool at all.

Quoted 3 lines

As an upstream-oriented person, I personally fine with that, but anyway would like to get wider agreement/disagreement on that, before removing sysfs parsing logic from the rdmatool.

I tend to agree with Jiri Benc. I fear that supporting sysfs + netlink api later on for the same things will make the code unnecessary complex. Also, the legacy sysfs will most likely stay there forever so there will be no actual motivation to port the existing things to the new netlink api.

Quoted 5 lines

For the prototyping purposes, I belive that what you did makes perfect sense. But for the actual mergable version, my feeling is that we need to strictly stick with new netlink rdma interface and just forget about the old sysfs one. Distros would have to backport the new kernel rdma netlink api.

Thanks,
It looks like that most of the comments are in favor of netlink-only solution.

Quoted 3 lines

Yes, this will be little bit more painful at the beginning, but in the long run, I believe it will save some severe headaches.

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.

Quoted 3 lines · Leon Romanovsky

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

Thanks,

Bart.--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 10 lines · Bart Van Assche

Quoted 3 lines · Leon Romanovsky

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.

Quoted 19 lines · Leon Romanovsky

Quoted 10 lines · Bart Van Assche

Quoted 3 lines · Leon Romanovsky

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.

Quoted 5 lines

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?

Thanks,

Bart.

Quoted 26 lines · Bart Van Assche

Quoted 19 lines · Leon Romanovsky

Quoted 10 lines · Bart Van Assche

Quoted 3 lines · Leon Romanovsky

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.

Quoted 5 lines

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.

Quoted 7 lines

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?

Quoted 35 lines · Leon Romanovsky

Quoted 26 lines · Bart Van Assche

Quoted 19 lines · Leon Romanovsky

Quoted 10 lines · Bart Van Assche

Quoted 3 lines · Leon Romanovsky

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.

Quoted 5 lines

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.

Quoted 7 lines

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?

Quoted 3 lines

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.

Now if the interface was something like "ip -FlagForRdma ..." I would object to that, but the interface is "rdma ... " so from users perspective it's different tools. They don't need to care that it was sourced from a common git repo.

Just as an aside this already works a bit with OPA:

 $ ./rdma link
1/1: hfi1_0/1: ifname NONE cap_mask 0x00410022 lid 0x1 lid_mask_count 0
link_layer InfiniBand
         phys_state 5: LinkUp rate 100 Gb/sec (4X EDR) sm_lid 0x1 sm_sl 0
state 4: ACTIVE

Leon I'll get you more feedback and testing, I've just been really bogged down this week, sorry.

-Denny

Quoted 52 lines · Dennis Dalessandro

Quoted 35 lines · Leon Romanovsky

Quoted 26 lines · Bart Van Assche

Quoted 19 lines · Leon Romanovsky

Quoted 10 lines · Bart Van Assche

Quoted 3 lines · Leon Romanovsky

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.

Quoted 5 lines

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.

Quoted 7 lines

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?

Quoted 3 lines

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.

Now if the interface was something like "ip -FlagForRdma ..." I would object to that, but the interface is "rdma ... " so from users perspective it's different tools. They don't need to care that it was sourced from a common git repo.

Just as an aside this already works a bit with OPA:

Quoted 8 lines

 $ ./rdma link
1/1: hfi1_0/1: ifname NONE cap_mask 0x00410022 lid 0x1 lid_mask_count 0
link_layer InfiniBand
         phys_state 5: LinkUp rate 100 Gb/sec (4X EDR) sm_lid 0x1 sm_sl 0
state 4: ACTIVE

Leon I'll get you more feedback and testing, I've just been really bogged down this week, sorry.

Thanks Denny,

Before you are starting to test it, can you please provide your feedback on my initial questions? Usability and need of sysfs.
----
This is initial phase to understand if user experience for this tool fits RDMA and netdev communities exepectations. Also I would like to get feedback if it is really worth to provide legacy sysfs for old kernels, or maybe I should implement netlink from the beginning and abandon sysfs completely.
-----

Quoted 64 lines · Leon Romanovsky

Quoted 52 lines · Dennis Dalessandro

Quoted 35 lines · Leon Romanovsky

Quoted 26 lines · Bart Van Assche

Quoted 19 lines · Leon Romanovsky

Quoted 10 lines · Bart Van Assche

Quoted 3 lines · Leon Romanovsky

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.

Quoted 5 lines

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.

Quoted 7 lines

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?

Quoted 3 lines

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.

Now if the interface was something like "ip -FlagForRdma ..." I would object to that, but the interface is "rdma ... " so from users perspective it's different tools. They don't need to care that it was sourced from a common git repo.

Just as an aside this already works a bit with OPA:

Quoted 8 lines

 $ ./rdma link
1/1: hfi1_0/1: ifname NONE cap_mask 0x00410022 lid 0x1 lid_mask_count 0
link_layer InfiniBand
         phys_state 5: LinkUp rate 100 Gb/sec (4X EDR) sm_lid 0x1 sm_sl 0
state 4: ACTIVE

Leon I'll get you more feedback and testing, I've just been really bogged down this week, sorry.

Thanks Denny,

Quoted 8 lines

Before you are starting to test it, can you please provide your feedback on my initial questions? Usability and need of sysfs.
----
This is initial phase to understand if user experience for this tool fits RDMA and netdev communities exepectations. Also I would like to get feedback if it is really worth to provide legacy sysfs for old kernels, or maybe I should implement netlink from the beginning and abandon sysfs completely.
-----

For the initial phase I think you did the right thing by reading sysfs. I like the ability for the tool to be compatible with legacy kernels, but at the same time I don't know if it's worth the hassle. I won't fight too hard either way.

Perhaps we should take a stab and seeing what a dual sysfs/netlink interface would look like, and see just how hard and complicated it really is. Then we can make that call. You already have the sysfs version, and have to do netink anyway, so let's not rip out what's there just yet, this is an RFC after all, not like you are asking for this exact version to be merged yet.

As far as usability, I think what's here is a great start and we can continue to refine. I'm particularly interested in the stats capabilities. In particular being able to filter what stats are shown and watch as they change over time. RDMA devices have lots of counters and stats. A common tool for users to be able to get that data across HW types would be a really good thing.

-Denny

Quoted 55 lines · Leon Romanovsky

Quoted 43 lines · Bart Van Assche

Quoted 31 lines · Leon Romanovsky

Quoted 9 lines · Bart Van Assche

Quoted 6 lines · Leon Romanovsky

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.

Quoted 7 lines

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.

Quoted 7 lines

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,

Quoted 9 lines

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?

Quoted 5 lines

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.

Quoted 62 lines · Dennis Dalessandro

Quoted 55 lines · Leon Romanovsky

Quoted 43 lines · Bart Van Assche

Quoted 31 lines · Leon Romanovsky

Quoted 9 lines · Bart Van Assche

Quoted 6 lines · Leon Romanovsky

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.

Quoted 7 lines

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.

Quoted 7 lines

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,

Quoted 9 lines

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?

Quoted 5 lines

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?

Quoted 6 lines

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.

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?

Quoted 3 lines · Leon Romanovsky

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

Quoted 10 lines · Jiri Pirko

Quoted 8 lines · Thu, May 04, 2017 at 08:10:54PM CEST, [email protected] wrote:

Quoted 3 lines · Leon Romanovsky

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.

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

Quoted 3 lines

Bart, please realize that iproute2 is much more than "*IP routing* tool". I understand you got confused by the name. Please see sources. Your comment is totally pointless...

I asked for a clarification that should have been in the cover letter but that was missing from that cover letter. So I think that was the right thing to do instead of pointless. BTW, can you explain why you are using an e-mail address that is hiding that you are a Mellanox employee?

Bart.

Quoted 10 lines · Jiri Pirko

Quoted 8 lines · Thu, May 04, 2017 at 08:10:54PM CEST, [email protected] wrote:

Quoted 3 lines · Leon Romanovsky

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.

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

Quoted 3 lines

Bart, please realize that iproute2 is much more than "*IP routing* tool". I understand you got confused by the name. Please see sources. Your comment is totally pointless...

I asked for a clarification that should have been in the cover letter but that was missing from that cover letter. So I think that was the right thing to do

instead of pointless. BTW, can you explain why you are using an e-mail address that is hiding that you are a Mellanox employee?

Quoted 11 lines · Sat, May 06, 2017 at 04:40:24PM CEST, Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ@pub…

Quoted 10 lines · Jiri Pirko

Quoted 8 lines · Thu, May 04, 2017 at 08:10:54PM CEST, Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ@pub…

Quoted 3 lines · Leon Romanovsky

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.

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

Quoted 6 lines

Quoted 3 lines

Bart, please realize that iproute2 is much more than "*IP routing* tool". I understand you got confused by the name. Please see sources. Your comment is totally pointless...

I asked for a clarification that should have been in the cover letter but that was missing from that cover letter. So I think that was the right thing to do

I think that was just complete misunderstanding about what iproute2 is.

Quoted 12 lines · Jiri Pirko

Quoted 11 lines · Sat, May 06, 2017 at 04:40:24PM CEST, Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ@pub…

Quoted 10 lines · Jiri Pirko

Quoted 8 lines · Thu, May 04, 2017 at 08:10:54PM CEST, Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ@pub…

Quoted 3 lines · Leon Romanovsky

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.

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

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

Bart, please realize that iproute2 is much more than "*IP routing* tool". I understand you got confused by the name. Please see sources. Your comment is totally pointless...

I asked for a clarification that should have been in the cover letter but that was missing from that cover letter. So I think that was the right thing to do

I think that was just complete misunderstanding about what iproute2 is.

Hello Jiri,

I do not agree with your reply. The abbreviation "IP" occurs in the package name and that is a reference to the "Internet Protocol". As far as I know originally the iproute2 package contained only tools related to the Internet Protocol. Other tools, e.g. the tipc tool, were added later on. What I'm wondering about is whether it really is a good idea to add tools like tipc and rdma to the iproute2 package. The iproute2 package is so essential that it gets installed on every Linux system, including embedded systems and smartphones based on Linux. Several companies maintain embedded Linux distributions and tools to build software images. These tools provide a user interface that allows to select what packages go into such an image. Adding tools like tipc and rdma to the iproute2 package makes it harder than necessary for those who build software images for embedded devices to minimize the size of such an image. As you probably know even today the size of a software image still matters for embedded devices. Something else I have been wondering about is whether bundling the tipc and rdma tools in the iproute2 package will make the job harder of people who build Android ROMs? The ip tool is present in every Android ROM, and the size of these ROMs matters because the larger these ROMs are the less space remains for apps.

Bart.

Several companies maintain embedded Linux
distributions and tools to build software images. These tools provide a user interface that allows to select what packages go into such an image.