[PATCH 1/1] Drivers: infiniband: hw: vmbus-nd: NetworkDirect driver for Linux

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh at linuxfoundation.org]
> Sent: Wednesday, July 27, 2016 2:26 PM
> To: KY Srinivasan <kys at microsoft.com>
> Cc: linux-kernel at vger.kernel.org; devel at linuxdriverproject.org; linux-
> rdma at vger.kernel.org; yishaih at mellanox.com; sean.hefty at intel.com;
> dledford at redhat.com; olaf at aepfle.de; apw at canonical.com;
> vkuznets at redhat.com; jasowang at redhat.com;
> leann.ogasawara at canonical.com; Long Li <longli at microsoft.com>
> Subject: Re: [PATCH 1/1] Drivers: infiniband: hw: vmbus-nd: NetworkDirect
> driver for Linux
> 
> On Wed, Jul 27, 2016 at 09:09:08PM +0000, KY Srinivasan wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh at linuxfoundation.org]
> > > Sent: Tuesday, July 26, 2016 9:41 PM
> > > To: KY Srinivasan <kys at microsoft.com>
> > > Cc: linux-kernel at vger.kernel.org; devel at linuxdriverproject.org; linux-
> > > rdma at vger.kernel.org; yishaih at mellanox.com; sean.hefty at intel.com;
> > > dledford at redhat.com; olaf at aepfle.de; apw at canonical.com;
> > > vkuznets at redhat.com; jasowang at redhat.com;
> > > leann.ogasawara at canonical.com; Long Li <longli at microsoft.com>
> > > Subject: Re: [PATCH 1/1] Drivers: infiniband: hw: vmbus-nd: NetworkDirect
> > > driver for Linux
> > >
> > > On Tue, Jul 26, 2016 at 07:05:37PM -0700, kys at exchange.microsoft.com
> > > wrote:
> > > > +/*
> > > > + * Create a char device that can support read/write for passing
> > > > + * the payload.
> > > > + */
> > >
> > > That sounds "interesting"...
> > >
> > > > +
> > > > +static struct completion ip_event;
> > > > +static bool opened;
> > > > +
> > > > +char hvnd_ip_addr[4];
> > > > +char hvnd_mac_addr[6];
> > > > +bool hvnd_addr_set;
> > >
> > > Global variables?
> >
> > >
> > > > +
> > > > +int hvnd_get_ip_addr(char **ip_addr, char **mac_addr)
> > > > +{
> > > > +	int t;
> > > > +
> > > > +	/*
> > > > +	 * Now wait for the user level daemon to get us the
> > > > +	 * IP addresses bound to the MAC address.
> > > > +	 */
> > > > +	if (!hvnd_addr_set) {
> > > > +		t = wait_for_completion_timeout(&ip_event, 600*HZ);
> > > > +		if (t == 0)
> > > > +			return -ETIMEDOUT;
> > > > +	}
> > > > +
> > > > +	if (hvnd_addr_set) {
> > > > +		*ip_addr = hvnd_ip_addr;
> > > > +		*mac_addr = hvnd_mac_addr;
> > > > +		return 0;
> > > > +	}
> > > > +
> > > > +	return -ENODATA;
> > > > +}
> > > > +
> > > > +static ssize_t hvnd_write(struct file *file, const char __user *buf,
> > > > +			size_t count, loff_t *ppos)
> > > > +{
> > > > +	char input[120];
> > > > +	int scaned, i;
> > > > +	unsigned int mac_addr[6], ip_addr[4];
> > > > +
> > > > +	if (hvnd_addr_set) {
> > > > +		hvnd_error("IP/MAC address already set, ignoring input\n");
> > > > +		return count;
> > > > +	}
> > > > +
> > > > +	if (count > sizeof(input)-1)
> > > > +		return -EINVAL;
> > > > +
> > > > +	if (copy_from_user(input, buf, count))
> > > > +		return -EFAULT;
> > > > +
> > > > +	input[count] = 0;
> > > > +
> > > > +	/*
> > > > +	 * Wakeup the context that may be waiting for this.
> > > > +	 */
> > > > +	hvnd_debug("get user mode input: %s\n", input);
> > > > +
> > > > +	scaned = sscanf(input,
> > > > +		"rdmaMacAddress=\"%x:%x:%x:%x:%x:%x\"
> > > rdmaIPv4Address=\"%u.%u.%u.%u\"",
> > > > +		&mac_addr[0],
> > > > +		&mac_addr[1],
> > > > +		&mac_addr[2],
> > > > +		&mac_addr[3],
> > > > +		&mac_addr[4],
> > > > +		&mac_addr[5],
> > > > +		&ip_addr[0],
> > > > +		&ip_addr[1],
> > > > +		&ip_addr[2],
> > > > +		&ip_addr[3]);
> > >
> > > Oh, that's a mess, you are going to parse text in the kernel that is
> > > passed on a char device?  Please tell me that not all IB drivers are
> > > like this...
> >
> > Greg,
> >
> > This driver is plugging into the Windows NetworkDirect infrastructure on the
> host side.
> > The fabric assigns the MAC/IP address for the interface. I have chosen this
> mechanism for
> > passing the information to the kernel driver. I can certainly look at other
> mechanism.
> 
> Why create a new mechanism that is different from all other IB
> controllers?  Shouldn't this just be a "normal" network device in that
> manner?

That is a good point. I will look at other options.

Regards,

K. Y