On Wed, Nov 08, 2017 at 04:46:26PM +0000, Bernard Metzler wrote:
> -----Leon Romanovsky <leon@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
