> -----Original Message----- > From: oulijun <oulijun@xxxxxxxxxx> > Sent: Wednesday, February 27, 2019 2:09 AM > To: Parav Pandit <parav@xxxxxxxxxxxx>; bvanassche@xxxxxxx; linux- > rdma@xxxxxxxxxxxxxxx > Subject: Re: [EXPERIMENTAL v1 0/4] RDMA loopback device > > Hi, > What is the difference between loopback driver and loopback packet in the > IB protocol? > Loopback packet in IB protocol is as you described. However users almost always needs a physical hardware HCA (IB/RoCE, iwarp). Iwarp patches are in progress. There hasn't been reliable software stack yet for users who want to just run their applications in laptop/vm on single system. This is often done for unit tests, sanity, stack regression tests. Loopback driver mimics the netdev's lo style loopback rdma device in very simple manner. Its ABI less, where there almost any user space driver at all and still achieves 7Gbps to 80Gbps performance. Again rxe and cma can be enhanced, to add lo netdev interface via new netlink command added. But I have serious doubts that we can make rxe really work perfectly without ABI change, and without major rework. I am not sure if that is really worth it. If siw reworks the rxe driver, than there is some light of hope. > for the IB protocol description: > 10.2.2.3 LOOPBACK > Packet loopback is supported through self addressed packets as described in > 17.2.2 and C17-18:. Self-addressed packet is a packet whose DLID and SLID > address the same port of the same CA. Additionally, an HCA can optionally > support a Loopback Indicator. When Loopback Indicator is supported, both > Address Handles and QP/EE Address Vectors can use Loopback Indicator > instead of Destination LID. When reaping completions for Datagrams based > QPs, the Loopback Indicator is also reported if the origin of the message was > Loopback. > > I always have a question for the above. Why not expsure the loopback > indicator for user to support loopback packet? > It is not useful to expose this and modify all user applications for hw and sw devices. Core code already does this detection and does the loopback on hw and sw interfaces. Hence it is not desired to expose this optional part of the spec.
