On Wed, Nov 08, 2017 at 04:46:26PM +0000, Bernard Metzler wrote:
> -----Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: -----
>
> >> + */
> >> +static __init int siw_init_module(void)
> >> +{
> >> +	int rv;
> >> +	int nr_cpu;
> >> +
> >> +	if (SENDPAGE_THRESH < SIW_MAX_INLINE) {
> >> +		pr_info("siw: sendpage threshold too small: %u\n",
> >> +			(int)SENDPAGE_THRESH);
> >> +		rv = EINVAL;
> >> +		goto out;
> >> +	}
> >> +	/*
> >> +	 * The xprtrdma module needs at least some rudimentary bus to set
> >> +	 * some devices path MTU.
> >> +	 */
> >> +	rv = bus_register(&siw_bus);
> >
> >bus register for the driver? no way.
>
> I admit - this looks ugly. And the comment above is incomplete.
> I did this mainly to allow siw to register with loopback devices.
> During device registration, we need to present a real parent device:
> device_add() needs it, as called by ib_device_register_sysfs().
> The loopback device does not have a parent device, nor dma_ops.
> The dma_ops can be satisfied by global dma_virt_ops. But I did not
> find a similar 'virtual parent device' I could present during registration.
> So I 'invented' that one.
>
> I see no other way yet than dropping loopback device support, if this
> approach is not acceptable. But, we found it nice to have, since performance
> for the loopback case improved significantly.
>
> Any suggestion on how to enable loopback support (referencing 127.0.0.x
> addresses during connection management) in a more elegant way would
> be highly appreciated....
>

RXE solved it by relying on loopback from netdevice, see rxe_dma_device call
in rxe_register_device.

Will it work for SIW?

Thanks