On Mon, Oct 11, 2021 at 05:46:48PM +0000, Long Li wrote: > > Subject: Re: [Patch v5 0/3] Introduce a driver to support host accelerated access > > to Microsoft Azure Blob for Azure VM > > > > Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > > > > ... > > > > > > Not to mention the whole crazy idea of "let's implement our REST api > > > that used to go over a network connection over an ioctl instead!" > > > That's the main problem that you need to push back on here. > > > > > > What is forcing you to put all of this into the kernel in the first > > > place? What's wrong with the userspace network connection/protocol > > > that you have today? > > > > > > Does this mean that we now have to implement all REST apis that people > > > dream up as ioctl interfaces over a hyperv transport? That would be > > > insane. > > > > As far as I understand, the purpose of the driver is to replace a "slow" > > network connection to API endpoint with a "fast" transport over Vmbus. So > > what if instead of implementing this new driver we just use Hyper-V Vsock and > > move API endpoint to the host? > > Hi Vitaly, > > We looked at Hyper-V Vsock when designing this driver. The problem is that the Hyper-V device model of Vsock can't support the data throughput and scale needed for Blobs. Vsock is mostly used for management tasks. > > The usage of Blob in Azure justifies an dedicated VMBUS channel (and sub-channels) for a new VSP/VSC driver. Why not just fix the vsock code to handle data better? That way all users of it would benefit. thanks, greg k-h
